近年来，分布式数据库产品的研发和技术逐步成熟，金融行业也已经有成功案例投入生产系统使用。本文从多个角度阐述分布式数据库选型所面临的问题及解决路径思考。

传统单机数据库一般指OLTP场景的关系型单机数据库，诸如Oracle、DB2等商业数据库以及开源产品MySQL、PostgreSQL，主要解决两个业务问题：在线数据库的实时高效存取和事务保证。传统单机数据库的容量和性能，足以满足绝大多数中小规模客户的需求；依托特定的软硬件条件，商业数据库甚至可以满足部分大规模客户的数据库使用需要。

但随着互联网时代的到来，业务数据呈爆发式增长，单机数据库在存储容量，以及计算、吞吐上遇到了瓶颈。数据量的膨胀，拉高的不仅仅是存储成本，也提升了数据库运维难度和数据安全风险；高并发的业务场景，特别是高并发更新的场景，都需要充足的数据库计算资源和磁盘IO资源，单机数据库捉襟见肘。虽然可以通过业务对数据合理化拆分到多个数据库实例，来延缓单机资源见顶的时间，但需要不断付出高额的架构改造成本。

分布式数据库基本思路都是将多台物理机资源组织起来，作为一个数据库对应用提供服务，理想情况下，高并发场景下的计算、存储IO、网络IO压力在物理机之间均衡。同时要求其具备资源横向和扩展能力，充分满足业务未来增长需求。

当前分布式数据库可细分为分布式数据库中间件和原生分布式数据库两种类型：

分布式数据库中间件，作为proxy层，将单机数据库实例作为底层存储节点组合起来，将海量数据的分库分表逻辑对应用屏蔽起来，使得底层存储资源的扩容对应用无感知，是典型的ShareNothing架构。

原生分布式数据库，架构是上下一体的，计算层和存储层耦合较为紧密，计算层OLTP数据库为SMP架构，分布式可实现负载均衡和高可用，OLAP数据库多为MPP架构，利用并行处理对复杂查询加速；存储层常采用ShareNothing架构对IO资源进行隔离，多副本之间采用分布式一致性算法在数据可用性和一致性之间做出平衡。因为计算层和存储层一体化设计，往往更容易兼容更多传统单机数据库的产品特性。

云原生数据库是近几年来比较热门的一个数据库分类，常常与分布式数据库发生混淆，但二者之间天然存在差别。

云原生本质上是充分利用云计算基础设施的高性能、高可靠性和高弹性能力研发云上产品的一种方式。在专门以云计算资源为基础研发的数据库，才是云原生数据库，它们能带来近乎传统单机数据库的特性支持和使用体验，同时具备资源（计算、存储）快速弹性伸缩的能力，资源虽然是分布式的，但数据库架构的实质依然是scale up。

与云基础设施的强耦合，是云原生数据库区别于分布式数据库的最大特点。 

这类产品，一般采用了典型的“Share Nothing”架构，实现存储与计算分离，通过上层无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。

1）产品优势

这一架构产品的优势在于功能丰富、可按业务做定制；稳定性较高，基于成熟稳定的单机引擎。在面对超大规模数据存储，通过灵活的分片配置策略，支持高灵活度数据打散技术，并可贴近场景需求定制分片。

2）产品劣势

相对不足在于全局事务能力、全局MVCC、副本控制、高可用等方面存在先天短板，需要有针对性增强。例如引入全局事务管理器组件，突破单机限制，实现分布式事务的实时一致性及全局MVCC能力，对应用透明的分布式事务处理，应用无需改造。通过一阶段“提交+自动补偿”机制，提升分布式事务处理性能。

针对数据强一致性的要求，在单机库同步技术基础上，通过内核级的增强优化实现更高级别的复制保证数据不丢失。此外，由于需维护多节点一致性而带来的在跨分片DDL、分片节点扩容、跨节点复杂查询、全局一致的备份恢复等方面问题值得关注。

3）最佳实践

这种架构产品较为适用于数据规模巨大、对延迟要求很高的在线交易场景。在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。

这类产品，一般也是采用“Share Nothing”架构，实现存储与计算分离。与上面不同的是，底层多采用自研存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上更有优势，例如在某些分析类场景可选择列存。

1）产品优势

Native的原生实现，工程上不依赖其他产品，可控程度更高。面对很多新的需求，可从底层加以实现支持，不受限于第三方。在副本控制、数据一致性、容灾、弹性能力等方面更具有优势。此外，场景方面有更为灵活的选择及未来可扩展的空间。

2）产品劣势

产品成熟度仍需较长时间沉淀，特别是使用在核心业务场景，仍然需要较长时间的锤炼。此外，其内置的分片规则，对于某些需贴合业务的架构设计不太友好。对于高并发、低延迟的极端场景仍然有一定局限。

云原生数据库是Share Everything模式，其底层是分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。针对这种架构不足展开说明，原因是这种方式是需要对底座有比较强的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。因此，使用选择上存在一定困难。

分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。

在进行分布式选型时，可重点考察下列几个方面：

1）分布式事务

分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。

2）性能

由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单sql的性能，但是大数据量的sql查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的sql并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句（主要是多表关联）的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。

3）数据备份

分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，另外，就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。

4）高可用

分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署。

5）数据一致性

NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。

6）其他因素

金融行业在数据库选型中，除了需要考虑上述四点外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。

除了上述技术因素外，在选型中还需考虑系统运行现状，可重点参考下述指标：

1）系统数量

考量租户能力。

2）数据量

考量系统承载力。

3）系统性能指标

TPS、QPS、RT等。

4）并发量

系统的最大并发数：为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还需独立搭建。     

5）业务中断时间

系统最大可容忍的业务中断时间：分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。  

6）系统的迁移成本

分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少地涉及到应用的改造。

除了对运行时的各种因素评估外，作为底层技术基础设施的更换，还需要考虑基础资源的使用。分布式数据库通常会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，单体硬件成本较低。但在服务器数量上，需要有更多考虑。一方面分布式数据库组件众多，且每个组件都需要高可用配置，即使部分可采用混部方式解决，但在整体数量上仍然会较多。

此外，还需要考虑各组件的负载模型不同、关键组件独立部署、数据多副本等等问题。此外，结合重点关注的性能数据、例如支持的QPS等，从而计算出服务器数量需求。需要注意的是，分布式数据库厂商提供的性能测试采用的服务器参数，一般是高配服务器，如果实际生产使用服务器配置降低，还要考虑性能数据损耗等问题。

技术没有银弹，不存在最好的数据库产品，只有针对具体场景最适合的方案。

根据业界多年实践经验，当数据库容量小于2T，TPS小于6000时，CPU使用率、响应时间和主从延迟没有明显异常的情况下，适合于传统单机数据库。

分布式数据库中间件特别适合数据具有天然分片特征的场景，当数据库容量大于2T，TPS大于6000，预期业务数据会持续增长，可以结合业务特点进行分库评估规划。但在SQL研发上有要求，避免非拆分键查询和分布式事务，不然吞吐会非常差。

原生分布式数据库，适合数据库容量持续增长，数据规模巨大（P级），对资源弹性伸缩，可用性和强一致性要求高的场景，与传统数据库的兼容度好，但架构往往不典型，运维难度略高，使用上分布式执行计划的优化也需要技巧。

分布式中间件产品现在通过自适应分区表，数据一致性hash，统一binlog服务等新特性的研发，越来越像原生分布式数据库靠拢；原生分布式数据库同样，不能完全摆脱实现数据透明水平拆分的中间件方案，相信二者的边界未来会逐渐模糊。