编者按：在国产替代浪潮下，国产自主数据库正在快速崛起。在众多头部国产数据库玩家中，低调耕耘多年的蚂蚁 OceanBase 一直是“扫地僧”一般的存在。OceanBase 生于大数据时代，2010 年支付宝正式成立 OceanBase，当时云计算方兴未艾，互联网正高速发展。OceanBase 创建初心是要解决“海量数据管理的难题”，真正做一个“顶天立地”的通用性产品，如今 OceanBase 已成为国产分布式数据库的代表产品。蚂蚁 OceanBase 作为一家独立的数据库厂商，也一直稳居国产数据库市场第一梯队。此前罗超频道对OceanBase 也有多次专题报道。
那么，OceanBase 的架构是如何演进的？OceanBase 的架构设计背后有什么技术考量？其独创的“单机分布式一体化”架构会不会成为数据库未来？今天分享一篇干货笔记，作者为现任蚂蚁OceanBase CTO杨传辉，他时也是中国计算机学会（CCF）数据库专委会执行委员，他带领 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年开始对外铺垫一体化架构的概念，在2021年10月22日的云栖大会上分享了<<OceanBase一体化架构助力核心系统>>。最早的一体化架构叫做“集中式分布式一体化“，当时我们认为DBA更加熟悉集中式这个说法。不过，市场品牌的负责人建议修改成 “单机分布式一体化”，这样会更加形象直观，能够更好地表达OceanBase的技术特点，开发者也更容易理解。
可行性分析，如何消除分布式带来的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。
单机分布式一体化架构对开发者意味着什么？
单机分布式一体化架构看起来什么都行，既能做单机，又能分布式，现阶段的侧重点到底是什么？我认为一方面，单机分布式一体化架构是一种技术的升维，对于用户和开发者比之前更加友好，会逐步成为主流选择。另一方面，新技术肯定有一段成熟期，尤其是用户体验和生态一开始不如单机数据库，需要一段时间来打磨。短期来看，单机分布式一体化架构对于开发者的价值在于如下几个方面：
1) 极大地降低分布式数据库的门槛。原先的NewSQL单机性能太差，业界主流的NewSQL系统，比如CockroachDB和YugabyteDB的单机sysbench性能只有MySQL的1/5 ~ 1/10。随着单机分布式一体化数据库逐步成熟，这类NewSQL会被逐步取代，我也确实看到很多用户把原先使用的NewSQL系统换成OceanBase来实现降本增效。
2) 解决用户从小到大扩展的需求。我在和很多中小企业沟通的过程中发现，大多数中小企业都是很有追求的，虽然目前阶段他们的数据量不大，单机数据库也能支撑，但是他们也对未来几年的业务发展充满期待，不希望等到业务发展之后再修改应用更换数据库，他们愿意一开始就选择单机分布式一体化数据库。
单机分布式一体化数据库最终会不会取代单机数据库？我认为从技术趋势上来看会逐步替代，但是整个过程比较长，需要很长一段时间。
聊聊核心技术原理
单机分布式一体化架构的核心技术是动态单日志流。为了真正实现一体化，需要解决如下几个关键的技术问题：
应用透明：从单机到多机不需要应用做改造，需要客户端支持动态路由技术，当后端数据库发生分区迁移时，能够动态路由到目的服务器上。另外，不管是单机还是分布式，需要支持全部的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个半小时。
再聊聊实际效果
今年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的性能基本能够做到随着服务器的增加而线性增长。
一些关键问题探讨
当然，单机分布式一体化架构也不是完美的，有一些问题仍然值得探讨，也希望未来和开发者用户做更深入的探讨：
1) 分布式到单机 vs 单机到分布式
到底是选择分布式到单机（先做分布式再做单机），还是单机到分布式（先做单机再做分布式）的技术路线？我认为只有分布式到单机才是可行的。因为分布式的技术难度比单机要高一个数量级，再加上单机的场景是主流场景。
从ROI的角度看，不太可能出现一个主流场景的单机数据库，在已经有大量技术债的前提之下，舍弃部分主流场景的支持，花费更高一个量级的代价去支持一个规模更小的高端场景。这也是为什么所有的商业案例中，只有先做高端，再做低端的降维做法才能成功。
技术创新也往往在外部才会发生，比如电动车领域的Tesla，分布式技术有点像电动车的电池，并不是燃油汽车厂商在内部实现了电动化的变革，而是一个外部的Tesla先做好高端的Model X/Model S，再逐步通过大众车Model 3去占领主流市场。
2) 全分布式场景
单机分布式一体化架构有一个假设，那就是：在分布式数据库中，大部分请求仍然是单机读写，少部分请求才是跨机读写。如果这个假设不成立，也就是大部分请求都是跨机读写，那么，分布式数据库性能的扩展比会大幅下降。怎么看待这个问题？
我认为可以进一步把全分布式的场景分为两类：
一类是OLAP场景，OLAP场景单个用户的数据量都很大，且维度会比较复杂，这个场景确实很难做到本地化。但是，这个场景的并发量很小，优化的关键点在于尽可能地把所有机器的资源通过并行化、向量化等手段尽可能地利用起来。每次运行的SQL都比较大，一次额外的网络请求开销在整个SQL语句执行过程中占比很少。
另外一类是OLTP场景，假设某个OLTP业务全部都是跨用户转账操作，那么，如果数据量比较小，单机分布式一体化架构可以只部署单机，没有额外的分布式开销；如果数据量比较大，必须采用多机部署，那么，性能的扩展比虽然会大幅下降，但是，这是业务无法避免的，这种场景下单机分布式一体化数据库相比其它的shared nothing数据库在架构上也没有劣势。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与极客网无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
