共计 4198 个字符，预计需要花费 11 分钟才能阅读完成。
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 元。
这个过程看起来所有都很失常，然而如果其中有一个结点比方 A 这个结点坏了，这怎么办？B 这个结点的 100 元加还是不加，仔细分析加也不对，不加也不对。如果 A 彻底坏掉了，就没有人晓得它已经做过这笔交易，如果 B 加了这 100 元，A 这里没减，这个帐就不平了。那反过来如果 A 这个节点过一会儿又失常了，B 这个节点不加这 100 元也不对，因为 A 的 100 元减掉了，B 的 100 元没有加。那么看起来很简略的一件事，其实做起来就变得很艰难。所以事务处理不是简简单单靠堆机器就能够堆进去的。
那么，又有人会问如果给这两个结点各建一个备库，出了问题用备库来顶上行不行？答案也是否定的。因为主备镜像无奈做到主库与备库完全一致，你要想做到完全一致，意味着每一笔事务都须要从主库同步到备库，这时候整个零碎的可用性的链路变长了。对于银行和企业来说，这是一个生死两难的问题，要保障同步，就面临着业务不可用的危险。所以，主备一致性与服务可用性两者不可兼得。
OceanBase 的诞生契机
咱们后面讲了，交易型数据库很难做，而且做了市场上很可能没有用户敢用，何况它的各方面投入也会很大。而 OceanBase 的诞生和倒退得益于有了百年不遇的天时地利与人和的时机。
“地利”是互联网的爆发式增长对数据库的高并发、大数据量提出了很高的需要，而传统关系数据库难以满足这个需要；“天时”是阿里巴巴外部从淘宝到支付宝领有大量应用数据库的场景，OceanBase 能够从不是特地要害的利用场景开始尝试，一步步地将数据库做到要害零碎；“人和”是过后单机数据库曾经走到了止境，下一步肯定是走向分布式，而过后团队成员恰好具备分布式技术背景。这几个条件一起促成了 OceanBase 的诞生。
OceanBase 的技术架构
多数派 (Paxos) 协定
分布式数据库肯定会面临分布式事务，面临两阶段提交，一般两阶段提交解决不了这个问题，也剖析过之所以出问题是因为对节点的可靠性做了假如。能够回忆一下，如果方才两阶段提交中结点都不出问题，那么两阶段提交是能够工作的。
OceanBase 是怎么解决这个问题的呢？OceanBase 的做法是在原有的根底上减少一个备库，主库同步事务到两个备库，只有一个备库收到，加上主库本人至多两个库收到，这样如果两个备库相当于三个结点三个正本，如果四个备库相当于五个结点五个正本。你坏一个甚至两个结点，数据还在，整个零碎能够失常实现两阶段的提交工作。
OceanBase 分布式事务实现
咱们以三个结点三个正本为例，哪怕坏了一个结点，剩下两个结点每一笔事务至多在其中一个结点上存在，那么能够利用这一点把方才没有进行完的事务或者进行中的事务复原进去，只有复原进去事件就能够做上来，两阶段的提交就能够失常完结。
三代 TPC-C 排行榜榜首
去年 OceanBase 第一次 TPC-C 测试之后，有一些的乐音，大家说你跟九年前的后果比算不了什么，其实是这些人并不理解 OceanBase 登顶背地的真正意义。
OceanBase 的 TPC-C 测试的立项是 2018 年 8 月 16 日，立项前探讨这个事件的时候，大家有肯定的放心，因为从人力物力各方面来看都是比拟大的投入。探讨之后定了两步走的策略，第一步做小一点的规模，目标是把这条路先走通，因为过后全世界还没有厂商用分布式数据做过 TPC-C 测试。起初用了 200 多台的数据库服务器，通过半年多的工夫，最终通过了这个测试。TPC-C 委员会的人对于传统的集中式数据库很相熟，但分布式事务处理数据库，他们也没有接触过。
第一次 TPC-C 测试通过之后，第二次测试的筹备就开始了。因为有了第一次测试的教训，第二次的测试后果是在意料之中的。或者有人会问集中式数据库是否还能跑出更高的性能？家喻户晓，数据库的性能，受制于两个瓶颈，一个是 CPU，另一个是 IO。三代 TPC-C 榜首中，第一和第二代的榜首是传统数据库的代表。第三代榜首是 OceanBase，达到了 7 亿多 tpmC，比二代高了一个数量级。在分布式环境下，OceanBase 的存储是本地盘，这个 IO 能力比共享存储的万兆网卡要更强，最要害是没有数量上的限度，无论是 CPU 还是硬盘数量。
新一代 HTAP 原生分布式关系数据库
讲到这里，可能会有人说，分库分表也能够解决你说到的相似问题。是的，的确会解决一些问题，但有些是很难解决的，比方分库分表后是多个数据库，这多个数据库要放弃 ACID 就十分艰难。如果原来的数据库是繁多数据库，就须要从新设计和布局整个零碎。有人混同分布式数据库的概念，把分库分表也叫分布式，但其实它不是分布式数据库，因为它是多个数据库而不是一个数据库，也不满足 ACID。
分库分表计划不足全局索引和惟一 ID，因为它不再是单个数据库。还要对业务做拆分，有个拆分维度，比方买家维度，那么业务上须要对卖家的维度进行解决怎么办？因为卖家的信息会遍布所有分库，如果做简略的统计还能够进行，但如果波及事务的解决是没有方法进行的。分库分表计划尽管能够解决一些问题，但也带来更多的挑战，更大的复杂性和更高的老本。
作为一款原生分布式关系数据库，OceanBase 自身能够做到程度扩大，不须要从新拆分业务，咱们能够在主库做交易解决，在备库做数据分析解决。甚至在将来能够在主库上同时实现交易和剖析的解决。这一技术上的变革很好地克服了分库分表计划的弊病。
原生分布式是数据库的将来
现在的海量数据处理系统，不论是大数据系统还是数据仓库，它们都是分布式——原生分布式。然而咱们再看关系数据库尤其是 OLTP 数据库，目前它依然是单机 / 集中式的。不是 OLTP 数据库不须要分布式，而是分布式的 OLTP 数据库的研制十分艰难。
有很多客户说，分布式是很好，然而明天分布式的生态不够成熟，不如集中式数据库的生态。回想起 150 年前，汽车刚刚被创造，马车还是最支流的交通工具，过后在马路上优先通行的是马车，汽车也没有生态。而到了 2020 年的明天，作为支流交通工具的马车曾经成为远古的过来，汽车早就成为了不可逆转的支流。
原文链接
本文为阿里云原创内容，未经容许不得转载。
