2分钟论文: 为了满足小企业用户, OceanBas分布式日志系统像写文件一样写数据库,超简单

一、 对你有什么帮助

2024 年

自己写一篇 https://open.oceanbase.com/blog/16174519112

翻译：PALF: Replicated Write-Ahead Logging for Distributed Databases 文章 来解释日志流 ，现在重写一遍

每一次探索 都有价值，关键是你真正的深入探索下去 ，

希望你在分布式数据库方面 在入门方面有帮助

岗位信息

职位描述

1. 参与OceanBase日志系统的研发工作，包括但不限于Paxos一致性协议、数据库WAL、数据同步产品OBCDC等方向的功能设计与开发；
2. 参与OceanBase高可用架构相关的研发工作，包括但不限于RTO优化、故障检测、仲裁、备份恢复、物理备库等产品功能的设计与开发；
3. 参与OceanBase新一代共享存储架构的设计与开发工作；

二、 最少知识：文件系统 磁盘追加写代替随机写

十多年前，谷歌发布了大名鼎鼎的"三驾马车"的论文，

分别是

• GFS(2003年)，
• MapReduce（2004年），
• BigTable（2006年），

为开源界在大数据领域带来了无数的灵感，

其中在 “BigTable” 的论文中很多很酷的方面之一就是它所使用的文件组织方式，

这个方法更一般的名字叫 Log Structured-Merge Tree。

在面对亿级别之上的海量数据的存储和检索的场景下，

而这些强大的数据库都有一个共性，就是其底层使用的数据结构，

都是仿照“BigTable”中的文件组织方式来实现的，

也就是我们LSM-Tree 来提提高写入速度

解决了：传统方案的困境（如B+树）

• B+树是数据库的经典结构（如MySQL的InnoDB），但它的写入是"原地更新"（Update-in-place）：
  • 修改数据时直接覆盖磁盘上的原有位置 → 大量随机I/O。∙
  • 当数据量巨大时（如十亿级），随机写入成为性能灾难。

LSM-Tree（Log-Structured Merge Tree）的核心思想：将随机写入转换为顺序写入！

关键设计：

1. 内存缓冲层（MemTable）
   1. 所有写入先写入内存中的MemTable（通常用跳表实现），速度极快（内存随机写 ≈ 100ns）。
   2. 写入到此即返回成功 → 低延迟。.
2. 日志预写（Write-Ahead Log, WAL）
   1. 为防断电，写MemTable前会同步写一条日志到磁盘（顺序追加写，速度极快）
3. 磁盘层（SSTables）
   1. MemTable写满后，整个冻结并批量顺序写入磁盘（生成一个不可变的*.sst文件）。
   2. 关键点：每次写入都是追加（Append-only），形成大块连续数据 → 完全避免随机写！4.
4. 多层级合并（Compaction）
   1. 磁盘上的SSTables分层存储（L0, L1, ..., Ln），低层数据被高层覆盖。

2024 年 8 月 26 日至 8 月 30 日，

第 50 届 国际超大规模数据库大会（VLDB 2024） 在中国广州隆重举办。VLDB 作为全球数据库三大顶级学术会议之一，被誉为“数据库领域的奥运会”

OceanBase 有两篇论文成功入选 VLDB 2024。

其中包括：PALF: Replicated Write-ahead Logging for Distributed Databases

📌 核心

• WAL：先写日志再写数据 → 确保数据安全
• PALF：在 WAL 基础上 + Paxos 共识 → 让日志变得更可靠、更高效

本文深入解读

• 该篇论文中所阐述的 OceanBase 4.0 分布式日志系统 PALF（Paxos-backed Append-only Log File System）的架构设计和突出优势。
• PALF 基于 Paxos 算法设计并实现了分布式共识协议，

使 OceanBase 数据库能有效容忍运行过程中的机器故障等异常，原生支持数据库级高可用方案，同时高效搭载 分布式数据库事务引擎，支撑 OceanBase 提供极致的性能表现

• 目前，PALF 已经成功应用于 OceanBase 4.0 及后续版本中，有效支持了 OceanBase 数据库的高可用、高可靠、高性能特性，以及物理备库、备份恢复等重要功能
• 最少知识：WAL（Write-Ahead Logging，预写日志）

🔑 PALF 是什么？

OceanBase 4.0 设计了一个全新的日志系统：PALF (Paxos-backed Append-only Log File System)。 它最大的特点是：

