阳振坤：OceanBase 数据库七亿 tpmC 的关键技术 OB君：2020年9月25日

OB君：2020年9月25日， OceanBase在外滩大会举办的“数据库，新标杆，新征途”分论坛正式落幕，内容涵盖数据库的趋势探讨、分布式数据库的技术创新与行业应用，及国内数据库的发展与生态。欢迎持续关注本系列内容~
北京奥星贝斯科技有限公司 CTO 兼 OceanBase 数据库创始人阳振坤，在外滩大会上分享了《OceanBase 数据库七亿 tpmC 的关键技术》的主题演讲，以下为演讲实录：
联机事务处理（OLTP）系统
很多人都清楚事务的 ACID 特性，知道事务要满足原子性、一致性、隔离性和持久性，这是从数据库本身的角度来看。但是，如果站在业务的角度，客户对数据库其实有更高的要求，第一个要求是数据不能错，交易数据是企业所有数据的基础，是最核心的数据，这是企业的命脉。
文章插图
第二个要求是服务不能停，比如最早期的支付宝在后半夜没有业务访问或者业务访问量很少，如今支付宝24小时都有访问，每日高峰的时候峰值甚至比早年的双11还高。所以服务是永远不能停的。
第三个要求是事务高并发处理能力，因为很难预算出有多少用户在同时使用，所以这就需要数据库有高度并发处理的能力。全世界有非常多的数据库厂商，近年来也进入了国产数据库的繁荣时期，但是翻过这座山真正能够把这套系统做到生产中使用的其实少之又少。
TPC-C 基准测试
TPC-C benchmark 诞生于上个世纪80年代， ATM 自动提款机问世以后，数据库厂商都希望推销自家的联机交易处理系统。各个数据库厂商在联机交易处理的 benchmark 上各自为政，没有统一的规范，各自的 benchmark 结果既缺乏足够的说服力，用户也无法在各个系统之间进行参照和对比。
TPC 组织的创始人 Omri Serlin 说服了8家公司成立 TPC 组织，共同制定数据库的系列 benchmark 测试标准并对测试过程和结果进行审计和认证。 TPC-C 是其中的联机交易处理的测试标准，也是国际上最重要最权威的测试标准。 TPC-C 模型本身看起来似乎很简单，也就是九张表、五种事务。但正是这个看似简单的模型，却很好了抽象了直到今天的各个行业业务系统，包括电子商务、银行、商场、交通、通信、政府、企业等等。
TPC-C 的测试和审计是一个特别严格的过程。 TPC-C 审计要求首先做功能的验证，也就是数据库事务的 ACID ，功能验证通过了才能跑性能。跑性能则有两个要求：第一，要求8小时稳定运行，没有任何人工干预；第二，性能测试至少进行2小时且期间的性能波动不超过2% 。这一定程度上证明了系统的稳定和可靠性。
过去从来没有分布式数据库做过 TPC-C 测试。鉴于 OceanBase 存储架构的特殊性， OceanBase 的性能测试是8小时而不是通常的2小时，因此整个8小时中性能波动不能超过2% 。
文章插图
可能有人会说，我可以用很少的数据也能跑出很高的性能，这个数据可以在 CPU 的缓存里，但这是 TPC-C 所不允许的，因为 TPC-C 测试对应的是实际业务场景。在实际业务中，用户数越多，性能越高，数据量也越大。所以， TPC-C 要求性能与数据量成正比。这里我们需要提到 TPC-C 的一个基本概念——仓库，每个仓库最高只允许12.86个tpmC ，大致换算一下，相当于一个 tpmC 对应5.44MB的数据。
另外有一个看起来很宽松的要求，不限制测试的软件和硬件的版本和型号，也不限制软件硬件的数量和规格，但配置和价格必须是公开的，且在市场上可购买的。那么有人会问是否只要堆越多的机器，就能达到越高的性能呢？对于交易处理系统，其实并没有这么简单。
为什么没有分布式 OLTP 数据库产品？
很多人大学里学过分布式事务，有人说两阶段提交如果2台机器能够做， 3台、4台、5台机器也能做，那么用100台、1000台机器，是否就能跑出更高的性能？
可能很多人没有仔细去想这件事，分布式事务两阶段提交其实是理论上的结果，而且这基于很强的假设——假设硬件不出故障，尤其存储不出故障。
那我们看看下面这个模型，假设 A 给 B 转 100 元钱，原来 A 有 900 元， B 有 500 元，转账后应该 A 有 800 元、B 有 600 元，这是很简单的一个流程：第一阶段做准备工作，检查一下 A 账户是否正常，同时检查 B 账户是否正常，任何一个不满足转账条件，转账交易就要被取消，如果两个账户都正常，那就通知 A 扣 100 元，通知 B 加 100元。