前言：中国人民大学常被誉为是“中国人文社会科学的高学府”，其实人民大学也是“中国数据库的发源地”。由中国人民大学教授萨师煊与王珊合作编写的《数据库系统概论》是国内部系统阐明数据库原理、技术和理论的教材，也被公认为是国内数据库领域的经典权威教材。
近期，蚂蚁金服研究员、OceanBase团队创始人阳振坤受邀在人民大学分享了分布式关系数据库OceanBase如何登顶国际TPC-C benchmark排行榜，并对这一突破背后的技术创新进行了深入的解析。
数据库：技术和市场的“死亡之谷”
数据库的概念早源自上个世纪60年代。到了70年代，关系模型已经诞生。80年代关系数据库逐渐成为整个社会的信息基础设施。2000年伊始，随着互联网的发展，业务系统对数据库的需求发生了很大的变化。在过去，传统的数据库并发访问量从几百到几千。进入互联网时代后，并发访问量骤增，达到百万至千万的级别。越来越多的公司发现根据现有的并发量和数据量，不仅他们买不起传统商业数据库，而且传统商业数据库也无法容纳和处理他们的数据量和访问量。
从2006年开始，大量新的非关系型数据库如雨后春笋般涌出，在整个数据库行业掀起了一场空前盛大的NoSQL革命。早在 2006年，Google Bigtable发表，随后HBase，HyperTable，MongoDB，Redis相继问世。火热发展的云计算带来了对更大规模数据库的需求。过去的业务大多类似商场开业，从选址、装修到IT设备的采购，至少需要一个季度甚至半年时间。如今业务部门从采购到上线，时间缩短至数小时，甚至很多业务要求像租用云计算服务一样，能够即拿即用。
云计算改变了已有模式，这时候传统关系数据库的缺点也进一步凸显：不能水平扩展、容量小、处理能力不够、成本又非常高。甚至很多人断言，关系数据库正在走向末路，然而时至今日，关系数据库依然是整个社会的信息基础设施，承载着整个社会重要程度高、访问量大的数据。
关系数据库从诞生起已经有几十年的时间了，但基本上它的市场格局没有太大的变化。早的几家霸主直至今天依然占据着统治地位。关系数据库虽然很重要，但是它在整个IT系统的成本里却并占据非常大的比例。关系数据库处在整个产品或者产业链底层的位置，替换风险很大，迁移的成本很高，因此非常难以被替换。这就导致了数据库变成了一个门槛极高、强者恒强的领域，后来者很难居上。
谈到关系数据库，准确地说用于在线交易处理的关系数据库，在我看来这是所有软件中难的。首先一个重要的难点在于它需要支持数据库事务即ACID，其次在于SQL优化器，这两点就占据了数据库中很大部分的工作量。同时，在线交易处理关系数据库的技术门槛也非常高，我们常说有三个“要”：1）既要：数据一条不能错；2）又要：服务片刻不能停；3）还要：交易处理高并发。基于如此高的技术门槛，这也意味着在线交易处理数据库注定是一个非常艰难的领域。
前有先行者挡道、后有NoSQL追赶，在大部分人看来，很多人都觉得这不是做自研关系数据库的好时机。但仔细分析后，会发现这是个千载难逢的好机会。
天时地利人和铸就OceanBase开创性的革新
2010年加入阿里巴巴后，当时很多人都看到单机数据库已经走到了尽头，我想如果能将分布式的核心理论揉到数据库里，解决单机数据库的水平扩展问题，对当时整个互联网的基础设施乃至整个社会的信息基础设施都会是一个非常好的机会。我当时找了几个同学想要一起做这件事，跟我一样，这几个同学都有分布式背景。尽管研制关系数据库充满了挑战，但我们得到了千载难逢的天时地利与人和的机遇。
“天时”是互联网的爆发式增长对数据库的高并发、大数据量提出了很高的需求，而传统关系数据库难以满足这个需求；“地利”是阿里巴巴内部从淘宝到支付宝拥有大量使用数据库的场景，OceanBase可以从不是特别关键的应用场景开始尝试，一步步地将数据库做到关键系统；“人和”是当时单机数据库已经走到了尽头，下一步一定是走向分布式，而当时团队成员大多是分布式技术背景，做的就是自己擅长的工作。
2010年6月25号OceanBase项目正式立项。项目创立之初，我们给自己定了两个小目标：是硬件性价比做到Oracle的十倍，第二是做到可水平扩展，因为这是OceanBase的根基。
传统数据库常常被人诟病，因为它有两个本质的缺陷：首先是传统的OLTP数据库不能水平扩展。由于不能水平扩展，机器只能越做越大，价格甚至几何级数的增长。
第二就是主库备库的数据不一致。主备镜像无法做到数据可用性跟一致性两全：主库备库的完全一致意味着每一笔事务都得从主库同步到备库，备库确认后才能应答。假如这中间网络出现问题，或者备库出现问题，所有的同步都会被堵塞，也就是所有的写操作都无法进行。因此主库一旦出问题，数据是有损的，所以企业只能买可靠的设备，从四个九到五个九，就是为了让这些机器不出一点问题，可想而知这样的设备肯定便宜不了。不论是软件还是硬件都便宜不了，服务自然也便宜不了，这就导致数据库成本非常高。
如果分布式数据库是一条康庄大道，这条路可能早就被无数人踏过。分布式OLTP数据库其实是一条非常难走的路，因为分布式数据库的一个核心问题就是单机故障会引起整库故障。随着机器规模的增大，机群故障率会指数级的提高。由于主备镜像无法做到数据可用性跟一致性两全，因此无法采用主备镜像或类似手段解决分布式数据库的节点故障的问题。 对于银行和企业的业务来说，可用性跟一致性是一个生死两难的问题，要保证同步，就面临着业务不可用的风险。所以银行往往会购买可靠性更高的存储和服务器等硬件。可靠性高的硬件自然价钱也非常高昂。因为分布式里每一个节点在任何时刻都可能会故障，不管这个节点本身的可靠性有多高，它都有故障的可能性。一直以来，我们工作的重点之一，就是围绕如何提升分布式整体的可用性。如果解决了这个问题，不再需要高可靠的硬件，也不用在意主备库是否一致和水平扩展的问题，很多问题都能引刃而解。
所以OceanBase采用了Paxos分布式一致性协议，它也是OceanBase整个分布式数据库里核心的基础之一。它本质上解决的一个问题就是用不可靠的成员来提供可靠的服务。也就是哪怕单个节点不可靠，只要大部分节点正常工作时这个系统就能正常工作。传统数据库中五个九的设备非常昂贵，OceanBase则基于普通的PC服务器，且不要求设备有很高的可靠性，只要两个九到三个九，整个系统就能够工作得很好，这一创新的技术突破大大提升了性价比。
那么，OceanBase是如何用Paxos协议来做成这件事？我们前面简单分析过，不可能既保证高可用，又保证主备库完全一致，因为这两个需求是矛盾的。然而Paxos协议却提供了一个迂回的解决方案，即多数派。举例说明，主库中的每一条日志会同步给两个备库，只要有一个备库收到，就能达成一个多数派协议。简而言之就是三者中有两个同意，少数服从多数，就认为这件事情成功了。那么这种情况下，任何一个节点坏掉，刚才的这笔事务也至少会在剩下两个节点中的其中一个节点有。所以哪怕是主库故障了，那么两个备库会互相握手，相互把缺失的数据快速补齐。恢复时间OceanBase通常不会超过30秒。
有同学肯定会问，你们用的都是廉价的服务器，万一三台中坏了两台怎么办？虽然在实际生产中三台坏两台的概率特别小，但是其实也有过类似的事故。所以接下来在生产系统中，大部分都换成了五节点。五个节点里需要有三个日志写成功，这种情况下，即使同时坏了两个节点，生产系统也完全不受影响。虽然提高了成本，但是比起整个系统的可用性来说，是一个能够接受的代价。接下来就是怎么解决分布式事务的问题。分布式事务两阶段提交模型虽然看起来相当美好，但是实际上一旦节点在第二阶段出现故障，则事务既无法提交也无法回滚，只能被挂起，在实际生产系统中，这会导致数据库的连接迅速被耗尽，从而使得服务中断。OceanBase做了一个小小的改变：我们把原来的每一个物理节点换成一个Paxos组，相当于换成一个虚拟节点，这个虚拟节点背后有三/五个物理节点。根据多数派成功协议，三/五个节点里有两/三个节点写成功这个事务就被判定为成功。实际上使用了这样一种方式解决了我们提到的万一有一台机器故障，两阶段提交就没办法推进下去的问题。我们就是通过这样一些看上去相对简单的方式解决了分布式事务的问题。其实，无论是主库备库不一致还是分布式事务的缺陷，根本的原因是传统关系数据库软件自身高可用的缺失，即传统关系数据库都是通过外部硬件来保证可用性，而没有从数据库系统内部来解决问题。
OceanBase征战TPC-C的艰辛之路
TPC-C benchmark诞生于上个世纪80年代，ATM自动提款机问世以后，数据库厂商都希望推销自家的在线交易处理系统。各个数据库厂商在在线交易处理的benchmark上各自为政，一直没有一个统一的规范，既缺乏足够的说服力，用户也无法在各个系统之间进行参照和对比。
就在这时，Jim Gray联合多位学术界、工业界的权威人士提出了DebitCredit标准。标准虽然出了台，但是数据库厂商却并没有严格按照标准测试，而是肆意篡改标准让自己跑出更高的结果。这就好比有了法律却没有执法的队伍，每个人都按照自己的理解来解释法律和执行法律。
Omri Serlin非常了不起，他说服了8家公司成立TPC组织，并且制定了TPC系列标准，相当于立法；同时TPC组织还负责监督审核测试过程和测试结果，相当于执法。从这之后，数据库领域各自为政的benchmark才有了一个统一的标准。
目前，TPC-C benchmark在国际上被认为是重要、权威的标准之一。TPC-C模型本身看起来很简单，就是五种事务的模型。但即使在今天在各个行业，包括电子商务、银行、商场、交通、通信、政府、企业里等等这些业务的抽象依然都是TPC-C模型。
当我们完成了TPC-C的优化工作以后，我们发现今年双11的OceanBase的性能目标已经提前达成，这也是因为TPC-C是实际生产系统很好的抽象，尽管实际的生产系统更复杂。TPC-C制定了五种事务的百分比，分别是：订单创建(<=45%)和订单支付(>=43%)以及订单查询、订单配送和库存查询各(>=4%)。其中，还有一些限制，比如规定每个Warehouse多只能贡献12.86tpmC（tpmC即订单创建每分钟所执行的数量）。所以这会导致一个直接的结果，性能与数据量成正比，也就是要跑更高的性能，自然需要更多的仓库。每个仓库的数据大概是70MB，同时TPC-C还要求满足60天压测的存储容量。OceanBase跑了6088万tpmC，对应的存储空间是PB级别的。
TPC-C的测试和审计是一个特别严格的过程，OceanBase团队前前后后花了接近一年的时间才完成。TPC-C审计要求首先做功能的验证，也就是数据库事务的ACID。等功能验证通过了以后，才能跑性能。跑性能则有两个要求：，要求8小时稳定运行，没有任何人工干预的运行；第二，性能采集至少进行2小时且期间的性能波动不超过2%。这些都是实际生产系统的要求。
整个测试不限硬件和软件，只要能够通过测试（需要公开系统组成和价格）。
TPC-C benchmark记录分为几种：in-review，active，history。当结果刚做出来，审计通过之后，在网站上的状态是in-review，即公示期，这个公示期是60天。在公示期之内，任何人都可以对该结果提出质疑，测试厂商必须要解释清楚这个质疑，甚至有可能再跑一遍benchmark。与此同时，TPC也规定一旦进入in-review的状态，厂商已经可以对外宣传。当然与此同时，厂商也需要承担一定的风险：如果后的结果被人质疑并且没有通过，这个结果是会被撤销的，被撤销的结果在TPC网站上是查不到的。
所以在整个测试过程中，OceanBase用的都是保守的方式，用高的要求，比如性能采集，OceanBase使用的不是2小时而是8小时，在整个8小时中性能波动不是<2%而是<0.5%，这使得OceanBase后测出的性能曲线几乎是一条直线。全球一共有3位TPC-C的审计员，都在美国，这次OceanBase的TPC-C测试是由其中的两位审计员联合审计通过。还有一种记录是active，就是公示期结束之后的结果，这时用户可以用披露书上价格买到整套系统。另外一种记录是history，记录依然是有效的，但由于时间等原因系统的部分组件（特别是硬件）不再有售，因此整套系统不再完整有售。
肯定会有人好奇，在整个TPC-C的历史上， IBM也曾经高居榜首几个月，然后很快被Oracle超过了。为什么Oracle结果已经出来九年多了，这个期间没有厂商测出更高的tpmC，包括Oracle自己？
个原因是测试TPC-C benchmark的投入。进行TPC-C测试需要投入人力和物力，传统数据库厂商要测出一个较高的tpmC，高端服务器和高端存储是一笔不小的投入。这个投入不是披露书中的成本，后者是整个系统三年的总体拥有成本，比如OceanBase披露的大约是3.8亿，这实际上是整个系统三年所有的成本，包括软件、硬件和服务的总体拥有成本。得益于阿里云公有云虚拟机的按需租赁，OceanBase实际的测试成本跟这个三年总体拥有成本相比有不止一个数量级的差距。
第二个原因是即便参与，如果后的结果依然不如Oracle，主流厂商很可能宁可不测。没有挑战，那么Oracle自己也没有必要和动力去刷新这个记录，况且做更高的tpmC至少要花千万计的美元，是一个不菲的成本。Oracle在这9年多的时间也不是什么都不做，它至少做了两件事：，2012年Oracle用X2-8 x86Server单机测出500万tpmC，第二，又过了一年，2013年Oracle用T5-8 SparcServer单机测出850万tpmC。Oracle在测出3000万tpmC时用了27台服务器的RAC，500万tpmC乘以27，甚至850万乘以27，哪怕结果做不到线性，也会是一个上亿的结果。竞争对手如果没有把握，就不会轻易去挑战。OceanBase之所以敢于挑战，就是因为自身的分布式水平扩展能力，而RAC的有效节点数是十分有限的。
坦率的说，OceanBase跟Oracle比在功能上还有不小的差距，单机的性能也有距离， OceanBase大的优势是可以用多个廉价的服务器达到昂贵高端硬件所能达到的性能以及更高的可用性。
从OceanBase立项天起，我们的目标就是做一款通用的数据库。当我们在解决了内部用得好的问题以后，我们就把更多的精力投入到外部市场上。所以OceanBase自2017年对外商用以后，今天已经在几十家商业银行落地应用。未来，OceanBase还有很长的路要走，比如在走访客户的过程中我们发现，绝大部分业务既需要OLTP又需要OLAP，而这正是OceanBase的产品目标：同时支持OLAP和OLTP，即HTAP。TPC-C是一个很好的起点，我们也希望基于这个起点能够不断磨砺产品，让这样一款通用型的数据库未来能够为整个社会提供更好的服务。
