对于作者：
杨传辉，OceanBase CTO。2010 年作为开创成员之一退出 OceanBase 团队，主导了 OceanBase 历次架构设计和技术研发，从无到有实现 OceanBase 在蚂蚁团体全面落地。同时，他也主导了两次 OceanBase TPC-C 测试并突破世界纪录，著有《大规模分布式存储系统：原理与实际》。目前，杨传辉率领 OceanBase 技术团队致力于打造更加凋谢、灵便、高效、易用的下一代企业级分布式数据库。
2022 年 8 月 10 日，OceanBase 4.0 小鱼在年度发布会亮相，单机分布式一体化架构也正式和大家见面。从我的角度看，OceanBase 总共经验了三次大的架构降级：第一次架构降级是 OceanBase 0.1~0.5 版本（2010 年~2015 年），过后的 OceanBase 通过单写多读架构实现了准分布式，有 UpdateServer、ChunkServer、MergeServer 等多种不同的角色；第二次是 OceanBase 1.0~3.0 版本（2016 年~2022 年），OceanBase 成为一个对等的全分布式架构，所有节点可读可写，逐渐反对了残缺的 SQL 性能；第三次架构降级就是这次公布的 4.0 版本，咱们正式提出了单机分布式一体化架构。
这篇文章次要和大家分享，4.0 背地的设计理念和技术思考。
面向云设计，以分布式为基石
在过来 70 余年的数据库倒退历程中，集中式数据库诞生了 Oracle、SQL Server、MySQL、PostgreSQL 等泛滥优秀作品，它们在单机性能和 SQL 性能做得十分杰出，然而没有方法程度扩大；分布式数据库的呈现解决了程度扩大的难题，然而单机性能和 SQL 性能相比集中式数据库有显著差距。这个过程呈现很多的分布式数据库，其中有些分布式数据库其实是分布式存储系统，只反对简略的 NoSQL 性能或者无限的 SQL 性能；也有一些分布式数据库同时反对程度扩大和残缺的 SQL 性能，这些零碎经常被称为 NewSQL，例如 CockroachDB，Google Spanner，然而，它们的单节点性能都不到 MySQL 的 1/3。
因而，单机和分布式如何抉择成为最让人纠结难以抉择的问题，通常的做法是依据数据量来做：如果数据量比拟小，抉择性能齐备的集中式数据库；如果数据量很大，则抉择分布式数据库或者分布式存储系统，就义性能和单机性能，通过批改业务或者堆机器来解决。
对于分布式数据库，有不同的理念：很多人或者很多零碎认为分布式是数据库的一种补充，适宜某些数据量特地大或者并发量特地高的细分畛域，而我的观点是不同的： 我认为分布式是将来面向云的下一代数据库的基石，将来云数据库的底层都是原生分布式。
打个比方，云数据库就像是电动车，而分布式就是其中的电池技术，有了分布式之后，尽管数据库的根本用法和之前差异不大，但用户体验开始分化，咱们曾经看到零配置、Serverless 等理念逐渐融入到最新的云数据库中。这就有点像电动车，当电池效率晋升，充电桩逐渐遍及之后，电动车开始在用户体验上拉开与燃油车之间的差距。很多人对特斯拉最大的感触并不是所谓的主动驾驶，而是操作简略，踩油门减速，收油门加速，甚至都能够做到不须要刹车。刚开始还有点不适应，然而过一段时间很快会发现这才是汽车原本应该的样子。分布式和云原生也应该是数据库原本应该的样子，将来的支流数据库默认都会具备面向云的灵活性、简略性和开放性，包含：
1) 面向云的灵活性： 具备任意扩大，反对按需扩大存储容量和计算能力，反对按需付费（Pay as you go）。反对客户从小到大全生命周期的数据库需要，当客户业务量很小时，能够抉择很小规格的独立实例（比方 4C8G）、甚至共享实例或者按申请付费（Serverless）；当业务量逐渐减少时，可能很灵便地减少数据库的存储和计算能力；当业务量跨过洪峰回归惯例时，可能很平滑地依照需要动静缩容来降低成本。
2) 面向云的简略性： 无论是性能，还是运维，让用户少做抉择甚至不做抉择。尽可能由数据库实现数据主动分片、主动容错、跨服务器分布式事务等操作，兼容 MySQL/Oracle/PostgreSQL 等用户接口。反对 HTAP 混合负载，晋升查问优化和自适应解决能力，尽可能减少用户配置。
3) 面向云的开放性： 以繁多“云原生”，到客户为核心的多云原生，缩小 IaaS 层依赖。反对“一库多云”、“一库多芯”，可能按业务须要疾速高效适配新的云平台和 CPU 等新硬件。
为此，咱们提出了 OceanBase 4.0 单机分布式一体化理念，让分布式成为数据库的基石而不仅仅利用到可扩大这一细分场景。为了达成这个指标，咱们既要扩展性，也要残缺的 SQL 性能和极致的单机性能，从小到大反对用户全生命周期的业务。因为单机分布式一体化架构将入门门槛升高到与集中式数据库根本相当，且在面向云的高可用、可扩大、性价比上具备显著劣势，我认为，该架构会逐渐成为支流，并且倒退出一个与 MySQL、PostgreSQL 平行且同等量级的开源社区。因而，咱们决定从 OceanBase 4.0 开始把开源分支和商业分支对立成为一个分支，放慢开源社区的倒退。
必须攻克的难关：动静日志流交融单机分布式
单机分布式一体化架构要求兼具分布式的扩展性和集中式数据库的性能和单机性能。事务的 ACID（Atomicity，Consistency，Isolation，Durability）是数据库的根本要求，而分布式数据库的难点就在于如何在异样场景下保障事务的 ACID，外围就是如何基于重做日志（Redo log）实现故障复原，以及基于重做日志实现异样场景下分布式事务的原子性。
咱们首先看看业内的已有计划：
A) 服务器级动态日志流： 典型的代表是基于中间件 + 开源数据库（MySQL/PostgreSQL）分库分表的计划。数据库辨别主库和备库，主库将重做日志同步到备库。这种计划不反对分区级的细粒度迁徙复制，也就无奈实现在线程度扩大。当须要扩容时，往往采纳按倍数扩容的计划，且扩容过程会影响业务，由 DBA 手动执行。
B) 分区级动态日志流： 典型的代表是 CockroachDB/TiDB 代表的 NewSQL 数据库，以及 OceanBase 1.0~3.0 版本。每个数据分区 / 数据分片有独自的日志流，反对分区级的细粒度迁徙复制，反对程度扩大。这种计划的问题在于分布式开销与分区的数量成正比，单台服务器反对的表格数量有下限，即便业务的数据能够全副放到一台服务器上，也须要接受分布式相干的 overhead。
C) 日志与数据拆散： 典型的代表是 FoundationDB 数据库。将存储服务器和日志服务器拆散开来，写事务只写日志服务器，存储服务器会定期从日志服务器拉取日志并利用到本地从而服务读申请。这种形式的问题在于存储服务器上的数据有很短的提早，影响读取最新数据的效率。
计划 A 的益处在于防止了分布式 overhead，单机性能更好，然而无奈实现在线程度扩大；计划 B 的益处在于反对在线程度扩大，但引入了分布式 overhead，会造成额定性能开销；计划 C 的益处在于部署灵便，但会影响读取性能。 因而，从 OceanBase 4.0 版本开始，通过动静日志流将计划 A 和计划 B 交融起来，兼具单机性能和分布式的程度扩大能力。 当零碎处于稳固状态时，动静日志流相似计划 A，每台服务器只有固定数量的日志流；但与计划 A 不同的是，OceanBase 4.0 反对将一个分区从一个日志流迁徙到另外一个日志流，这意味着能够实现与计划 B 相似的分区级在线程度扩大能力。 这个看似不难理解的计划，但实现起来却极具挑战，举三个理论的场景：
第一，当一个分区从一个日志流迁徙到另外一个日志流时，如何确保迁徙过程是原子的，也就是说，无论产生任何异样，该分区的所有的正本要么全副迁徙胜利，要么全副迁徙失败；
第二，分区迁徙时，如何确保不会影响正在进行中的事务，咱们必须思考到这种状况，有些事务可能做到一半或者该事务正在运行的 SQL 语句做到一半；
第三，分区迁徙时，如何确保上游总是订阅到正确的数据，无论什么状况产生，不会失落也不会反复；
OceanBase 4.0 解决了这些技术难题，实现了在线程度扩大的同时不减少分布式相干 overhead，从而可能像集中式数据库一样部署在小规格的服务器上，做到单节点性能达到甚至超过集中式数据库的程度。
为多云架构而生：从云原生，到多云原生
云计算从诞生之初到当初经验了屡次技术迭代，从最早的托管虚拟机，到托管服务，再到明天的多云和 Serverless，一直谋求灵便、简略、凋谢。OceanBase 4.0 正是为多云架构设计的。
灵便：内置主动程度扩大
云上用户从小到大倒退过程中，从共享实例，到小规格实例，到大规模实例，再到最初的分布式计划。OceanBase 通过内置的多租户隔离架构，可能实现共享实例，从而尽可能降低成本。 当用户的业务量越来越大时，通过单机分布式一体化架构，能够逐渐从小规格实例扩大到分布式实例，小规格实例没有分布式相干 overhead，分布式实例既能扩大存储容量，也能扩大计算能力。反对 Pay as you go 的计费模式，既反对疾速扩容，也反对疾速缩容。
咱们还将摸索 Serverless 计划，从而实现按申请付费。Serverless 计划波及到几个重要的技术点：
- 当用户齐全没有申请时，数据库是否做到零耗费？
- 如何疾速弹性扩缩容，当计算节点产生故障时，如何疾速拉起新的计算节点持续提供服务，做到秒级甚至更低？
- 如何掂量不同 SQL 申请的开销，从而实现按申请计费？有些 SQL 可能很简略，有些 SQL 可能很简单且须要拜访大量数据。
这些问题都很有意思，也欢送大家和咱们探讨。
简略：HTAP = OLTP+
OceanBase 4.0 心愿升高数据库选型和运维的复杂度，尽可能用一套数据库满足不同场景的需要。一方面，单机和分布式的架构差别能够通过后面提到的动静日志流计划对立起来；另一方面，咱们看到市面上大部分 NoSQL、NewSQL 以及 OLAP 零碎底层的存储引擎都是类 LSM Tree 架构，能够在一套零碎中实现 OLTP、实时 OLAP、Key-Value、JSON、GIS 等多种数据模型的解决，防止用户因为基础设施能力有余而采纳多套零碎。
我并不反对 ”One Size Fit All”，单机分布式一体化架构也不是万能的，然而，我认为，在不怎么就义性能老本的前提下 ”One Size Fit Bunch”。依照这个思路，我在前一段时间写了一篇文章《真正的 HTAP 对用户和开发者意味着什么》： 我认为的 HTAP 其实就是 OLTP+，先有高性能的 OLTP，而后在 OLTP 的根底上反对实时剖析，并减少 Key-Value、JSON、GIS 等多模反对，适宜在线查问和在线剖析业务，对于离线剖析和大数据分析并不是最优的。
凋谢：面向多云的存储计算拆散
OceanBase 晚期版本反对本地部署，起初逐渐反对阿里云和 AWS 等多云部署，存储计算拆散是云数据库的标配，有两种设计思路：
第一种，数据库外部实现存储计算拆散。 具体做法是将数据库辨别为 SQL 层和 KV 层，SQL 层无状态用来做计算，KV 层用来做存储。这种形式的益处是实现简略，能够把可扩大和高可用等分布式个性下移到 KV 层，事务处理构建在一个可扩大、高可用的分布式 KV 之上；当然，问题也十分的显著，这个计划就义了性能和开放性，每次 SQL 操作都须要一次 RPC 交互且须要首先将内部数据导入到数据库中。
第二种，数据库与文件层之间做存储计算拆散。 具体做法是抛开 SQL 和 KV 分层计划，数据库读写数据块时反对本地或者近程的各种分布式文件系统，数据库用来做计算，文件层用来做存储。这种形式最大的难点是须要将高可用和可扩大的解决融入到分布式事务，实现简单，益处是保障了性能和开放性，数据库外部的 SQL 和 KV 模块之间不再须要 RPC 交互，且可能适配多云平台上的各种存储系统。
OceanBase 4.0 抉择了第二种计划，我称之为“凋谢的存储计算拆散”。 另外，为了更好地适配不同云平台，OceanBase 在设计存储格局时升高了对外部文件系统的依赖。OceanBase 存储引擎是类 LSM Tree 格局，将 SSTable 划分为 2MB 大小的宏块，LSM Tree 引擎执行 Compaction 操作时，只有批改过的 2MB 宏块才须要被重写。每次写宏块操作都是异步的，抉择 2MB 宏块大小也可能很好地施展不同云平台上各种分布式文件系统的性能。
通过这种形式，能够升高对底层存储系统的依赖，用户可按理论业务需要，将数据库部署到不同的云平台甚至多云，并确保零碎稳固和高性能。
小就是大：为规模化而战
我认为将来单机分布式一体化畛域会倒退出一个与 MySQL、PostgreSQL 等同规模的技术社区，这类零碎也会有百万量级的企业用户。依照“二八原理”，大部分用户的数据一台机器就能放下，但用户也有疾速倒退业务的需要，一体化架构可能很好地解决这个矛盾。分布式数据库的复杂度必定是远高于集中式数据库的，一体化架构可能在用户规模还小的时候将应用门槛升高到集中式数据库的程度，同时，不须要提前放心业务倒退带来的扩展性问题，一次抉择一生受用。为了扩充应用规模，须要：
第一，反对单机部署和小规格部署。 OceanBase 有一个很有意思的设计：每个分布式系统都会有一个总控节点，用于全局治理调度。OceanBase 的总控节点并不是一个独自的过程，而是一个服务 RootService，集成到 OBServer 外面。这个设计方案的益处就在于单节点部署只有一个过程，且可能在线减少 OBServer，既实现了单节点最低配置，又实现了单机和分布式架构的对立。OceanBase 4.0 将部署规格升高到 4C8G，且将来还会进一步升高。
第二，兼容集中式数据库的行为和应用形式。 作为一个全新的自研数据库，OceanBase 到明天为止依然保持兼容 MySQL 和 Oracle 的技术路线，原则上不发明新的应用语法。咱们心愿可能反对业务平滑迁徙，根本不批改业务代码即可由集中式数据库迁徙过去。OceanBase 3.x 曾经反对了存储过程、触发器、外键、XA 等性能，OceanBase 4.0 进一步加强了对通用 DDL、表锁、通用 LOB、GIS、JSON 等性能反对。
第三，走齐全开源的技术路线。 2021 年 6 月 1 日咱们发表正式开源，过后开源分支和商业分支还是两个不同的代码分支，由 OceanBase 研发团队定期将商业分支的代码 patch 到开源分支。这种形式导致 OceanBase 开源分支总是会落后商业分支一段时间，而 OceanBase 4.0 之后咱们更进一步，把开源分支和商业分支合并成一个代码分支，使得二者齐全同步。
稳固牢靠是第一因素：谋求极致性能和极致高可用
数据库作为根底软件，须要满足看得见的、看不见的很多需要，例如稳固牢靠、性能、老本、高可用、SQL 反对、易用性，等等。从 OceanBase 的技术理念角度看，首先必须确保稳固牢靠，所有其它需要都必须为之退让。例如，OceanBase 零碎外部有一个数据校验机制，主动对多个正本之间进行实时的事务一致性校验和定期的基线数据一致性校验，为了实现该校验性能，会就义一些性能，且对存储格局的设计方案有肯定束缚，但这是必须要做的， 稳固牢靠是咱们为客户坚守的第一因素，也是 OceanBase 数据库最根本最奢侈的第一准则。
数据库实质的货色还是跑得有多快，老本做到多低。只有谋求极致性能的数据库才能够利用到外围场景。数据库的性能相当于芯片的制程，有的数据库性能差，相当于是 28nm 技术，也能利用在一些模仿芯片的场景，有些数据库性能好，相当于是 7nm 技术，可能利用在所有场景，包含对性能要求很高的手机等。
OceanBase 4.0 应用 C++ 语言，但咱们不容许应用 C++ 语言的高级性能（包含 C ++ STL），只应用 C++ class 等根底性能用于组织代码。咱们在数据库外部治理所有的内存和 IO 应用，而不是交给底层的操作系统。为了优化性能，咱们须要优化每个算子，尽可能减少每条 SQL 语句执行过程中的 CPU 指令数。对于一个分布式数据库，往往还会遇到如下性能挑战：
- 主备强同步。强同步会减少事务提交的提早，如果让 SQL 执行线程期待强同步返回，将会带来大量的线程上下文切换开销。OceanBase 的做法是异步化，SQL 执行线程提交同步工作后立刻解决下一条 SQL 语句，等到强同步胜利后再通过回调函数应答客户端。
- 类 LSM Tree 查问性能。类 LSM Tree 引擎读取时须要合并磁盘中的 SSTable 和内存中的 MemTable，这个操作会影响查问性能，波及到 Compaction 策略，查问算子的设计，等等，须要一直优化。
- 跨服务器操作性能。这外面既波及到分布式事务，也波及到 SQL 语句近程执行的性能，须要将 SQL 执行尽可能本地化，并一直优化近程执行的效率。
OceanBase 从 0.5 版本开始就将 Paxos 融入到数据库中实现无损容灾，明天，OceanBase 独创的“RPO=0，RTO < 30 秒“曾经成为数据库行业高可用的事实标准。当然，30 秒之内复原（RTO < 30 秒）并不是相对的，取决于大量分区 Paxos 选举的租约工夫和改选工夫。
随着 OceanBase 4.0 进入单机分布式一体化架构，再加上咱们进一步优化 Paxos 选举协定及全面探活机制，最终可能做到 RTO < 8 秒，给业务带来更强的的继续可使劲。 从 30 秒到 8 秒，这短短 22 秒的晋升看似简略，但背地非常复杂。举一个例子，F1 方程式较量中有一个必须的环节就是换胎，这个过程是争分夺秒的。从 1950 年代须要分钟级到当初最快记录 1.92 秒。数据库的运行就像继续运行的赛车较量，RTO 就像两头的换胎环节必须争分夺秒。而咱们更难的中央在于 F1 的换胎环节是提前布局，一个 10 多人的团队来实现的。但数据库的故障是任何工夫都可能产生，且齐全不须要人工参加。
写在最初：与用户和开发者独特成长
这次 OceanBase 发布会的 4.0 小鱼通过动静日志流实现了单机分布式一体化架构，反对单机小规格部署，在现场演练的环节咱们看到，在等同硬件环境下，OceanBase 4.0 单机 sysbench 基准测试性能好于 MySQL。同时，4.0 版本也具备面向多云的灵便、简略、凋谢，以及规模化输入的能力。 当然，每个版本走向成熟都离不开大量实在业务场景的打磨，Serverless 和 HTAP 等个性也在不断完善过程中。
OceanBase 4.0 的很多翻新和想法来源于用户的需要或者倡议，咱们也会始终保持 MySQL 模式齐全开源的策略，和咱们的用户、开发者一起，把单机分布式一体化架构真正做成数据库的支流，倒退出一个与 MySQL、PostgreSQL 等同规模的一体化数据库产品和社区。