跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）

这是白皮书的第三篇

2.3 OceanBase 4.0

OceanBase 4.0 及其特性

OceanBase 4.0 架构开发是为了更好地支持中小企业，其核心的变化是引入了动态日志流。在之前的版本中，事务扩展和存储扩展的粒度是绑定的，但在 OceanBase 4.0 中这两个概念被解耦，多个存储分片共享一个事务日志流和高可用性服务。

这样做是为了支持更小规模的应用，因为如果日志流的数量和分区的数量绑定在一起，在很多场景下无法适应中小企业的支持。换句话说，如果日志流太多，在较小的规模下，开销会显得更大。

除了动态日志流，OceanBase 4.0还有以下特点：

• 更多分区： 降低了分区维护的成本，并优化了内存，将存储内存开销变为按需加载，只在内存中维护根节点，需要时再加载叶节点和数据节点。
• 更多 DDL 支持： 允许用户轻松修改分区和更改主键，方便了现有的数据库使用习惯。这通过表锁定、分区 DML（PDML）和直接插入等技术实现。
• 更少的资源消耗： 将生产规格从 16C/64G 降低到 4C/16G（CPU/内存），提高了用户效率。主要优化了线程堆栈、元数据开销和稳定性。
• 租户隔离： 优化了租户耦合逻辑，主要体现在租户级合并、租户级元数据和租户 I/O 隔离三个方面。

单机与分布式集成数据库架构

OceanBase 4.0 的架构既可以使用分布式方式也可以使用单机模式（类似 MySQL）来使用 OceanBase 数据库。

• 在单机部署或作为 OceanBase 集群中的单容器租户时，OceanBase 可以提供与使用单机数据库相同的效率和性能。
• 在采用分布式模式时，无需在租户级别、事务级别和单个 SQL 执行级别支付额外的成本。

为了满足不同情况的需求并兼顾各个级别，OceanBase 4.0 在 SQL 层、存储层和事务层的架构设计中采用了单机与分布式集成架构。

Shared-nothing还是shared-everything,到底如何抉择？

数据库开发长期以来围绕着shared-nothing和shared-everything 架构展开争论。

如图 4 所示，物理集群既不是完全shared-nothing，也不是完全shared-everything。每台机器上的单个节点都是多处理器结构，具有大量的 CPU 以及强大的存储和计算能力。在对单机和集中式数据库进行扩展时，不应忽视这些功能，而应将其视为一个需要考虑的部分。分布式数据库应同时考虑水平扩展和垂直扩展。

为了利用硬件垂直扩展能力，应该考虑数据库的作用。可以想象这样一种分布式数据库。图 5 左侧是几种分布式数据库的实际架构图。它类似于 OceanBase 0.5 的结构，有专门的计算节点和存储节点。 计算节点构成一层，存储节点构成另一层。这两层是单独抽象出来的。其中，通过 GTM/TSO（全局事务管理器，时间戳预言机）处理全局事务的模块在进行多机交互时需要与该模块进行交互。

如图 5 右侧所示，如果将这个分布式数据库以一种非常简单的方式插入到一个节点中，并以单机方式运行，就会发现最大的问题。在单台机器上工作时，这些组件之间的交互成本非常高。对于像 MySQL 这样的单机数据库来说，这种开销本质上是一种额外的不必要的开销，因此很明显，这种简单的方法很难与单机数据库相提并论。

如图 5 右侧所示，如果这个分布式数据库是以非常简单的方式插入节点并作为独立运行，其中我们关注节点之间的协同，且这些节点的硬件配置不应需要特别的强悍。

单机与分布式集成：兼顾单机和分布式场景

图 6 展示了单机与分布式集成数据库的系统架构。在单机的情况下，必须有一个三层系统，分别由独立的 SQL 引擎、事务引擎和存储系统组成。相比之下，分布式数据库则将分布式 SQL 引擎、分布式事务引擎和分布式存储引擎结合在一起，形成三个独立的层。理想的情况是将单机和分布式系统的这三种引擎结合起来，同时使用相同的代码库，并允许动态交互和改变。

在单机模式和分布式模式之间进行转换时，需要进行数据迁移，并且迁移是在线进行的。为了减少对业务的影响，迁移分为两个部分。对于leader副本，第一步是切换leader，使要迁移的数据副本的角色变为follower，以确保上面没有读写操作。第二步是在follower副本上执行数据迁移。

单机与分布式集成架构要求数据库系统既具备分布式系统的可扩展性，又具备集中式数据库的功能性和单机性能。数据库的基本要求包括事务的 ACID（原子性、一致性、隔离性、持久性）属性。分布式数据库面临的挑战是在异常情况下如何确保事务的 ACID 属性。核心问题是如何实现基于重做日志的数据恢复，以及如何在异常情况下确保分布式事务的原子性。

单机数据库需要提供各种功能来最大限度地提高其可扩展性。在 SQL 层，这需要并行执行能力，而在事务层，必须支持多版本并发控制（MVCC）等可扩展的核心技术。此外，利用组提交等技术对于实现单台机器上多个事务的并发执行至关重要。最后，在存储层，必须支持单台机器上的并行 I/O，以充分利用多个磁盘和存储带宽。

在将单机数据库部署到分布式集群中时，提高分布式可扩展性并不是单一需要考虑的因素。为了获得令人满意的性能，必须优化单机效率，并且数据库必须能够高效地执行串行命令。此外，分布式事务必须能够进行自适应优化，以便能够成功地进行单机事务。

OceanBase 实现了一项开创性的技术，即单机与分布式集成 LSM-Tree 存储引擎，该引擎可以同时应用于单机和分布式场景。在前一种情况下，可以进行合并操作，前后之间没有干扰，而在分布式部署中，可以采用交错轮转压缩等分布式策略。 在其设计中，SQL 层、事务层和存储层都考虑到了单机和分布式场景，在这两种情况下都不会产生额外的开销，从而实现了 OceanBase 的设计目标。

因此，需要具备两个基本属性：

• 首先，在单机上工作时，OceanBase 没有额外的组件，即单个进程可以工作，而不需要冗余进程之间进行复杂的交互。在单进程多线程模型下，每个组件实际上都可以通过简单的函数调用来完成交互，这一点非常关键。

• 其次，图 6 中所有组件（SQL 层、事务层和存储层）之间存在垂直交互。如果是在单机上，则采用函数调用的方式进行交互；如果是在节点之间，并且需要进行节点之间的交互，则必须使用 RPC 进行交互。

根据上述Shared-nothing和Shared-everything组合架构，在每个 OBServer 节点内都使用函数调用来直接实现 SQL 引擎、事务引擎和存储引擎之间的通信，类似于单机数据库。为了实现多个节点之间的通信，对分层结构进行了放松，以便能够实现最佳、最合适和最有效的解决方案。例如，当来自一个节点的 SQL 向另一个节点上的 SQL 层发送消息时，后者将被授予访问其存储节点的权限。OceanBase 提供了直接访问远程存储的功能。这个概念也应用于事务处理层，以避免不必要的交互。

-------------------------------------------

总结：

1 分布式的适应场景，与应对单机市场的乏力

2 OB 发现了其中的问题，与加入支持单机部署元素，降低整体的功耗

3 OB 4.0 扩展了后续的部署的属性，OB 属于分布式数据库，同时也可以进军单体数据库市场。

4 OB 在日志流和整体架构上，与传统的分布式数据库是不同的。