蚂蚁金服高级研究员兼 OceanBase 数据库创始人阳振坤，在发布会分享了《OceanBase：面向未来的企业级关系数据库》，以下为演讲实录：
10月2日，OceanBase 数据库 TPC-C 基准测试结果发布，今天我想跟大家汇报一下它背后的一些东西，然后给大家简单讲一下我们的技术方案，以及给大家介绍 TPC-C benchmark 以及 OceanBase 进行测试认证的一些事情，最后是个简短的小结。
我们做的是在线的交易处理系统（OLTP），但更大的意义不在于 benchmark 本身，而在于我们改变了关系数据库做交易处理的方法，把它由一个集中式系统，变成一个分布式系统。另外，更大的意义不是 OLTP 本身，而是在 OLAP 上。大家可能觉得奇怪，你做的是 OLTP benchmark，它的价值怎么会在OLAP上呢？
首先介绍下数据库和业务应用的背景。可以看到当前的集中式数据库所面临的挑战，要做数据库产品的研发首先要有业务需求，数据库经过一些年的发展，到了80年代中期自动提款机出现之后，数据库非常重要的特性开始得到普遍的应用，就是在线的交易处理。
后续很多年数据库就围绕这个继续发展，之后企业发现还需要商业智能：需要报表，需要对销售结果进行探讨、进行对比、进行分析等，所以数据库除了在线交易处理的能力之外，还需要在线分析处理的能力，传统的商业数据库在这两个能力上其实做得非常好。
但最近这些年情况发生了变化，原来由同一个关系数据库做的 OLTP 和 OLAP 这两件事情变成了由两个系统来做：关系数据库分库分表继续做在线交易处理，数据仓库则做商业智能分析即在线分析处理。
为什么会出现这样的情况？因为互联网。互联网在短短几年时间里，把整个交易量、数据量翻了几百倍几千倍，发展最快的单个硬件仍然赶不上这个速度，单个硬件就算能够有这个处理能力和容量也肯定不经济。
这样一个系统变成两个系统带来很大的不便。首先，数据仓库本身没有数据，数据还得从交易处理数据库来。所以还得架一个桥梁，把数据从交易数据库通过ETL即抽取、转换然后加载到数据仓库，而且这个本质是非实时的，否则的话数据仓库就成为了交易数据库。
其次，交易数据库分库分表后也带来了很多挑战，比如订单号需要全局唯一，如果只有一个数据库这件事情很好办，多个数据库是需要在订单号中加一位代表哪个分库库，而每个分库能做到唯一。当你分库变成两位数变成三位数怎么办？这是业务扩容，如果是业务缩容呢？所以业务需要做很多的改动。
第三是数据仓库本身，数据仓库天然是面向某个主题的，从来没有听说过关系数据库面向某个主题，关系数据库就是关系数据库，你可以根据需要建索引，可以根据需要建物化视图等，但数据仓库只能是面向某个主题的。如果有多个不同的主题，就要建好多个数据仓库，尽管可以把相近的主题合并在一起，但这并不能改变数据仓库面向主题的本质，它会造成大量的数据冗余。另外一个问题是时效性，因为数据仓库本质上不是实时更新的。
交易处理数据库不能扩张，是因为它是集中式。集中式的根本原因还是由于交易处理最重要的一个特性，即事务的 ACID，原子性、一致性、隔离性、持久性。数据库发展了半个多世纪，做交易处理的一直都是集中式系统。
另外一个原因是在线交易处理系统要求非常高的可用性、可靠性，分布式系统有一个固有的缺陷就是可靠性：多台机器在一起的时候，整体可靠性是指数级下降，除非你有特殊的技术。比如当你把一百台5个9机器放在一起的时候，整个系统只有3个9的可靠性，任何一个关键业务都不敢使用3个9可靠性的系统。
这两个原因使得多年来交易处理的系统一直是集中式。我们做 OceanBase 分布式的交易处理系统的时候，就出现很多的质疑，这个质疑声一直到去年还有。最后公司下决心说好吧，我们就做一次在线交易处理的 benchmark 的认证，这个 benchmark 不仅是跑分，首先你要证明你的系统能够做交易处理，能够满足事务的 ACID，原子性、一致性、隔离性、持久性，只有通过 ACID 测试才能进行下一步测试，所以这个TPC-C benchmark不是像有人说的那样，堆砌机器就可以跑个高分的。
假如图中这个球代表一百块钱，金融场景里最常见的是A转一百块钱给B。这个转账过程最大的困难是它的过程必须是原子的，即没有中间过程：这个钱只要A这边转出去，B一定就收到了；如果B没有收到钱，同一时刻A一定没有转出这个钱。
如果这两个账户在一台机器上，这个事情可以有比较成熟的做法；如果是在两台机器的话，这件事情变得非常困难，怎么样协调两台机器同一时间做这个事情？数据库设计者把这个事情做了两个阶段，第一阶段要检查A帐户，看它能不能转钱，也要检查B帐户，看它是不是存在，是否能够接收转入。这些检查如果有一个不合格转账就要取消掉，比方说没钱拿什么转账；这些检查如果都合格了就进入第二步：通知A扣一百块钱，通知B加一百块钱。
这个做法其实有一个大的缺陷：如果第一阶段检查都是好的，在第二阶段A这个机器突然出了一点问题，怎么办？B那边一百块钱还加不加？按协议第一阶段都正常，那么B的一百块应该加，但假如A这台机器彻底坏了，拿一台备机来，备机没有这个转帐信息，它根本就不知道曾经有这个转账，这样整个系统里多了一百块钱出来，不知道哪来的；如果B的一百块钱不加，假如A这台机器只是 CPU 负载高、网络特别忙阻塞了一会儿，过一会儿又正常了，把这100块钱扣掉了，B不加这一百块钱也不对，所以就出现B加也不对，不加也不对，这导致很多年来没有分布式数据库能够用来做交易处理。
是否有个交易处理的系统能够做到随时可以扩展也随时可以收缩呢？这正是2010年公司立项做 OceanBase 的目标。
OceanBase技术方案
OceanBase 项目最早做这件事情首先是有市场驱动的，我们的访问量、数据量都比以前涨了几十倍，甚至几百倍，用传统的数据库很困难了，或者说买不起数据库了。
第二，因为在线交易处理是一个实时系统，不能停，否则大家拿支付宝吃个饭、坐个车都不行。
第三，数据库的数据还不能出错，可是软件哪能没有 BUG 呢？所以一个做实时交易处理的数据库系统不只是研发出来的，更是用出来的。当时的淘宝和支付宝就有成千上万的数据库，有这么多的数据库对于这个项目来讲有两个好处：一是经济价值足够大，不用给商业数据库系统付那么多钱；二是这么多的业务提供了一个土壤，让新的数据库成长起来。我们总是讲农村包围城市，总能找到相对边缘一些的业务。
OceanBase项目一开始的时候，就设定了两个重要的目标：
1. 这个系统要能够水平扩展；
2. 这个系统必须高可用的，尽管使用普通的硬件。
现在让我们看看 OceanBase 是如何解决高可用的问题的。
这个图是传统数据库主备镜像的示意图：主库做事务，并同步给备库。如果要求备库跟主库完全一致，那么每一笔事务都要实时同步给备库，如果备库出现异常或者主备库之间的网络异常，那么主库上的事务就会积压，并且会在很短时间内撑爆主库，然后导致业务不可用，这可能比数据差错更糟糕。大家会问数据仓库也是分布式，它怎么不担心机器坏？根本原因是数据仓库的数据不是实时更新的，如果出现上面的异常，它可以暂停更新。
我们的做法是增加一个备库，主库同步事务到两个备库，只要一个备库收到，加上主库自己至少两个库收到就可以。这个里面关键是多数派，每一笔事务至少在3个库中的2个库落地，任何一个库坏了，哪怕主库坏了，每笔交易至少在一台机器上存在。我们通过这个方法，把系统做到高可用。
同时坏两台机器的概率，如果是自然损坏确实很低，但如果有人为因素，就不一定了。比如说人为把机器关掉，换一个组件做升级，加上自然损坏，可能出现同时两台机器故障。所以比较重要的业务会写五份事务日志，有三份数据或者是四份数据。即使人工关掉一台机器，自然再故障一台机器，整个业务系统还是可用的。
回到刚才的分布式事务，OceanBase 的方法是：我们把原来的每一个物理节点换成一个 Paxos 组，相当于换成一个虚拟节点，这个虚拟节点背后有三/五个物理节点。根据多数派成功协议，三/五个节点里有两/三个节点写成功这个事务就被判定为成功。实际上使用了这样一种方式解决了我们提到的万一有一台机器故障，两阶段提交就没办法推进下去的问题。我们就是通过这样一些看上去相对简单的方式解决了分布式事务的问题。
OceanBase 比较早在建设银行就有了一些业务。蚂蚁金服绝大多数的数据库都在 OceanBase，还有一部分在持续迁过来。阿里巴巴是最早立项目用的，后续包括网商银行、南京银行等金融机构也在把一大批业务迁到 OceanBase 上。西安银行是今年发展起来的业务，已经把Oracle业务迁移到 OceanBase 上。
TPC-C基准测试
TPC-C benchmark 诞生于上个世纪80年代，ATM 自动提款机问世以后，数据库厂商都希望推销自家的在线交易处理系统。各个数据库厂商在在线交易处理的 benchmark 上各自为政，一直没有一个统一的规范，既缺乏足够的说服力，用户也无法在各个系统之间进行参照和对比。
就在这时，Jim Gray 联合多位学术界、工业界的权威人士提出了 DebitCredit 标准。标准虽然出台了，但是数据库厂商却并没有严格按照标准测试，而是肆意篡改标准让自己跑出更高的结果。这就好比有了法律却没有执法的队伍，每个人都按照自己的理解来解释法律和执行法律。
Omri Serlin 非常了不起，他说服了8家公司成立 TPC 组织，并且制定了 TPC 系列标准，相当于立法；同时 TPC 组织还负责监督审核测试过程和测试结果，相当于执法。从这之后，数据库领域各自为政的 benchmark 才有了一个统一的标准。
TPC 的 Benchmark 后来不断的修订，这些年修订了很多版本。一方面适应业务的变化，另一方面是软件硬件的变化。即使放在今天来看，它还是一个普遍适用的场景，不管是金融、交通、通讯等，还是一个非常普遍适用的场景。
TPC-C 测试一共五种事务。里面最多的是订单创建，又叫交易创建。TPC-C 模型是一个销售模型，最多是15件商品，平均是10件商品。模型是以一个仓库为单位，每个仓库有10个销售点/仓库，每个销售点服务3000个顾客，这个测试是模拟其中某一个顾客到销售点买东西，买的东西可能是5件，可能是15件，因为买的东西不一定都在本地仓库里有，所以每件商品假设有1%概率在别的仓库，每个订单创建的事务如果在分布式系统里有10%的概率是分布式的事务。还要模拟整个订单创建里面有1%订单是要回滚掉。整个性能指标 tpmC 是每分钟订单创建的数量，假设100笔事务其中有45笔是订单创建，还有55笔是另外的，其中订单的支付是43笔。订单支付里面有15%概率不在本地仓库支付，要到异地仓库支付，也变成分布式事务。
这是 TPC-C 测试的模型，模拟一个人到一个销售终端买东西。你的请求会发到一个应用系统去，可以想象应用系统是一个简化版的淘宝或者支付宝。然后你的请求会发到数据库里去，整个应用系统和数据库都要公开，你用什么机器，机器配置是什么，包括价格都要公开。终端模拟器不要求公开。这里面有很多硬要求，仓库里面有9张表，每张表有多少数据，每个数据有什么样的分布都有规定，如果你不符合就不能进行测试。
每个仓库最高只允许达到12.86个 tpmC。我们做的6000万 tpmC，大概按照这个比例大概需要480万的仓库，整个算下来数据336T左右，我们的数据是乘以2的。规范定义的系统单个部件允许失效，如果用了共享存储，就是说共享存储里允许单个部件失效，大家知道共享存储里单个部件失效，共享存储肯定不会失效，我们没有用，我们就是用的虚拟机。如果想通过这个测试，只能把每份数据写两份，这样任何一台机器坏掉，我们的系统还能正常工作。
另外，你在做性能之前必须先测功能，功能有很多，其中比较关键的是要证明你满足数据库事务的功能，就是原子性、一致性、隔离性和持久性。隔离要求串行化，这也是比较难的事情，尤其是分布式数据库。今天分布式数据库中除了 OceanBase 可以做到，还有就是 Google Spanner。
另外，跑性能则有两个要求：第一，要求8小时稳定运行，没有任何人工干预的运行；第二，性能采集至少进行2小时且期间的性能波动不超过2%。这些都是实际生产系统的要求。这两个小时用来做性能采集，看这两个小时里必须保持着前面的比例，订单创建多大的比例，支付多大的比例，在这个前提之下把两个小时所有订单创建数给记录下来，然后再÷2小时得到真正的 tpmC 值。OceanBase 做了8个小时，审计员看到我们的结果觉得太高，所以，OceanBase 整个性能采集跑了8个小时，而且整个波动小于0.5%，因为我们不想留下任何给别人质疑的空间。
现在结果在公示期，有60天，60天别人说这个结果有不符合规范的地方，或者弄虚作假的地方，你必须要站出来证明自己，我确实符合这个规范和符合标准。60天之后结果就是所谓的 Active，这个时候只要在你所在的地区，任何人都可以以公布的价钱买到这个系统。
很多硬件设备三年之后都不生产了，所以它三年之后就认为这是一个历史的记录，即为 histroy，记录还在那儿，还是有效合法的，但是你买不到系统。
我们比较一下历史上最近的三个结果：
第一，2010年8月份，那个时候 OceanBase 刚刚立项，那个时候还想着怎么样活起来。在 2010年的时候，DB2 用3台 Power 和30台存储做到了超过1000万的结果。结果4个月不到，Oracle 用27台 Sparc 和97台存储做到了3000多万的结果。存储是一个更大的瓶颈。
很多人也在问：为什么 Oracle 后来这么多年没有做？Oracle 不是没有做过，Oracle 在2012年做过一个结果，当时拿X86机器做的，做了500多万。2013年又做过一次，也是单机，拿一个更好的工作站做了800多万。Oracle 已经做了3000多万，为什么做500万、800万这个结果呢？其实我自己的看法是对其他厂商起到威慑作用。这个里面27台工作站，平均一台100万多一点。2012年、2013年做了500万和800万如果你再做，我可以用单机800万做，哪怕不是线性的也是个很可怕的结果。除非分布式有突破，否则没有单机数据库能够达到Oracle这样的性能结果。
我们还有一个变化，没有去买大量的硬件，最后用了204台的数据库服务器，还有3台是管理节点和3台监控节点，一共210台。我们用了虚拟机，虚拟机跟物理机相比，内存、CPU 都提高50%。我们这个结果如果在物理机上跑，会有50%的提升，因为虚拟机还是有一定的消耗。
应用系统用了64台的服务器，这都是要求披露的。有人在质疑你们这么多钱测试一次3.8亿，谁玩得起？3.8亿是说假设一个用户买下系统并且用三年，包括硬件、软件、技术支持全部在内是3.8亿。整个三年的硬件成本是租虚拟机的成本，整个成本大概在系统里面只占五分之一，测试成本大概用租了3个月的机器，找阿里云租的，本身你的硬件成本只占3.8亿的五分之一不到，这还是36个月的成本，实际上我们只用了3个月的成本。大家其实可以把我们整个硬件投入能估算出来的。
我们这个测试更大的价值不在于 OLTP，是想跟别人证明，我们在分布式数据库能做交易处理，更重要是想证明这个数据库既能够做交易，也能做智能场景分析。绝大多数场景下，用户、客户不再需要搭建一个数据仓库，去复制数据、去导数据。否则这样一个系统只是为了做交易，其实它没有足够的价值。
最后是一个简短的小结。80年代后，交易处理和商业智能就成了关系数据库一个核心需求，但是集中式的架构这么多年发展下来，扩展能力有局限，尤其有了互联网、移动互联网出现以后。TPC-C Benchmark 本身无所谓我们做了什么，别人做了什么，它定义的是业务需求。它定义的是订单创建、订单支付、订单查询、订单配送，而这些都是业务需求，只要满足这个业务需求，哪怕拿文件系统去测并且能够测出一个好结果也是本事。
通过这个测试，更多是想证明我们是有史以来第一个分布式数据库具备交易处理的能力，这是以前没有的。也是曾经80年代、90年代末宣判做不到的，OceanBase 接下来做的最重要事情不仅是关系数据库的功能，要做的是把商业智能的能力做进来，能够向客户提供所需要的交易处理和商业智能分析。谢谢大家。