关于作者：
杨传辉，OceanBase CTO。2010 年作为创始成员之一加入 OceanBase 团队，主导了 OceanBase 历次架构设计和技术研发，从无到有实现 OceanBase 在蚂蚁集团全面落地。同时，他也主导了两次 OceanBase TPC-C 测试并打破世界纪录，著有《大规模分布式存储系统：原理与实践》。目前，杨传辉带领 OceanBase 技术团队致力于打造更加开放、灵活、高效、易用的下一代企业级分布式数据库。
我从 07 年开始研究大规模分布式系统，刚开始参照 Google 三驾马车（GFS / MapReduce / Bigtable），10 年开始加入当时的淘宝做 OceanBase。
OceanBase 最初是一个分布式架构，支持的 SQL 功能非常有限，后来逐步加入 SQL 功能并通用化。刚开始接触大规模分布式系统的时候，我觉得这个领域特别高大上，当年的分布式系统有点像今天的 ChatGPT，涉及的技术很前沿，而且有些协议非常难，我记得当时仅仅理解 Paxos 协议就花费了一年多的时间，看了十几篇相关论文且和小伙伴们做了大量的技术讨论。
曾经有一段时间，我觉得分布式是 IT 软件技术皇冠上的明珠，所有系统只有做成分布式才显档次。但是，当我们将 OceanBase 早期版本应用到淘宝和支付宝时，用户和 DBA 给我们提出的都是 SQL 兼容性和性能成本相关的需求，把我们和单机的 MySQL 数据库做比较，只有完全兼容且性价比更高才会选择 OceanBase。他们告诉我，OceanBase 的扩展性和无损容灾确实很好，也认同分布式这个方向，但是对不起，老板说今年业务发展太快，不能投入额外人力做数据库改造，也不能投入额外的数据库服务器。
过去有一句土话叫“既要也要还要”，小孩才做选择，用户和 DBA 想要的就是一个不要做选择的“成年人的数据库“。我记得当时还和 Google Spanner 的研发人员做过一次技术讨论，我问他们为什么 Google 内部能够接受 Spanner 很差的单机性能，他们告诉我 Google 内部的程序员很强，大家都可以把应用修改为异步程序。另外一点就是，Google 有 Jeff Dean，只要他想统一基础架构就可以自上而下推进。我很羡慕 Google 内部做基础设施的研发人员，同时，我也意识到，这种模式是不可扩展的。对于开发者来讲，一定要把单机的高性能低门槛融入到分布式的可扩展高可用才能做出一个真正好用的分布式数据库。
我们在 2016 年发布了全分布式架构 OceanBase 1.0 版本，这个版本的所有节点都是可读可写的，但是，有一个问题，那就是每个节点用于分布式相关的 overhead 比较大，当表格和分区较多时，即使系统空转，也会消耗好几个 CPU 核用于分布式相关操作。这个问题使得 OceanBase 1.x 系列的版本只能帮助较大规模的企业解决数据库的问题，很难在中小企业做规模化复制。
于是，我们在 2018 年开始讨论如何降低分布式数据库的门槛，让分布式数据库成为一个人人皆可触达的东西。数据库底层架构的调整需要非常慎重，我们足足花费了两年多的时间完成了技术讨论和总体架构的设计，并在 2020 年年中左右开始做详细设计和代码开发，再经过两年多的时间才在 2022 年 8 月份发布了第一个 OceanBase 4.0 版本，代号“小鱼“。4.0 版本奠定了单机分布式一体化架构的底座，但是还有很多的遗留问题，在 3 月份开发者大会发布的 4.1 版本中解决。
我们从 2021 年开始对外铺垫一体化架构的概念，最早的一体化架构叫做“集中式分布式一体化“，当时我们认为 DBA 更加熟悉集中式这个说法。不过，市场品牌的负责人建议修改成 “单机分布式一体化”，这样会更加形象直观，能够更好地表达 OceanBase 的技术特点，开发者也更容易理解。
1、可行性分析，如何消除分布式带来的overhead？
架构设计首先要做的就是可行性分析。做技术的同学肯定都很熟悉，架构设计的核心在于取舍，为什么能够做到，背后的原理是什么，舍弃了什么。我们在设计一体化架构时，也做了一个设计假设，那就是：对于一个分布式数据库，虽然数据量很大，但是大部分操作仍然为单机操作（>80%），少部分操作才是跨机操作（<20%）。
OceanBase 早期在阿里系内部推广时，我自己就是内部的 BD/SA，我会主动去和每个业务的开发人员交流，最后发现，虽然阿里系的业务很复杂，有电商，金融，物流，本地生活，文娱，地图，医疗健康，但是，所有的互联网 to C 的在线业务基本都能够按照用户号(user_id)做 sharding 来实现分布式。按照 user_id 做完 sharding 之后，绝大部分操作都是单用户内部的操作，只有非常少数的跨用户操作。
金融行业也是类似的，我们都用过网银系统，大部分时间都是在读写自己的账户，少部分时间才是做转账这样的跨账户操作。于是，系统的优化目标就变成：首先确保 80% 的单机操作没有任何分布式相关的 overhead，这部分操作能够和单机数据库站在同一个起点上 PK 性能，接下来才是优化另外 20% 跨机操作的性能，尽可能追求极致。
单机操作的分布式相关 overhead 主要来自于两个方面：一个是高可用带来的，一个是可扩展性带来的。2013 年的时候当时的支付宝 Oracle DBA 告诉我一个经验数据，当 Oracle 打开强同步的时候，性能降低至少 30% 以上。OceanBase 为了实现无损容灾，底层采用了基于 Paxos 的强同步方案，如果不在架构上有所变化，肯定做不到单机高性能。
我们的做法是把数据库中的 redo 日志提交给异步化，这样就避免了数据库内部的工作线程等待日志提交返回结果，即使网络和磁盘比较差，强同步带来的开销也比较小。我们用 sysbench 对 OceanBase 三台机器强同步做了性能评测，结果表明 Paxos 强同步对于 OceanBase 的性能损失只有 8% 左右。这个损失是完全可以接受的，可以通过其它模块的优化给弥补回来。可扩展性带来的性能损耗主要是数据分片导致的，每个数据分片都需要写单独的redo日志，可以简单地把每个数据分片想象成一个 mini 数据库，分片越多，每台机器上分片管理相关的分布式 overhead 就越大。
4.0 单机分布式一体化架构的创新就在于动态日志流。每台机器上的每个租户只有一个日志流，这个租户上的所有数据分区都动态绑定在该日志流之上，从而避免了大量日志流导致的 overhead。另外，分区到日志流是动态绑定的，当系统增加新的服务器时，可以把分区从源端的日志流动态解绑并重新绑定到目的端的日志流，从而实现分区动态迁移。
很多人可能会想，数据库发展了这么多年，为什么 OceanBase 想到了这么做，其他人都没有想到？这里面其实也没有什么魔法，我认为关键点在于全球分布式数据库很少有像 OceanBase，必须扛住支付宝双十一这样的极限业务场景，并且多年被业务方”既要也要还要”给逼出来的。
业界对于可扩展性也有不同的做法：经典的单机数据库干脆就不支持可扩展，想要分布式的时候让应用做改造；NewSQL 系统的思路是把可扩展性下沉到存储层，将系统划分为 SQL 层和存储层，SQL 层做功能，存储层做可扩展性，这种实现方式更加简单，但会带来一个问题，那就是每个 SQL 请求都需要一次额外的远程访问，即使是访问自己账户也是一样；OceanBase 的做法是先实现全分布式架构 1.x/2.x/3.x，再逐步演进到单机分布式一体化架构 4.x。
2、对开发者意味着什么？
单机分布式一体化架构看起来什么都行，既能做单机，又能分布式，现阶段的侧重点到底是什么？我认为一方面，单机分布式一体化架构是一种技术的升维，对于用户和开发者比之前更加友好，会逐步成为主流选择。另一方面，新技术肯定有一段成熟期，尤其是用户体验和生态一开始不如单机数据库，需要一段时间来打磨。短期来看，单机分布式一体化架构对于开发者的价值在于如下几个方面：
第一，极大地降低分布式数据库的门槛。原先的 NewSQL 单机性能太差，业界主流的 NewSQL 系统，比如 CockroachDB 和 YugabyteDB 的单机 sysbench 性能只有 MySQL 的 1/5 ~ 1/10。随着单机分布式一体化数据库逐步成熟，这类 NewSQL 会被逐步取代，我也确实看到很多用户把原先使用的 NewSQL 系统换成 OceanBase 来实现降本增效。
第二，解决用户从小到大扩展的需求。我在和很多中小企业沟通的过程中发现，大多数中小企业都是很有追求的，虽然目前阶段他们的数据量不大，单机数据库也能支撑，但是他们也对未来几年的业务发展充满期待，不希望等到业务发展之后再修改应用更换数据库，他们愿意一开始就选择单机分布式一体化数据库。
单机分布式一体化数据库最终会不会取代单机数据库？我认为从技术趋势上来看会逐步替代，但是整个过程比较长，需要很长一段时间。
3、聊聊核心技术原理
单机分布式一体化架构的核心技术是动态日志流。为了真正实现一体化，需要解决如下几个关键的技术问题：
- 应用透明：从单机到多机不需要应用做改造，需要客户端支持动态路由技术，当后端数据库发生分区迁移时，能够动态路由到目的服务器上。另外，不管是单机还是分布式，需要支持全部的 SQL 功能。
- 单机操作：单机只有一个 redo 日志，单机事务写 redo 日志的方式与经典的单机数据库比较像。OceanBase 还做了一项技术创新，经典的单机数据库采用的是B+树存储引擎，OceanBase 的做法是将 B+ 树数据分块的思路融入到 LSM 树存储引擎，一方面能够像 LSM 树一样具备高压缩能力，并把热点数据放在内存中提供服务，另一方面通过类似 B+ 树的数据分块思路来减少 LSM 树的写入放大。最终使得 OceanBase 4.1 即使在三台机器做强同步的情况之下无论是单机的性能还是存储成本都好于 MySQL 8.0。
- 跨机操作：跨机操作通过底层的分布式架构提供，上层的 SQL 功能不受影响。如果事务只涉及一台机器，走单机事务；如果涉及多台机器，通过两阶段提交实现分布式事务。另外，通过分布式、并行、异步化等技术手段尽可能地优化性能。
- 迁移代价：迁移操作后台进行，实际运行时一般会对迁移限速。假设迁移最大限速 200MB/s，占用万兆网卡 20% 左右的带宽，迁移操作只是拷贝数据，CPU 占用比较少，只要不是在双十一零点这样的极端场景，后台迁移都不会影响前台的在线交易请求。假设数据量为 1TB，迁移时间为 1TB / 200MB/s = 5000s，大约 1 个半小时。
4、聊聊实际效果
今年 3 月份我们在开发者大会分享了 OceanBase 的性能数据，过去也在 TPC-C 测试展示了 OceanBase 的扩展能力：
- 单机性能：32C 场景，OceanBase 4.1 在 sysbench 所有场景(point select/read only/write only/read write/insert/update)都好于 MySQL 8.0，在最为综合的 readwrite 场景 OceanBase 4.1 比 MySQL 8.0 高 39%。
- 公有云性价比：采用 4C16G CPU，MySQL 部署主备两台机器，OceanBase 部署三台机器，两台为全功能副本，一台为日志副本。无论存储多大，从 100GB，300GB，500GB 到 1TB，OceanBase 4.1 在阿里云和 AWS 的性价比都好于MySQL 8.0，且存储容量越大，OceanBase的优势越明显。整体上看，同样的性能，相比云上的 MySQL，OceanBase可以帮助用户节省 18.57% 到 42.05% 整体拥有成本，且 OceanBase 还有更好的三副本无损容灾能力。
- TPC-C 扩展性：OceanBase 参加过两次 TPC-C 测试，最后一次测试中采用了超过 1500 台机器，TPC-C 的 workload 里面有 10%~15% 分布式事务，本地事务 85%-90%，与真实场景比较接近。通过 TPC-C 官网公布的报告可以看到，OceanBase 的性能基本能够做到随着服务器的增加而线性增长。
5、问题探讨
当然，单机分布式一体化架构也不是完美的，有一些问题仍然值得探讨，也希望未来和开发者用户做更深入的探讨：
一、分布式到单机 vs 单机到分布式
到底是选择分布式到单机（先做分布式再做单机），还是单机到分布式（先做单机再做分布式）的技术路线？我认为只有分布式到单机才是可行的。因为分布式的技术难度比单机要高一个数量级，再加上单机的场景是主流场景。从 ROI 的角度看，不太可能出现一个主流场景的单机数据库，在已经有大量技术债的前提之下，舍弃部分主流场景的支持，花费更高一个量级的代价去支持一个规模更小的高端场景。这也是为什么所有的商业案例中，只有先做高端，再做低端的降维做法才能成功。
技术创新也往往在外部才会发生，比如电动车领域的 Tesla，分布式技术有点像电动车的电池，并不是燃油汽车厂商在内部实现了电动化的变革，而是一个外部的 Tesla 先做好高端的 Model X/Model S，再逐步通过大众车 Model 3 去占领主流市场。
二、全分布式场景
单机分布式一体化架构有一个假设，那就是：在分布式数据库中，大部分请求仍然是单机读写，少部分请求才是跨机读写。如果这个假设不成立，也就是大部分请求都是跨机读写，那么，分布式数据库性能的扩展比会大幅下降。怎么看待这个问题？我认为可以进一步把全分布式的场景分为两类：一类是 OLAP 场景，OLAP 场景单个用户的数据量都很大，且维度会比较复杂，这个场景确实很难做到本地化。
但是，这个场景的并发量很小，优化的关键点在于尽可能地把所有机器的资源通过并行化、向量化等手段尽可能地利用起来。每次运行的 SQL 都比较大，一次额外的网络请求开销在整个 SQL 语句执行过程中占比很少。另外一类是 OLTP 场景，假设某个 OLTP 业务全部都是跨用户转账操作，那么，如果数据量比较小，单机分布式一体化架构可以只部署单机，没有额外的分布式开销；如果数据量比较大，必须采用多机部署，那么，性能的扩展比虽然会大幅下降，但是，这是业务无法避免的，这种场景下单机分布式一体化数据库相比其它的 shared nothing 数据库在架构上也没有劣势。
