OLTP分布式数据库或称 分布式事务数据库 必须要做到同 集中式数据库 等同的 事务一致性、吞吐量应该更大、响应时间可控。 一个不支持分布式事务强一致的数据库产品 不能称之为 分布式事务数据库产品,刚好看到一份银行核心系统转账业务场景性能测试的 普通一致 和 强一致 的 吞吐量、响应时间的对比,见文档:http://www.talkwithtrend.com/Document/detail/tid/433445
市场号称能做交易或专注做交易产品的分布式事务情况如下:
1) 专注OLTP分布式数据库产品:Oceanbase 、HotDB 做到了等同 集中式数据库 的 事务一致性 和透明性,TDSQL、GoldenDB、DDM、GaussDB T依然是采用外接GTS服务或zookeeper的模式,属于柔性事务
2) 专注多模HTAP分部署数据库产品: SequoiaDB 准确说不支持 、TiDB 还未等同集中式数据库的 事务一致性 和透明性 ,另外响应时间 和吞吐量是大概是 蚂蚁金服Oceanbase 和热璞数据库HotDB的 25%。
3)、OLTP分布式数据库厂商会走向两极分化: SequoiaDB 和 TiDB 追求多模数据库路线,也即业务场景上支持75%的 OLTP和75%的OLAP (注:交易响应时间不满足高性能要求,分析计算能力不满足大规模数据量计算) ,数据库类型会完全融入 KV文档类型类MongoDB语法,及兼容MySQL 语法、PostgreSQL语法; Oceanbase 、HotDB 、 TDSQL、GoldenDB、DDM、GaussDB T 100%专注OLTP分布式数据库 方向,语法及生态完全融入MySQL体系,兼容Oracle数据库语法。
总结:
衡量分布式事务数据库产品的分布式事务能力,从: 业务代码是否要修改或做特殊设置等、数据一致性是否等同集中式数据库、吞吐量能否水平扩展数十倍 集中式数据库产品(或等同Oracle/DB2 跑中高档小型机/AS400等的吞吐量)、响应时间可控(注:假定网络时延足够小时,银行转账业务场景能否控制 200毫秒以内)、事务中的锁为悲观锁、事务中的死锁自动发现和自动解除