金融行业国产OLTP分布式数据库如何选型

今年猝不及防的疫情使得产业数字化成爆发趋势， “新基建”的提出再次让国产数据库走到了春风口。 面对国内各式各样的数据库产品，该如何选择？尤其是金融行业，实现从Orecal、IBM到国产数据库的替换必将要多种维度考虑。目前市面被熟知的国产OLTP数据库产品有：OceanBase 、HotDB, 巨杉数据库，TiDB、TDSQL GoldenDB， 作为对数据库强一致、高可用等要求极高的金融行业该如何选型？ 以下笔者根据金融行业核心业务系统对数据的要求总结的一些选型时须着重考虑的维度：

产品自身

首先满足分布式数据库产品的基础要求：数据正确、稳定可靠、极致性能、智能自治

数据正确
从应用访问数据库视角是数据库层的数据实时一致、原子性、事务隔离级别等；从数据持久化视角是数据库的提交事务数据是否不丢失、单个数据副本损坏是否另外一个数据副本的数据零丢失。

稳定可靠
判断物理服务器损坏、文件系统损坏、物理服务器网络故障、物理服务器断电等，也即分布式数据库产品参与数据库操作处理的每个组件是否有响应的高可用机制，及采用分布式一致性协议的组件是否能突破少于半数节点无法提供服务的能力等。

极致性能：
集中式数据库转分布式数据库后，每笔数据库DML操作至少多一个网络来回（提问中产品：TiDB、GoldenDB、 TDSQL 则每笔DML操作多2个网络来回，OB、HotDB则每笔DML操作多一个网络来回），加上数据库服务接入节点（或称计算节点 或称计算引擎）的内部对SQL语句解析、优化、改写、锁资源开销等。但时间主要是因至少多一个网络来回的时延，则必须拥有更强大的并发数能力和每笔数据库操作必须快速响应，才能又更大的吞吐量。可参考蚂蚁金服OB、热璞数据库HotDB对外承诺的数据：10万及以上连接数、10万及以上并发数、30万及以上TPS、100万及以上QPS。

智能自治：
由一套或几套 的Oracle数据库产品集群或DB2数据库产品集群 支撑企业业务发展,转变成分布式事务数据库产品后,优秀OLTP分布式数据库产品的计算节点服务器数量个位数即可,但因单个存储节点处理能力有限需要依赖水平扩展的方式达成高并发 、 高吞吐,则存储节点服务器数量一定会是集中式数据库存储设备台数的十倍及以上,且数据分片后和数据库访问操作经过计算引擎(或称计算节点)会被改写等处理,对DBA 而言如何判断数据库隐患分析 、 数据库故障排查 、 数据库性能瓶颈调优 、日常运维管理等,要是没有产品化的思路则会带来成几何倍数的运维工作量 、运维技术门槛 、 运维技术难度.

金融级需求

1） 金融行业必须确保 数据正确 、 数据实时一致 、 可靠可用,所以就必须在POC环节做响应的测试验证,例如:采用银行账户之间的转账业务场景验证分布式事务是否做到 “数据正确,数据实时一致” 、 对涉及数据库操作访问处理的组件都需要做健壮性测试验证和故障叠加的健壮性测试验证. 金标委也提供了相关的检测方案标准待公布,对于银行传统转账业务场景可参考文档资料:银行核心系统转账场景性能测试报告

2） OLTP分布式数据库产品必须同金融行业已大规模使用长达30年以上集中式数据库产品的事务原子性 、 事务隔离级别 、数据库的 应用操作透明 、 数据库基础SQL 、 数据库基础函数 、 悲观锁 、 死锁检测和死锁解除等保持一致

综上，我们再说说上述几款国产OLTP分布式数据库该如何选型（OceanBase 、HotDB, 巨杉数据库，TiDB、TDSQL GoldenDB）

（1）从自主研发和数据库生态的两个维度思考分析

(2)、 从"数据正确 、 稳定可靠 、 极致性能 、 智能自治"的四个维度思考分析

上述信息及观点，希望可以帮助大家在金融行业国产OLTP分布式数据库选型时起到参考作用