银行业分布式关系型数据库选型分析①

谢伟

(江西省农村信用社联合社 江西南昌 330096)

1 实践技术难点

为了实现对应用程序透明和计算及存储的分布式，分布式关系型数据库需要通过网络将物理上分散的多个数据库节点连接起来组成一个逻辑上统一的整体。而由于数据分布在多个物理节点上，而且任何一个节点都不完全可靠，所以数据必然需要有冗余副本。相反，传统集中式关系型数据库数据只有唯一的一个副本，计算能力一般也是集中在一台服务器中。很明显，分布式关系型数据库面临的挑战更大，实现的技术难度更高。

一是数据一致性。分布在多个数据库节点的副本内容需要严格保持一致，并且同时还需要减少跨节点甚至跨数据中心网络通讯时延的影响，保证性能控制在业务可接受范围。

二是高可用性。任意数据库节点发生故障后，数据库可用性不能受明显影响，或者能在极短时间（例如30s）内恢复至正常状态。

三是分布式事务。在任意情况下，包括网络通讯故障和数据库节点发生故障等，数据库事务必须正常结束，不能出现各节点间事务状态不一致。

四是多表操作。由于数据是分散在多个物理节点，多表关联查询就必然需要若干跨节点的数据复制操作，增加执行时间，耗费网络带宽，从而降低系统性能。需要有良好的机制降低此类性能影响。

2 典型产品分析

近年来，分布式关系型数据库是各互联网巨头和新兴数据库厂商的关注热点，各类产品层出不穷，技术方案各有千秋，面向的应用场景各异，但整体方案还是有不少相似之处。以下以市场上较为成功的OLTP数据库OceanBase和OLAP数据库GreenPlum为例，简要分析一下分布式关系型数据库的技术实现。

2.1 OceanBase

OceanBase是一款阿里巴巴2010年开始研发的分布式、Shared-nothing的关系型数据库[1]，支持完整的ACID特性，高度兼容MySQL协议与语法，早期用于收藏夹、天猫评价等，现已广泛用于各种关键应用场景，其中包括支付宝和网商银行。2018年1月26日，网商银行成功利用OceanBase实现了三地五中心双活，进一步验证了城市级容灾能力，为金融行业关键数据库技术升级做了有益的探索。

OceanBase采用数据分布和负载均衡技术实现系统的高性能和弹性伸缩，使用两阶段提交协议实现跨节点的分布式事务。OceanBase基于Paxos的分布式算法实现系统的高可用和数据一致性[2]，集群中的每个分区都维护三个以上副本，整个系统中分区的多个副本之间通过Paxos协议进行日志同步，其中一个副本为主，其他副本为备。因为Paxos协议特性，故障恢复迅速、数据同步效率高，极大降低了多副本和跨数据中心部署带来的性能下降风险。

此外，OceanBase数据库还充分利用了OLTP系统业务周期性和当前硬件发展的特性，采用基于SSD基线数据和内存增量数据的分布式存储架构，充分发挥了SSD存储随机读性能优异的技术优势，同时利用大量内存存储增量数据规避了SSD存储写入放大的弱点，尽可能提高了系统的日间事务处理能力。

2.2 GreenPlum

GreenPlum数据库是一种MPP架构的分布式关系数据库，使用传统的PostgreSQL数据库作为基础存储和计算模块，拥有良好的线性扩展能力，支持行列表方式存储数据，擅长于大批量数据的低并发处理，非常适合大数据计算或分析平台，常用于数据仓库系统。

GreenPlum具有较好的高可用性，Master只负责对客户端进行访问控制和存储表分布逻辑的元数据，通过PostgreSQL的流复制同步保证数据一致，Segment为一组独立的PostgreSQL数据库，存储用户数据，Master通过哈希算法将表的数据分布于所有Segment中。在分布式事务方面，GreenPlum采用两阶段提交和全局事务管理机制来保证集群上分布式事务的一致性，可以像PostgreSQL一样满足关系型数据库的包括ACID在内的所有特征。

但是，由于Master负责全部查询计划生成和优化、Seg ment通过文件复制实现数据一致性等原因，GreenPlum并发能力和响应速度一般，并不适合在极短的时间处理大量的并发小任务，不适用于OLTP场景。

3 选型参考建议

经过以上分析可以看到，经过众多专家的不懈努力，无论在OLAP还是OLTP场景，分布式关系型数据库已成功实践，另外随着通信技术的快速发展，通信成本日益下降，分布式系统整体性能扩展能力也越来越强。但是，分布式关系型数据库产品的历史相对较短，在实现相关算法过程中或多或少进行了一些调整，用户覆盖面也较小，产品缺陷难以暴露，产品质量有待检验。因此，为支撑未来IT建设，银行业引入分布式关系型数据库需要从技术兼容性、以及新技术前瞻性两个维度进行评估，其中ACID的支持与SQL兼容性是评估分布式关系型数据库的两大关键指标。

（1）ACID。从安全性上来看，不论采用新技术或传统技术，银行作为金融机构，满足ACID是数据库选型的必要条件。在分布式关系型数据库业界中，CAP 理论已成为分布式系统设计与构建的重要理论基石[3]，它又称之为布鲁尔定理（Brewer's theorem），即一致性（Consistence）、可用性（Availability）和分区容忍性（Partition Tolerance）三者不可得兼，目前，一些针对互联网技术设计的产品以牺牲一致性，换取分区容忍性和可用性，很难在金融业务中被广泛使用。因此，银行对分布式关系型数据库选型必须首先保证数据的安全和一致性，其中分布式事务、分布式锁、隔离级别是选型的关键特性。

（2）SQL兼容性。SQL兼容性指分布式关系型数据库对传统关系型数据库的SQL语言、协议的兼容程度。多数银行业务系统仍然采用DB2、Oracle等传统关系型数据库，如果将此类应用从传统关系型数据库迁移至分布式关系型数据库，若SQL兼容性无法保证，势必会造成应用改造量大、数据迁移风险等问题，因此，对SQL完整性支持的强弱成为分布式关系型数据库选型的评判关键标准之一。

（3）弹性伸缩能力。随着云计算、移动互联的快速发展，分布式技术之所以成为发展趋势，是因为其良好的弹性伸缩能力，可以快速适应流量暴增带来的业务冲击，因此，作为新兴技术，分布式关系型数据库必须做到弹性伸缩，才能顺应当前趋势发展，支撑应用系统技术架构升级。

（4）混合事务分析处理。在传统银行IT架构中，联机事务交易与统计查询分析业务系统通常分别采用OLTP和OLAP数据库，通过定期抽取、转换、装载过程将联机交易数据迁移至分析系统中，但随着云计算发展，分布式关系型数据库云化之后，作为一种云服务，必须同时提供OLTP和OLAP的能力，但又要保证联机交易和查询分析无相互干扰，因此混合事务分析处理能力也成为银行数据库选型参考之一。

4 结语

总体来说，分布式关系型数据库技术的不断发展和产品的不断涌现和持续升级，将为银行业进一步实践分布式架构扫除最后一个障碍，为进一步提升业务连续性提供强大的基础支撑，为进一步提升业务竞争能力增添动力。作为传统银行业，为适应云计算、大数据等技术变革，分布式关系型数据库选型应充分考虑ACID数据安全与SQL完整性，采用典型试点、初步推广的策略，积极拥抱分布式关系型数据库。