数据库管理-第263期 VLDB：OceanBase Paetica（20241118）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、年度墨力之星，ITPUB认证专家、专家百人团成员，数盟会长老会成员，OCM讲师，PolarDB开源社区技术顾问，HaloDB外聘技术顾问，OceanBase观察团成员，青学会MOP技术社区（青年数据库学习互助会）技术顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

本文参考内容： https://www.vldb.org/pvldb/vol16/p3728-xu.pdf
《OceanBase Paetica: A Hybrid Shared-nothing/Shared-everything Database for Supporting Single Machine and Distributed Cluster》

OceanBase在其4.0版本中引入了单机分布式一体化架构，OceanBase 4.0有个中文名叫“小鱼”，从OceanBase提交至VLDB的论文中，其还有一个英文名：Paetica，对应论文的全名为“一个支持单机与分布式集群的混合Shard-nothing/Shared-everything数据库”。

1 由大到小

在OceanBase 4.0之前的版本中，因为数据库原生分布式的设计，简单来说就是，部署一个OceanBase数据库需要多台服务器（或容器或虚拟机，其本身的设计目的也是为了承载大数据量和较高负载的业务系统。这就使得中小体量、压力的业务不适合使用OceanBase或使用成本较高，这限制了OceanBase在全场景的扩展。
OceanBase 4.0引入单机分布式一体化架构之后，OceanBase不再需要大规模的服务器为基础，仅需一台服务器也可运行，为中小型系统数据库提供良好的支持。源于统一底层架构设计，单机部署可以根据数据量与负载的变化横向扩展至分布式架构。

2 版本衍进

在OceanBase 0.5中，OceanBase架构被分为两层，即存储和计算层。上层为无状态的提供SQL服务的服务层，下层则是由块服务器（ChunkServer）和更新服务器（UpdateServer）两种服务器构成的存储集群。其中块服务器具有可以自动分区和水平可扩展存储能力的特点；而更新服务器则是利用Paxos协议来确保一致性和可用性。然而更新服务器不具备处理分布式事务的能力。这种架构有可确定的扩展性，相对较强的读能力。但由于更新节点是一个单点写入多点读取的架构，当需要更高级别并发性能时很难进行扩展。此外，存储与SQL分层会待料较高的查询延迟，网络抖动的难以控制带来了整体延迟控制的挑战。

在OceanBase 1.0-3.0中已经放弃了之前的架构，转变为完全的点对点（P2P）架构，每个OBServer都包含SQL、存储与事务引擎，所有节点在同时存储数据外还可以处理SQL与事务操作。如下图，垂直方向表示分布的和可伸缩的层，而水平方向表示复制层。水平方向提供了可用性，而垂直方向可以通过增加机器来提升性能。这样的架构具有卓越的扩展性。这里采用了一系列优化方案来降低延迟：在独立模式下，本地执行计划、本地事务API和消除读写操作中的网络开销是确保低延迟的关键特性；在分布式模式下，使用复制表、并行执行引擎和多个分区索引是确保低延迟性能的关键因素。

OceanBase 4.0的架构如下图所示，并带来了以下功能：

• 更多的分区：降低了分区维护成本，更低的元数据维护开销。对于具有较大磁盘的模型，元数据的开销也会显著增加。在这个迭代中，我们将存储内存开销设置为按需加载，因此只维护内存中的根节点（非常小）。当用户需要访问元数据时，然后加载叶节点和数据节点。该方法减少了驻留内存的开销，并带来了小尺寸内存优化的特点。
• 更多的DDL支持：在OceanBase 4.0中，数据定义语言（DDL）允许用户轻松地修改分区和更改主键，从而促进了现有的数据库使用实践。DDL的实现相对简单。最初，创建一个隐藏表，并使用获得的快照点启动pre-DDL事务。然后锁定原始表以进行读和写。随后，使用数据操作语言（DML）语句来补充隐藏表中的数据。最后，将重新命名为原始表。过程涉及三个关键技术，即1)表锁定，防止写操作在进行修改，2)分区DML（PDML），用于加速查询和简化代码，3)直接插入，允许直接写入静态数据，从而避免内存过载和提供更快的速度。
• 更少的资源消耗：在OceanBase 4.0中，生产规格从16C64G下降到4C16G，从而提高了用户效率。我们主要优化了以下方面，即1)线程堆栈优化以减少线程局部变量和使用SmartVar来减少堆栈变量，2)改进元数据开销从每个分区到每个日志流存储，从而允许元数据按需加载，3)通过默认激活输入限制提高稳定性，从而在4C16G下实现更大的稳定性。
• 租户隔离：优化了租户耦合逻辑，主要在以下三个方面：1)租户级合并，默认合并行为由租户触发而不是集群范围；2)租户级元数据，其中元数据从系统租户调整到用户租户，TableId和租户解耦；3)租户I/O隔离，Clog（提交日志）文件被分为租户和SSTable支持租户级I/O限制。

对于中小型企业，OceanBase 4.0架构的核心变化是引入动态日志流。最初，我们将事务扩展和存储扩展的粒度等同在一起。但是，如果存储被划分为多个分片，那么事务处理和高可用性能力也是基于这些分片的。我们已经在OceanBase 4.0中解耦了这两个概念，因此几个存储分片将共享一个事务日志流和与此日志流相对应的高可用性 服务。

3 2PC的变化

如下图，传统的分布式事务处理过程是被分为事务的开始阶段和提交阶段；而再下一张图则是OceanBase的事务处理过程。前者尝试减少2PC和同步复制的开销。OceanBase事务提交协议为参与者和协调器提出了一种新的方法，称为两阶段提交协议。


与传统2PC相比，OceanBase的2PC从事务提交到成功提交时的消息处理和日志量明显少于传统的2PC，这使得它在延迟方面具有很大的优势。这一优势还将支持OceanBase在分布式场景中的事务处理能力，而不像其他分布式数据库那样承担了巨大的开销。访问GTS有两种方案：1）语句快照获取；2）获取事务提交版本号。对于独立的事务，1)不需要访问GTS，它已经在OceanBase 4.0中进行了优化；2)交易提交版本号将获得GTS，以满足外部一致性，但该获取只是一个接口调用，并不会实际发送RPC，因此效率相对较高。

总结

本期通过OceanBase在VLDB中论文的部分内容进行解读，简单介绍了OB 4.0的一些创新性特性。
老规矩，知道写了些啥。