1. 基于 Paxos 共识算法，让多个副本之间的日志保持一致。
2. 只追加写（Append-only），保证数据一旦写入不会被篡改。
3. 和数据库事务引擎深度融合，性能更强。

🚀 PALF 的优势

• 高可用：即使某台机器宕机，系统依然能正常工作。
• 高可靠：日志会在多个副本中保存，不会因为单点故障丢数据。
• 高性能：相比传统的分布式共识实现，PALF 在事务处理和大规模并发下效率更高。
• 功能支撑：PALF 不仅保证事务，还支撑了 物理备库、备份恢复 等关键功能。

三、论文 内容: 演化：从单机追加写到分布式日志系统

3.1 为什么要重新调整架构

很简单OceanBase3.0 版本 无法运行在 8G 内存主机上，根本无法大规模推广和学习。

OceanBase 数据库在 4.0 版本中重新设计其内部架构（“Redesigned Architecture”）

主要是为了解决其旧版本（1.0-3.0）在实际应用中遇到的两个主要挑战，

以便更好地适应不同规模的企业需求。

主要原因包括：

• 日志复制的开销过大：

1. 在 OceanBase 的旧版本中，事务处理、日志记录和数据存储的基本单位是表分区。

1. 由于每个服务器上可以创建数万个分区，导致存在大量与每个分区绑定的 Paxos 复制组。
2. 这种大规模的 Paxos 组数量会消耗大量资源，增加了部署和操作的门槛，且这些资源消耗往往没有实际意义。

原文：

In the previous version of OceanBase [46] (1.0-3.0), the basic unit of transaction processing, logging, and data storage was the table partition.

As an increasing number of applications have adopted OceanBase, we found that the previous architecture is not as wellsuited to medium and small enterprises as to large-scale clusters of large companies.

• 巨型事务问题：

1. 旧架构在处理涉及大量分区的巨型事务时面临挑战。
2. 一个事务可能跨越数万个分区，这意味着两阶段提交协议中会有数万个参与者。这会导致系统不稳定，并牺牲整体性能。

为了应对这些挑战，OceanBase 4.0 引入了一个名为 Stream 的新组件。

Stream 将多个数据分区、复制型预写日志系统（PALF）和事务引擎结合在一起。

原文：

To address these challenges, t

he internal architecture of version4.0 of the OceanBase database was redesigned [47].

A new component, Stream, has been proposed, which consists of several datapartitions,

a replicated write-ahead logging system, and a transaction engine

其核心思想是：一个 Stream 中的一系列分区【多个分区的日志，事务合并操作】

Stream 的核心理念在于

• 尽管数据库中的表仍然被分区，但事务和日志操作的基本单位变成了 Stream 中的一组分区，而非单个分区。
• 表分区本质上是存储在存储引擎中的一块数据。
• 事务引擎负责生成重做日志，用以记录 Stream 内多个分区的修改，并把这些日志存储在 Stream 的预写日志（WAL）

通过这种抽象，集群中复制组的数量可以减少到与服务器数量相同，从而消除了大规模复制组带来的开销。

这使得 OceanBase 4.0 在独立模式下（适用于中小型企业）能够实现与集中式数据库媲美的性能，

并通过增加机器轻松扩展到分布式集群（适用于大型企业）。

Stream 架构的创新设计

核心思想：逻辑聚合物理分区

• Stream 作为新单元：
  • 聚合多个数据分区（物理存储单元）
  • 统一事务引擎：为 Stream 内所有分区生成单组 Redo 日志
  • 统一日志系统：绑定一个 PALF 组（而非每个分区独立）

重构后的核心优势

1. 资源开销锐减
   1. Paxos 组数量从 数万级 → 服务器数量级（如 3 节点集群仅需 3 个 PALF 组）。
   2. 日志复制、选主开销降低 90%+。
2. 分布式事务优化
   • 原 10,000 分区事务 → 需 10,000 次 2PC 协调
   • 现聚合到 3 个 Stream → 仅需 3 次 2PC 协调
   1. 事务仅需协调 Stream 数量（而非分区数量），例如：
   2. 事务延迟从秒级降至毫秒级。
3. 弹性扩展能力
   1. 单机模式：默认每服务器部署 1 个 Stream，性能对标单机数据库。
   2. 分布式模式：新增机器自动扩展 Stream，线性提升吞吐（Active-Active 架构）。
4. 读写分离优化
   1. Leader 处理强一致性写 + 实时读
   2. Follower 支持最终一致性读（通过 CSN 保序），分担读负载。

3.2 PALF Architecture

PALF 架构概述:

