2021年春节临近，所服务的头部客户数据库系统也开始面临全年最高峰值长时段性冲击。同事们在现场维护的同时，也在讨论分布式数据库是否也可以很便利地支持客户业务平稳运行。这个议题很大，但不针对具体业务特性和基础架构具体配置，横向对比其实意义有限，因为不同类型数据库没有机会同时服务同一个应用获取有意义的细粒度技术比对数据。另外，功能层面满足与否，也只是冰山露出水面的部分。架构决策层面的问题，集中式或者分布式，尺有所长，寸有所短，本质还是选择约定上下文环境中解决特定问题的最优解。
但这个讨论触发了我去分析OceanBase TPC-C测试报告，剖析OB支持高并发联机处理系统的细粒度数据。 闲话少絮，数据为先，两次TPC-C测试的重点关注项与对比表。
数据加工完成后，觉得有意思的一些点：
§ 测试基本情况：OB的两次测试间隔7个月，版本均为OceanBase v2.2 企业版，包含分区、水平扩展和高级压缩功能。
§ 3年TCO数字惊人。咋一看，不管是2019年的3.8亿，或是2020年的28.1亿，均是对上云成本优势说法的巨大心理冲击！28.1亿这个数字包括了1960个云主机3年软、硬件和维保费用（1557个数据节点，3个OCP管理节点，400个客户端节点），但不包括企业客户的一些必选收费项，如流量带宽、负载均衡、安全服务等。如真有高流量数据库负载上公有云，成本分析和弹性扩缩容一定要做仔细，不然成本可能不降反升。
§ 性价比显著提升，总的tpmC上涨10.6倍，成本降低36%，应该主要是得益于单节点算力密度的增加，CPU超线程数由64增加到84，内存由512G增加到712G，NVMe盘由1.7T增加到3.5T，高负载数据库+高配机器黄金搭配的合理属性在云时代依然没有改变。
§ 良好的水平扩展能力，节点数量由207台增加到1557台，节点数增加652%，超线程数增加887%，而tpmC增加1062%，证明了系统极强的水平扩展能力。
§ 数据规模： 数据库总数据量由553TB增加到5.9PB，从TB级迈入PB级；内存容量和总数据量比例为18.8%(2019)和17.9%(2020)，系统会有读盘请求。不过从TPC-C测试场景来看，对于OB LSM引擎是非常友好的，占比90%的新订单创建与支付交易操作产生的数据应该可以几乎全部命中内存，内存使用效率高。
§ 响应时间：按照所有交易权重平均响应时间约120毫秒（2020较2019下降10%），对比我们日常运维的高TPS交易系统，响应时间差不多高了一个量级，但这个响应速度是在225万/秒（2019）和2600万/秒（2020）TPS多了不止一个量级的情况测出来的，而且90分位加权平均响应时间150毫秒（2020较2019下降28%），持续8个小时测试，吞吐抖动不超过2%，说明系统鲁棒性是非常好的。
§ 单数据节点处理能力：单节点处理能力数字惊人，单节点TPS 达到16809，SQL语句处理能力达到46.5万/秒。单节点达到这个量级的处理能力，原因一方面是TPC-C测试表少，SQL语句相对简单，交易单一导致占比90%的高频交易几乎全部内存操作。同时， OB事务引擎MVCC读写无锁设计、池化的内存管理和libeasy框架的高并发处理能力等应该是另外一个方面。
§ 单节点处理能力的引申：基于OB数据库的架构特性，提高单点处理能力最关键的配置项应包括：高性能CPU（主频高，核数多，超线程数目大），内存大（准内存数据库），高网络带宽（Paxos强同步redo log和分布式事务两阶段提交），IO高效（日志落盘持久化），压缩算法高效（最好有芯片级硬件加速，减少多副本存储成本）。
§ 分布式事务：系统整体提供了百万级的分布式事务处理能力，从24.7万/s增加到286.95万/s。从单节点来看，尽管由于整体负载和节点数目巨大变化带来系统整体分布式事务的巨大变化，但每节点上实际执行分布式事务的比例并没有变化，还是在11%左右。这个比例，对金融交易来说，可能对快捷支付类交易有一定的参考性。对其他金融交易来说，考虑到其访问表的数量和单交易SQL语句数目存在数据量级差异，参考性较弱。如果要全盘引入分布式数据库支持全量业务，应用逻辑和数据分布需根据数据库的特性全面重新设计，最贴近的比喻是回到2000年初的物理大集中阶段。往好的方向想，就是历史总是螺旋式上升的。
§ 极致优化的测试：细读报告，可以看出测试过程降低硬件成本和提高性能的某些极致优化点。当然这个是规则允许的，不然通不过审计。 与阿里正常宣讲的3副本或者5副本的部署方式不同，OB在TPC-C测试中，3个副本不是对等的，只有2份数据。其中1个完整副本包含redo log，LSM内存表，SST数据，这里隐含的意思是这个副本会做compaction；第2个副本只包含redo log，SST数据，它应该是在主副本完成compaction之后从主副本直接拷贝SST；第三副本只包含redo log，没有数据。因此这里可以看出：整个1557台节点的内存基本都可以用于事务读写，两个副本基本没有内存开销；整个1557台节点的硬盘，用于存储2份数据文件而不是3份。之所以可以这样，是因为TPC-C并没有规定或考察RTO时间，所以只要保证RPO为零就行了。另外的一个例子是： 有10万条记录的小表Item，复制到每个数据库节点，也就是有1557份（item表的建表语句如下图）。金融级客户肯定不能这样部署，所以前述数字参考性要仔细考量。
§ 
§ 考虑TPC-E 测试。TPC-C测试历史悠久，从1992年就开始了。模拟一个零售商的货物管理业务。该零售公司有N个仓库，每个仓库有10个终端，每个终端服务1个地区，每个地区服务3000名顾客。测试数据库测试定义了9张表，5类交易（新订单创建，支付，订单查询，配送， 库存查询）。其中订单创建和支付交易比例约45%，订单查询、配送和库存交易各约4%，另外要求10%新订单交易跨仓库，15%支付交易跨仓库因此会出现一定比例分布式交易。更多关于TPC-C测试的信息，可参考其官网。TPC-C测试具有一定的行业通用性，市场接受度也比较高。OB首先进行TPC-C测试完全可以理解，但考虑到分布式数据库已有了一定的行业应用度，要摘取皇冠上的明珠（比如金融行业最极致OLTP应用核心数据库）， 同业后续如继续进行测试，应该考虑TPC-E测试。TPC-E历史同样悠久，2007 年 2月已开始启用， TPC-E基准描绘的是券商业务金融性质交易，对金融行业参考意义更大。TPC-E 涉及 12 个不同类型交易的和 33 个表。TPC-E 由于其不同的事务类型、更复杂的数据库和整体执行要求，因此比TPC-C复杂，但行业参考性强。国内有厂商参与，比如2019年联想ThinkSystem SR860 V2 + 微软SQL Server2019企业版的TPC-E测试。
回到本文最开始的问题，OceanBase问鼎TPC-C，证明了share nothing架构分布式数据库在性能、可用行、扩展性、强一致性上的巨大进步与突破，虽然报告惊叹的数字如上文分析，只能在一定程度上参考。结合国内大家可以看到的案例，如OB在南京银行、西安银行、广东农信；TDSQL在张家港农商核心系统、平安银行信用卡；GoldenDB在中信和交行信用卡；TiDB在平安寿险核心、北京银行支付清算等案例也证明了分布式可以和共享存储架构集中式数据库一样支持高并发OLTP场景。但这个”高并发“的细粒度数据，运维/非功能层面遇到的挑战和应对思路，希望这些先行者能在合规前提下分享给同业及公众，毕竟技术交流无问西东，实事求是就好。
最后，希望分布式数据库沐浴在自主可控的春风中，加速发展、快速迭代、继续投入，拓展出更加美好的未来。
=====================================================
参考文档与致谢：
http://tpc.org/1799
http://tpc.org/1803
http://tpc.org/results/individual_results/ant_financial/ant_financial~tpcc_alibaba_cloud_elastic_compute_service_cluster~es~2019-10-01~v02.pdf
http://tpc.org/results/fdr/tpcc/ant_financial~tpcc~alibaba_cloud_elastic_compute_service_cluster~fdr~2019-10-01~v01.pdf
http://tpc.org/results/individual_results/ant_financial/ant_financial~tpcc~alibaba_cloud_elastic_compute_service_cluster~es~2020-05-17~v01.pdf
http://tpc.org/results/fdr/tpcc/ant_financial~tpcc~alibaba_cloud_elastic_compute_service_cluster~fdr~2020-05-17~v01.pdf
http://oceanbase.org.cn/?p=312 致谢郁白
http://tpc.org/4087
