单机分布式一体化数据库的架构设计与优化

作者：杨志丰，OceanBase产品总经理、首席架构师

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

本文摘自《OceanBase社区版在泛互场景的应用案例研究》，欢迎点击链接阅读详细内容。
综述

在OceanBase 十余年的技术演进中，共经历了三次大的架构升级：第一次架构升级是 OceanBase 0.1~0.5 版本（2010 年~2015 年），当时的 OceanBase 通过单写多读架构实现了准分布式，包含 UpdateServer、ChunkServer、MergeServer 等多种不同的角色；第二次架构升级是 OceanBase 1.0~3.0 版本（2016 年~2022 年），OceanBase 成为一个对等的全分布式架构，所有节点可读可写，逐步支持了完整的 SQL 功能；第三次架构升级是OceanBase 4.0 版本，于2022年8月正式被提出，是业内首个单机分布式一体化数据库。
OceanBase 4.0版本有一个形象的比喻叫做“小就是大”。这是因为，单机分布式一体化的核心是采用一套系统，实现从单机到分布式的转换，使用户无感知。通过单机分布式一体化架构，满足用户从小到大的业务规模化诉求：用户无需关心集中式或分布式技术路线选型，可以在业务量小的情况下从小规格单机部署起步，使用完备功能的单机部署形态，随着业务压力的变化将数据库从单机平滑扩容到多机甚至超大规模的分布式集群，同时具备多机平滑缩容到单机的能力。也就是说，通过一套数据库满足业务从小到大的集中式和分布式架构诉求，用一个系统满足每一个用户业务从小到大的全生命周期数据存储与管理需求。
本文从技术角度简要介绍单机分布式一体化架构的设计思路、技术优化和业务价值。
一、三次架构迭代，从分布式到单机分布式一体化

（一）从原生分布式到单机分布式一体化的技术挑战

OceanBase 从 2010 年开始研发，彼时分成存储和计算两层。上层是无状态提供 SQL 服务的服务层，下层是由两种 server 共同组成的存储集群。这样的架构具备一定的扩展性，尤其是读扩展性较强，并且 SQL 层是无状态的，可以自由伸缩。但该架构最大的问题是单点写入、多点读，导致在更大规模并发要求下，无法扩展。同时，存储层和SQL层的割裂使时延难以控制。
为解决上述问题，OceanBase 摒弃之前的架构，发展出了 OceanBase1.0 ~3.0 的架构，所有的节点都可以在处理 SQL 的同时，处理事务并保存数据。如图1所示，纵向为分布式可扩展层，通过不断加机器提升扩展性；横向为复制层。提供服务高可用能力。

图1 OceanBase1.0-3.0架构
在该架构下，OceanBase成为彼时唯一通过 TPC-C 测试的分布式数据库，证明了该架构的扩展性和并发处理能力可以满足绝大多数当前世界上在线服务系统需求。
但随着业务需求的迭代，OceanBase在走向通用数据库的道路上，希望能够支撑更小规模的应用。但卡点在于：3.0版本的架构下，事务日志流数目和存储分片数是对应绑定的，存储分片的粒度决定事务处理和高可用能力是相应粒度，这就导致存储分片增多，日志流随之增多，在越小规模的业务系统中，开销显得越大。因此，需要将存储分片数和事务日志流解耦，让若干个存储分片共享一个事务日志流以及这个日志流对应的高可用服务，实现扩展性与成本的平衡，以更好地支撑小规模应用。
此外，考虑到业务的发展规律与生命周期，数据库需要具备从支撑小规模应用的单机模式，平滑过渡为可处理海量数据的分布式模式。单机分布式一体化架构便被创新性地提出，该架构要求兼具分布式的扩展性和集中式数据库的功能和单机性能。事务的 ACID（ Atomicity，Consistency，Isolation，Durability）是数据库的基本要求，而分布式数据库的难点就在于如何在异常场景下保证事务的 ACID，核心就是如何基于重做日志（Redo log）实现故障恢复，以及基于重做日志实现异常场景下分布式事务的原子性。
为了真正实现一体化，需要解决如下三个关键的技术问题。
（1）应用透明： 从单机到多机不需要应用做改造，需要客户端支持动态路由技术，当后端数据库发生分区迁移时，能够动态路由到目的服务器上。另外，不管是单机还是分布式，需要支持全部的 SQL 功能。
（2）单机操作： 单机只有一个 redo 日志，单机事务写 redo 日志的方式和经典的单机数据库相似。经典的单机数据库采用B+树存储引擎，OceanBase 的技术创新是将 B+ 树数据分块的思路融入 LSM 树存储引擎，一方面能够像 LSM 树一样具备高压缩能力，并把热点数据放在内存中提供服务，另一方面通过类似 B+ 树的数据分块思路来减少 LSM 树的写入放大。在OceanBase 4.1版本中，即使在三台机器做强同步的情况之下无论是单机的性能还是存储成本都优于 MySQL 8.0。
（3）跨机操作： 跨机操作通过底层的分布式架构提供，上层的 SQL 功能不受影响。如果事务只涉及一台机器，走单机事务；如果涉及多台机器，通过两阶段提交实现分布式事务。另外，通过分布式、并行、异步化等技术手段尽可能地优化性能。
（二）可行性分析，如何消除分布式带来的overhead？


架构设计的首要任务是可行性分析，核心在于取舍。在设计OceanBase单机分布式一体化架构时，我们也做了这样的设计假设：对于一个分布式数据库，虽然能够处理的数据量很大，但大部分操作仍为单机操作（>80%），少部分操作才是跨机操作（