• PALF 是一个由多个复制组（称为 PALF 组）组成的复制型日志系统。
• 每个 PALF 组包含多个 PALF 副本，这些副本部署在不同的服务器上，以实现容错。
• 事务引擎可以像操作普通追加写入式文件一样，向 PALF 组追加日志并从中读取日志。

PALF 的三层架构: PALF 由三个主要层组成，分工明确：

1. 接口层 (Interface Layer):
   • 日志通知器 (Log Notifier)：在领导者（Leader）中，负责通知事务引擎日志是否已提交。
   • 日志重放器 (Log Replayer)：在跟随者（Follower）中，负责将日志条目中记录的修改重放到事务引擎。
   • 角色协调器 (Role Coordinator)：当 PALF 副本的角色发生切换（例如，从领导者切换到跟随者，或反之）时，它会向角色协调器发送角色变更信号，由角色协调器进一步通知事务引擎进行角色转换。
   1. 位于最上层，提供用户接口并协调 PALF 与事务引擎的状态。
   2. 它的设计目的是隔离数据库特性对 PALF 的影响，从而提高 PALF 的通用性。
   3. 包含以下关键组件：
2. PALF 副本层 (PALF Replicas Layer):
   1. 中间层，负责日志复制、重配置和日志存储。
   2. 日志序列器 (Log Sequencer)：为每个记录分配一个单调递增的日志序列号 (LSN)，该 LSN 在 PALF 组内唯一标识一个日志条目。
   3. Paxos 协议：日志条目（作为日志入口封装）按照 LSN 的顺序复制到其他 PALF 副本（跟随者）并由其持久化。
   4. 日志提交：一个日志条目仅在多数 PALF 副本持久化它之后才被提交。
   5. 领导者选举：PALF 的领导者候选者由独立的选举模块选举产生，这与一些将领导者选举和日志复制绑定在一起的 Paxos 变体不同。
   6. 重配置模块 (Reconfiguration module)：负责管理 PALF 组成员关系。
3. PALF 运行时环境 (PALF Runtime Environment / PALFEnv):
   • RPC 接口：用于处理远程过程调用。
   • LogStorage：所有 PALF 副本的日志条目都以固定大小的块形式存储在各自的独立目录中。
   • MetaStorage：存储所有 PALF 副本的元信息，如成员关系。
   • BlockGC：负责在日志块不再需要时进行修剪（垃圾回收）。
   • 统一的 I/O 工作池 (Uniform I/O worker pool)：PALF 副本发出的所有 I/O 请求都由该统一池处理。
   1. 最底层，在每台服务器上激活，用于提供远程过程调用 (RPC) 接口并管理 PALF 副本的磁盘资源。
   2. 包含以下功能和组件：

3.3 具体过程

分层设计 1， 接口层，2 事务引擎(PAlF层) 和 3 传输层

原文：

PALF consists of three main layers:

• the interface layer,
• the PALFreplicas layer,
• and the PALF runtime environment.

The lower twolayers take charge of log replication, reconfiguration, and log storage;

事务引擎 修改内存变更 通过AOF方式追加文件中，通过PALF同步到其他副本节点

如图 1 所示

• 步骤 2-3 事务可以直接在内存存储引擎中修改数据。
• 步骤 4 生成的日志记录会被追加到 PALF 中
• 步骤 5 在领导者节点上，事务引擎将 PALF 当作本地的日志文件系统来处理，它只关心日志记录是否已经被刷新到磁盘。PALF 的职责是将领导者节点上执行的修改复制到其他跟随者节点上
• 步骤 6 一旦 PALF 提交了日志，领导者节点就会通知事务引擎操作的结果
• 步骤 7-8随后，跟随者节点会重放领导者节点执行过的所有修改

在PALF group，事务引擎生成的日志记录首先会被发送到领导者节点。

随后，日志序列号器会为每条记录分配一个递增的日志序列号（LSN），

这个LSN在PALF组内是唯一的，用于标识特定的日志条目。

这些记录将被封装成日志条目，并通过Paxos协议按照LSN的顺序复制到其他PALF副本（跟随者节点）中，并在那里持久化存储。

四、小结

1. 聚合分区 减少传输。
2. 抽象系统接口，用户像追加写文件一样。

预告：Paxos协议

参考资料

• Mini-LSM：可能是史上最完整的 LSM-Tree 存储课程
• https://open.oceanbase.com/blog/16174519112

历史文章：

2分钟论文：网卡直写磁盘，这项专利彻底绕过了 CPU！