欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase 首席架构师杨志丰（花名：竹翁）带来了 《OceanBase 的单机分布式一体化》 的分享，为大家介绍了单机分布式一体化架构的概念及思考，以及对业务的价值。
以下为演讲实录：
明天我的演讲主题是《OceanBase 的单机分布式一体化》，次要来解释 OceanBase 为什么要做单机分布式一体化，我将从以下 3 个方面进行明天的分享：
首先，单机分布式一体化是什么？
其次，单机部署时如何取得与单机数据库相当的性能？
最初，分布式部署时如何实现高性能低时延？
什么是单机分布式一体化？
每个人听到“单机分布式一体化”可能都会有本人不同的了解，也会有很多疑难，事实上，单机分布式一体化不是 OceanBase 忽然冒出来的概念，而是基于三方面的起因。
第一，产品迭代。 OceanBase 从 2010 年开始自研，在走出蚂蚁团体开始服务金融行业，到当初走到云下来服务更多互联网行业客户的过程中，基于客户的反馈，咱们的产品一直在演变、欠缺。
第二，硬件趋势的一直倒退。 OceanBase 在 1.0 最后设计的时候，过后咱们在蚂蚁团体的外部集群，用的机器都是一般 16 核的机器，前面随着硬件技术的倒退，咱们的支流机器都在 96 核以上，服务器单机的性能有了极大的晋升。
第三，云技术的倒退。 近几年，云技术倒退突飞猛进，OceanBase 刚刚创建之初，云技术刚刚衰亡，而当初云基础设施触手可得。技术的倒退随同着 OceanBase 架构的倒退，OceanBase 的技术经验了三个大的版本迭代。
▋ 从 0.1 到 4.0，OceanBase 的倒退历程
第一个版本是 0.5 版本，尽管是十几年前的版本，但其实它曾经齐全是分布式的架构，在过后，OceanBase 把 SQL 层和存储引擎做了拆散，下面是一组 SQL 无状态服务，上面是由 ChunkServer 和 UpdateServer 组成的存储集群，对外裸露的就是表的 API。过后因为咱们刚刚开始去做数据库的实现，所以咱们做了一些限度——没有多点写入，所以过后实际上是不反对分布式事务的。
当 OceanBase 从 0.5 往 1.0 演进的时候，咱们有一个粗浅的感触：传统单机数据库采纳紧耦合的设计，存储和计算放在一起，起初因为有了 NoSQL，很多人感觉是不是应该把存储层独自隔离开，OceanBase 在零点几版本的时候就遵循这样的设计思路，所以咱们做了拆散，但拆散当前带来十分大的问题。
这个问题在于做 NoSQL 还能够，然而要做关系型数据库并没有那么简略，如果你对时延有要求的话，松耦合的形式会导致效率上有很大开销。所以 OceanBase 从 1.0 开始，咱们就在从新思考这个问题—— 把存储事务 SQL 做成紧耦合的架构，即全分布式架构，将原来的三个 Server 合成一个 OBServer 的节点，同时解决存储事务 SQL，同时咱们将高可用的粒度，由原来机器级别的高可用粒度，切分成若干个 Zone， 这些都得益于咱们在蚂蚁团体的场景实际。
当 OceanBase 倒退到 2.0 版本时，OceanBase 从蚂蚁团体走向了内部客户，在这个过程中客户反馈说：“OceanBase 只反对 MySQL，是很好，但咱们这外面有很多的 legacy（遗留）零碎是不可能把它齐全的改成用 MySQL 或者用开源的形式去做的”，所以 OceanBase 在 2.0 的时候引入了重要的个性，在多租户的能力之上又兼容了 Oracle，但它的整体架构和 1.0 是一样的，在 4.0 版本时，咱们就进入了全新的单机分布式一体化的阶段。
▋ 单机分布式一体化的三个含意
当初，我来正式定义一下 OceanBase 单机分布式一体化到底是什么，单机分布式一体化有三个层面的含意。
第一个层面，OceanBase 以一个程序的模式存在，既能够在单机的模式下部署，也能够做成多机部署。 这个并不是非常容易做到的事件，只有咱们把单机分布式一体化作为一个指标，能力去实现这样的状态。
第二个层面，咱们所谓的单机分布式一体化，其实有一个租户的概念。 即便你部署了一个分布式的 OceanBase 集群，然而外面的某一个租户如果在单机上，咱们也认为这是一种单机的状态。
第三个层面，单机分布式可动静转换。 在两种状态之间，OceanBase 能够随便切换，能够灵便地做动静的调整，单机能够变成分布式，分布式能够变成单机，同样在租户层面和集群层面都能够做到。
尽管也会有其余方面的很多挑战，但切换的最大挑战显然是对于性能的，所以接下来我将分享 OceanBase 怎么做到在单机分布式一体化架构上面，在单机部署的时候能够做到单机数据库相当，在分布式部署的时候咱们在保障可扩展性的同时，又能够做到比其余的分布式数据库更高的性能和更低的时延。
▋ 单机分布式一体化，匹配企业不同倒退阶段
首先看业务的价值，对于很多企业来说他是有一个从小到大的过程，或者说在大企业外部有个小的业务，业务都是从小开始变大，有一天可能某个业务忽然冒出来，但最后的时候其实并不需要那么多的资源，咱们心愿用户既能够享受到分布式数据库带来的劣势，应用起来又不存在十分多的艰难，能够一个数据库解决企业多个不同倒退阶段的需要。
OceanBase 正式反对单机状态部署。如果你对读写拆散有要求，你能够应用 OceanBase 主备库的能力，就像传统的 MySQL 的主备库一样，没有任何的区别；如果你感觉 MySQL 的主备库在切换的时候会产生丢数据的问题，特地是近程容灾的时候，能够从主备库动静的降级到 OceanBase 三正本模式；如果你感觉高可用、三正本的模式不能在现阶段把握，或者对你来说不是很要害，那么 OceanBase 其实具备十分强的单机模式下 scale-up 垂直扩大的能力，所以咱们并不是做分布式数据库就不论单机的性能。
当企业或者业务倒退到大规模场景的时候，有十分多的问题要思考。比方，业务特地多，在蚂蚁团体外部，大家能够设想有十分多的业务、甚至有上万台的机器在应用 OceanBase，这个时候如果你只有 10 人的 DBA 团队，你怎么去治理一万个 MySQL，这是十分大的挑战，所以咱们的多租户和整个分布式的架构，使得咱们能够把集群的数目管制在一个正当范畴之内，在每个集群外部有很多自动化运维的伎俩，让咱们的 DBA 真的能够安稳的睡一个好觉，此时有很多非功能性的需要就提出来了。
比方，分布式数据库是很好，然而我可能在以后这个阶段并不需要。然而我想说“有了 OceanBase 的单机分布式一体化架构，大家不会有放心，你能够在你须要的时候抉择你所须要的个性”。反过来说，如果我引入了分布式数据库，同时给你搭售了三正本和很多其余你不须要的能力，那不是咱们所心愿的，这也是咱们单机数据库外围的价值。
单机部署时如何取得与单机数据库相当的性能
▋ 适度分层设计尽管简化了实现，但就义了性能
反过来想这个问题，如果我有一个分布式的数据库，左侧是其余的分布式数据库的典型状态，将存储节点和计算节点做一个拆散，他们之间通过网络进行通信，这样的话是能够各自做拓展的。分布式数据库当然不是仅分片那么简略，数据库很重要的是事务处理的核心节点，数据库要保证数据全局的一致性和原子性，所以很多数据库会引入这样一个全局事务管理器的模块。
OceanBase 也有相似的模块，咱们叫全局工夫戳服务，性能都是相似的，像上边的右图一样，将三个节点装到一台单机上。
很多人说这样的“单机分布式一体化”咱们也能够，但这外面是有十分多开销的，因为分布式解决所波及的很多协定，对于单机来说都是开销，各个组件之间，如果你通过 RPC 做通信，会产生十分多额定的开销，另外 RPC 协定是须要专门去设计的，所以在设计这种通信协定的时候，不能像函数调用一样，能够尽量灵便的做很多快捷的解决。
此外，还有一层暗藏的含意，就是从咱们从事数据库研发的视角来说，如果你以分布式作为结尾，你在理论实现过程中不会去想单机是什么状况，这个是大家能够了解的。
▋ OceanBase 的单机分布式一体化
咱们看一下 OceanBase 单机分布式一体化整体的架构，说起来非常简单： 每一台机器都具备本人独立的 SQL 存储事务的模块，在单机之内，SQL 存储事务之间间接通过函数调用，和单机没有任何区别；在机器和机器之间通过网络去做通信。
上图中的架构有几个特色：第一，每个节点单过程，OceanBase 没有那么多角色辨别，整个 SQL 事务存储是在单个过程内共享内存的；第二，单机内工作是没有 RPC 的，并且对于单机数据库来说，为了晋升垂直的扩展性，OceanBase 还反对单机内并行，在更深层次上，每个组件的设计，OceanBase 都会兼顾单机和分布式。
在这样的设计外面，咱们每一个性能的设计都要思考在单机内怎么样做最好，分布式时怎么做最好，所以咱们的设计都会有这样两个维度。
首先看单机的两个含意，第一，每个 Zone 外面一个 OBServer，所以即便一个 Zone 外面有很多个资源的单元，即 Unit，如果你的租户是单个 Unit，就等于这里所讲的单机。
为了晋升单机内垂直的扩展性，OceanBase 在 SQL 引擎、事务引擎、存储引擎都会做到极致的优化：第一，单机内能够并行；第二，在事务引擎里，咱们在做事务的高并发解决的时会做组提交的技术。同样在存储引擎外面，咱们的存储引擎属于准内存的存储引擎，写入的时候只须要放到内存里就能够了，并不需要像传统的 B+ 树一样，把它写到数据块里。单机内同样在 IO 层面反对很多并行。
你会看到晚期的 MySQL 给他一个 96 核的集群，想把 CPU 跑满，是不可能的，这就是垂直扩展性的体现。
▋ OceanBase 4.0 VS MySQL 8.0
上图是 OceanBase 4.0 和 MySQL 8.0 的性能比照，在六种场景下，OceanBase 4.0 和 MySQL 8.0 的性能都是相当的。
上图是咱们垂直扩展性的试验，同样在 Sysbench 的六种负载场景下， 从 4 核到 64 核的机器，大家都能够看到 OceanBase 具备十分好的垂直扩展性，多给一倍的核数，OceanBase 的性能就晋升一倍。
分布式部署时如何实现高性能低时延
对于 OLTP 业务来说，大家用分布式数据库很放心时延的指标，那么单个操作的时延指标是不是能像单机数据库一样呢？这是 OceanBase 着力在优化的点。根本起因就是：无论你在怎么样的数据中心，做一次 RPC 就须要 0.5 毫秒，这个工夫不可疏忽。
▋ 分布式性能须要高性能低时延
下图是在某个特定的负载上面，随着分布式事务比例的减少，单机数据库和两种分布式数据库的性能体现，绿色是单机数据库。
随着某种分布式事务的减少，对于比方 TPC-C 来说，即跨 warehouse 交易的减少，和单机数据没有什么差异。如果有两种数据库，OceanBase 的设计指标是变成上面 DB1 的性能曲线，随着分布式事务减少，必定有开销，但当我还没有分布式事务的时候，DB2 的性能就比 MySQL 差十分多，这不是咱们想设计的分布式数据库。
此时有两种形式能够做到，第一就是升高分布式事务和分布式查问的这个比例，正如 CTO 杨传辉所说：“实际上对于很多在线型的交易，全局性的事务，他的比例往往并没有大家想的那么多。在典型的 TPC-C 场景下，TPC-C 里跨 warehouse 的交易查问只有 10%”（可移步浏览《OceanBase CTO 杨传辉：万字解读，打造开发者敌对的分布式数据库》）。做在线交易的时候，DBA 同学很分明本人的业务，并不是所有的货色都要付出分布式的开销，为了可能达到这样的成果，咱们做了很多的工作，其中最次要的就是 4.0 外面自适应的日志流。
OceanBase 做了很多自适应的策略，去自动化的依据表的设计去做主动的负载平衡，主动的做数据排布缩小分布式事务和分布式查问的比例，如果这些自动化的措施都达不到这个指标，用户同样能够用咱们提供的分区表和表组的性能本人去管制、升高分布式事务。
如果以上的要求都做不到怎么办呢？咱们就必须硬碰硬地升高分布式事务和分布式查问整个的开销，这块 OceanBase 有很多独特的设计。
▋ OceanBase 分布式为何能高效经济？
回到单机分布式一体化架构，在这个架构上面咱们看看分布式场景下它是怎么工作的。
对于下面这种分层的设计来说，如果 SQL 层、存储层、事务层是分层的设计，无论本人怎么操作，这个 SQL 和本地的事务之间是没有感知的，所有的货色都是全局的，本地的交易数据还是近程的交易数据对于 SQL 层都没有差异。OceanBase 不是这样，咱们显式的就辨别了这两者的区别，所以 OceanBase 的 SQL 层能够间接拜访到另外一台机器的存储层。如果须要拜访另外一台机器存储层的时候我做 RPC，如果我拜访的存储是在本地，就不须要做 RPC。
整体设计的时候有几个不同的粒度，实质上设计时咱们做得更加精细化，精细化是说单机分布式并不是简略的概念，而是多个粒度的单机，在咱们看起来有四个根本的粒度：
第一，租户。 是分布式的租户还是单机的租户。
第二，会话。 OceanBase 会通过 Proxy 路由协定使得在很多其余数据库外面分布式的做一件事件，在 OceanBase 会变成单机的事件。最典型的就是咱们会依据这条 SQL 的特色，把它路由到存储所在的节点上，这样即便整体上看起来如同是分布式，然而对于那条 SQL 的执行，它就变成本地执行。
第三，事务。 在事务层面上，OceanBase 如果在单个事务内只操作一个日志流内的分区，分布式事务提交的协定和单机的协定也是有区别的。
第四，SQL。 如果是一个单机的 SQL 执行和须要近程拜访 SQL 的执行，咱们有两种独立的执行门路。在此基础之上，为了使分布式的执行更加高效，咱们整个 SQL 引擎在 OLTP 下面做串行执行的时候会有自适应的策略。
咱们的设计素来都是一个整体，对于 LSM-Tree 来说，合并是十分耗费资源的后台任务，然而如果在分布式的部署场景下，咱们创造了一种聪慧的办法： 使得每台机器的合并和它的服务能够错开，咱们称之为“轮转合并”，就是如果一个正本在提供服务就先不合并，我让 follower 正本去做合并，这样使得后盾的 LSM-Tree 合并对于前台的操作在这台机器上没有影响。
▋ 单机分布式自适应的执行引擎如何晋升分布式查问性能
如果我没有方法优化业务来缩小分布式 SQL，对于分布式 SQL 这部分我怎么去执行？OceanBase 整体的 SQL 自适应执行引擎，分为串行执行和并行执行。
并行执行能够在单机内并行，这一点绝对于一些开源的单机数据库是有劣势的，晚期的 MySQL 版本单机内并行是没法做到的，又能够利用多机，如果一台机器 CPU 还不够，我能够把整个集群的 CPU 用起来去做并行执行。串行执行咱们就显式地去辨别了，它到底是一个大数据量的拜访，还是一个小数据量的拜访。
如果是一个小数据量的拜访，咱们会把数据拉到本机来执行；如果是一个大数据量拜访，咱们会把整个 SQL 的执行打算下压到那台机器下来做数据过滤，整个过程是优化器自适应去抉择的。
▋ 兼顾单机和分布式的事务处理协定以晋升事务性能
最初，事务是十分难做分布式优化的，OceanBase 在事务引擎方面有十分多的翻新的专利。在这里我介绍两个点，下图是分布式事务执行提交的流程，事务从整体上来看分成 “事务开启”和“事务提交” 两个要害操作。
第一，在“事务开启”的阶段，左侧是其余的分布式数据库典型的两阶段提交的过程。在开启事务的时候，为了实现多版本的隔离，读和写相互不影响，在 MVCC 的场景下，它须要取得一个全局的快照——即以后哪些事务在操作，哪些事务曾经提交了快照，对于很多分布式数据库来说，这个快照的操作是十分大的开销。
而 OceanBase 在这个阶段做了优化，咱们在很多场景下，OceanBase 不须要拜访全局的工夫戳服务。咱们翻新地实现了一些对于 GTS 服务的优化，使得这部分的开销是可扩大的。证实就是 TPC-C 测试，TPC-C 有 1500 个节点，1500 台机器每秒解决 2000 多万次事务（是事务并不是 SQL），但只有一个 GTS 服务节点，看起来如同这个 GTS 不容易扩大的，实际上咱们优化后变得很容易扩大。
第二，在“事务提交”的阶段， 对于提交的协定来说，大家能够看到左侧两阶段的提交协定，传统的两阶段提交协定须要写四个阶段的日志，在参与者上要写事务的日志，在协调者上也须要记录日志，使得两阶段提交在容灾的场景上是平安的。
OceanBase 在两阶段提交上做了一个十分翻新的设计，OceanBase 的参与者是三正本、高可用的，所以并不放心协调者的节点数据失落，所以咱们在参与者上不记日志，这样就节俭了两条日志。第二，咱们会在第一个阶段就给利用返回胜利，这是咱们十分独特的一个优化，使得整体的 roundtrip 少了一次。所以整体来说，即便在分布式事务场景上面，OceanBase 的散布事务比其余的分布式数据库有很大的劣势。
最初附上 OceanBase 与市场上几款常见的分布式数据库在 Sysbench 500 线程下的性能比照，这也就是全分布式场景下 “OceanBase 的低时延是什么” 的最好出现，我的分享就到这里，谢谢大家！
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/