# 从 LSM-Tree 原理到 OceanBase 存储架构实践

&emsp;&emsp;在前面的文章中我们提到，OceanBase 和 TiDB 这两款主流分布式数据库并没有沿用传统的 HEAP 或 B+ 树存储引擎，而是选择了 `LSM-Tree` 架构。事实上，`LSM-Tree` 近年来在业界颇受欢迎——无论是大数据领域的 HBase、Cassandra，还是 LevelDB、Lucene（ES 的底层引擎），或是分布式 `NewSQL` 领域的 OceanBase 、TDSQL 新敏态存储（现名 TDSQL Boundless）以及 TiDB 底层的存储 `RocksDB`，都采用了 `LSM-Tree` 作为核心存储引擎。这期文章，我们就以 OceanBase 为例，来深入聊聊 `LSM-Tree` 的设计原理与工程实践。

## 1. LSM-Tree

## 1. LSM-Tree

### 1.1 概念

&emsp;&emsp;**LSM 树（`Log-Structured Merge-tree`，日志结构合并树）** 是一种专为高吞吐写操作设计的持久化存储数据结构。它并不是一棵具体的物理树，而是一种将**内存数据结构**与**磁盘文件系统**结合的多层存储架构思想。

&emsp;&emsp;传统数据库（如 MySQL InnoDB）采用的 B+ 树依赖“就地更新（In-place Update），在面对海量写入时会导致大量的磁盘随机 I/O。LSM 树的核心思路是 **将随机写转换为顺序追加写（Append-only）**，以此榨干机械硬盘和 SSD 的极限写入带宽。

### 1.2 LSM 树的核心架构组件

LSM 树将存储层分为**内存组件**与**磁盘组件**两部分：
![image.png](https://developer.qcloudimg.com/http-save/yehe-8568070/e0123619d1ec84f68123bb3fd10b8a9e.png)

#### 1. 内存层（Memory）

- **WAL（预写日志）**： 所有写操作在进入内存前，会先以顺序追加的方式写入磁盘上的 WAL 文件，用于崩溃恢复。这一机制是几乎所有数据库的共性设计——只要内存的成本仍远高于磁盘，WAL 就不会退出历史舞台。
  
  - WAL 只为**内存中的 MemTable** 提供崩溃恢复担保，`MemTable` 刷盘生成 `SSTable` 后，对应的 WAL 即可 **整块物理删除** 。
  - `InnoDB` 的 `Redo Log` 为 **内存中的 Buffer Pool**​  提供崩溃恢复担保，以固定大小循环覆盖使用；崩溃恢复时，`Redo Log` 需要与磁盘上 B+ 树旧页的 LSN 进行比对校验，将未落盘的数据页恢复到一致状态。
  - 两者的本质差异在于：**LSM-Tree 的 WAL 是"一次性消费"，而 InnoDB 的 Redo Log 是"循环复用"。**
- **MemTable（内存表）：** 驻留在内存中的有序数据结构（通常基于跳表 `SkipList` 或红黑树实现），负责直接处理所有的数据写入。
  
  - 在 `LSM-Tree` 的设计哲学中，`MemTable` 将所有修改、更新、删除操作，在逻辑上统一转化为了 **"插入"** 操作。由于数据操作全程在内存中完成，无需磁盘 I/O，因此能够提供极致的写入与读取性能。
  - `InnoDB` 的写入需要先定位到 `Buffer Pool `中的目标数据页，对记录进行**原地更新**，修改现有行或标记删除（ purge 线程后续异步清理）。这意味着 InnoDB 的写入路径上伴随着数据页的查找、加锁与可能的页分裂，且脏页最终需要随机刷回磁盘。
  - `MemTable` 的 "一切皆插入"​ 规避了原地修改的复杂性，将所有的写压力转化为内存中的顺序/随机插入，再异步批量落盘，这也是 `LSM-Tree` 写入吞吐通常高于 B+ 树的核心原因。
- **Immutable MemTable（冻结内存表）：** 由于内存空间有限，当 `MemTable` 达到大小阈值后，系统会触发**冻结（Freeze）** 机制：当前 `MemTable` 被切换为只读状态（`Immutable MemTable`），同时系统会立刻开一个新的 `MemTable` 继续接收新数据。
  
  - `LSM-Tree ` 的 **“写冻结、后台刷”** 的设计，巧妙地将原本需要同步等待的磁盘落盘操作，转化为了后台线程的 **异步 Flush 任务**，从而彻底解耦了用户写入与磁盘 I/O，保证了写入的低延迟。
  - `InnoDB` 依赖 **Checkpoint 机制**​ 来推进刷脏页：当 `Buffer Pool` 中脏页比例过高或 `Redo Log` 空间即将写满时，后台线程会将脏页随机刷回磁盘 B+ 树中。虽然 InnoDB 也尽力将刷盘异步化，但脏页的**随机写特性**以及 Checkpoint 推进不及时时可能触发的**前台线程同步刷脏**（Sharp Checkpoint），都会对写入延迟造成抖动，为此，`Innodb` 引入了 `Fuzzy Checkpoint `、组提交等机制。

#### 2. 磁盘层（Disk）

- **SSTable（Sorted String Table，排序字符串表）：** 磁盘上的**不可变文件**。内部记录按 `Key` 升序排列，并包含索引块（`Index Block`）和布隆过滤器（`Bloom Filter`），以支持高效的点查与范围扫描。一旦生成，`SSTable` 永不修改，后续的更新和删除只是往新的 `SSTable` 中追加记录，并通过 `Compaction` 机制在后台异步回收旧版本数据和墓碑。
  
  - SSTable 是**写后即只读**的，任何"修改"都不会触碰已有文件，而是写入新的 SSTable，这彻底消除了随机写和原地更新的复杂性。代价则是需要后台 `Compaction` 来回收空间。
- **Multi-Level（分层组织）：** SSTable 在磁盘上按层级（Level 0, Level 1, Level 2...）存放，层级越高，存储的数据量越大，且数据整体呈"冷→热"分布——L0 靠近写入端，数据最新、最热；越往下层，数据越旧、越冷。每一层内的 `SSTable` 文件之间 `Key` 范围互不重叠（L0 除外），且层间容量通常呈十倍递增（如 RocksDB 的 10 倍放大策略），形成天然的"漏斗"结构。

### 1.3 LSM-Tree 的优点

#### 1.  极致的写入吞吐量（转随机写为顺序写）

&emsp;&emsp; `LSM-Tree` 采用追加写机制。所有写操作（插入、更新、删除）先写入内存的 `MemTable`，满后异步**顺序批量刷盘**生成 `SSTable`，彻底消除了写入时的随机 I/O 。

#### 2. 超高的数据压缩比与空间利用率

&emsp;&emsp;磁盘上的 SSTable 是完全只读且不可变（`Immutable`）的，且内部数据按 Key 严格排序。静态文件的特性使其非常适合进行高效的前缀压缩、字典编码或通用压缩（如 `ZSTD`、`Snappy`），显著节省磁盘存储成本。

#### 3. 高并发下的无锁/轻量锁写入

&emsp;&emsp;内存写入通常采用无锁或轻量锁的数据结构（如跳表 `SkipList`），避免了传统 B+ 树在并发修改时复杂的锁竞争（如树结构调整时的 ` Latch Crabbing` 锁机制），并发写入吞吐极高。

#### 4. 对 SSD 硬件寿命友好

&emsp;&emsp; `LSM-Tree` 通过内存缓冲与后台合并，将小块写入整合成大块连续写入，极大地减少了 SSD 的物理擦除次数，显著延长硬件寿命。

### 1.4 LSM-Tree 的缺点

发现 LSM 树优点太多了，那它有什么缺点呢？

#### 1. 读放大问题

- **表现：** 当读取一个数据（Key）时，如果该数据不在内存中，系统可能需要依次检索 Level 0 到 Level N 的多个 `SSTable` 文件才能找到最新版本的数据。
- **缓解方案：** 引入布隆过滤器（`Bloom Filter`）快速判断 Key 是否存在于某文件，以及使用 **Block Cache** 缓存频繁读取的数据块。

#### 2. 写放大与 CPU/IO 抖动

- **表现：** 数据虽然最初是顺序写落盘，但后台的 Compaction（合并）进程会不断地把旧 SSTable 读取出来、排序合并后重新写回磁盘。一个数据在生命周期内可能会被重复写入磁盘多次。
- **后果：** 当后台 Compaction 压力过大时，会抢占磁盘 I/O 和 CPU 资源，导致前台业务写入产生明显的**延迟抖动**。

#### 3. 空间放大问题（Space Amplification）

- **表现：** 由于采用追加写，更新和删除操作只是追加一条带新版本号或墓碑标记（Tombstone）的记录，旧版本数据和被删数据依然保存在磁盘上。
- **后果：** 在后台 Compaction 完成清理之前，这些“垃圾数据”会暂时占用额外的磁盘空间。

#### 4. 范围查询（Range Scan）性能相对较弱

- **表现：** 检索某段区间的数据（如 `WHERE id BETWEEN 100 AND 200`）时，由于相同范围的数据可能分散在不同的 `SSTable` 文件中，系统需要对多个 `SSTable` 进行归并排序，相比 B+ 树在单一连续页上的顺序扫描，效率稍逊一筹。

## 2. OceanBase 的存储架构

&emsp;&emsp; `OceanBase` 的 `LSM-Tree` 存储架构设计核心在于解决传统 `LSM-Tree` “读放大” 与 “写放大” 的天然矛盾，结合了内存数据库的高性能与 `LSM-Tree` 的高吞吐特性。

### 2.1 设计原则

OceanBase 采用**准内存与读写分离** 的设计原则：

- **写数据（追加更新）：** 所有的更新、插入和删除操作均不直接修改磁盘上的原始数据，而是作为增量记录追加写入内存（`MemTable`）。写路径先写 WAL 保证持久性，再写入 `MemTable`。
- **读数据（多版本融合）：** 查询时需要将磁盘中的静态基线数据（`Base SSTable`）与内存/磁盘中的动态增量数据（`MemTable` / `SSTable`）进行多版本合并。

为了解决` LSM-Tree` 读路径过长和读放大严重的问题，`OceanBase` 建立了**多级缓存架构（KVCache）**：

1. BloomFilter Cache ，建立在磁盘宏块（Macro Block）上的**布隆过滤器**缓存，拦截并**提高空查询的效率**，防止无用 I/O。
2. Row Cache，直接缓存**热点数据行**，如果这行数据很热，**Row Cache** 直接把这一行缓存在内存中。GET 操作（点查）命中 Row Cache 可直接返回，跳过复杂的 LSM 树多版本归并过程。
3. Block Cache，缓存从磁盘读取并解压后的热点数据微块（Micro Block），减少磁盘数据解压带来的 CPU 消耗。
4. Block Index Cache，缓存热点微块的索引，加速微块数据的访问。
5. Fuse Row Cache，缓存“熔合结果”（行的快照点数据），即使内存和磁盘都有缓存，每次读都要把“磁盘基线页”和“内存增量段”拉出来现场做一次重组（Fuse），CPU 消耗极高。**Fuse Row Cache**（熔合行缓存）直接把**重组好之后的、最终形态的那一行数据**缓存在内存里。只要这行数据后续没有新的写入，下一次点查直接拿走最终快照，绕过了 `LSM-Tree ` 复杂的合并读取流程。

### 2.2 动态数据和静态数据

#### 1. MemTable

&emsp;&emsp;动态数据结构（`MemTable`）是 `LSM-Tree` 中增量数据在写内存中的组织形式，每个分区对应一个 `MemTable`。插入、更新、删除时，数据写入内存块，由 **BTree** 和 **Hash Table** 双索引指向对应数据指针。

&emsp;&emsp;传统的 LSM-Tree（如 RocksDB）在 MemTable 中通常只采用单一的 **跳表（SkipList）**。跳表虽然能够以 $O(\log N)$ 的复杂度同时支持插入、点查和范围扫描，但在极高并发的 OLTP 场景下存在两大局限：

1. **点查性能不极致：** 点查（根据 Key 获取 Value）在跳表中仍需 $O(\log N)$ 的指针跳转，远不如 Hash 索引的 $O(1)$。
2. **CPU 缓存命中率低：** 跳表节点零散分布在内存中，频繁的指针追溯对 CPU Cache 极其不友好。

&emsp;&emsp;在此架构下，内存中的 MemTable 被拆分为**数据存储区** 与**索引区**：

- **Hash Table（哈希索引）—— 极致的点查加速 ($O(1)$)**
  
  - **作用：** 专门服务于 `SELECT * FROM t WHERE id = 123` 或 `UPDATE/DELETE` 这类基于主键/唯一索引的点查与更新操作。
  - **原理：** 将 Key 进行 Hash 映射直接定位到槽位，指针直接指向数据区中的最新行版本。避免了树形结构的层层比较，将点查延迟降低到物理极限。
- **BTree （B 树索引）—— 高效的范围扫描 ($O(\log N)$)**
  
  - **作用：** 专门服务于 `WHERE id >= 100 AND id < 200` 或 `ORDER BY` 这类范围查询与归并合并（Compaction）操作。
  - **原理：** BTree 的叶子节点之间天然有序且节点连续（相比 SkipList，对 CPU Cache 更友好）。范围查询时通过 BTree 快速定位到起始 Key，随后沿着叶子节点顺序遍历指针即可。
- **Data Heap / Block（真实行数据区）**
  
  - **存储内容：** 存放实际的 Key-Value、多版本控制信息（MVCC 的事务时间戳/版本号）以及修改标记（如 Tombstone 墓碑）。
  - **解耦设计：** 索引节点不直接嵌套完整数据，只保存指向数据区的 64 位内存指针。这种“索引与数据分离”的设计，使得构建双索引的开销被降至最低。

| 数据结构       | 优点                  | 缺点                           |
| -------------- | ----------------------- | --------------------------------- |
| **BTree**      | 数据按主键有序，适合**范围查询**。     | 单行查找需进行大量主键比较，理论性能比 Hash Table 慢。 |
| **Hash Table** | 可根据主键快速定位到行，适合**单行点查**。 | 不适合范围查询。                          |

#### 2. SSTable

&emsp;&emsp; `SSTable` 是 LSMTree 架构中表数据在磁盘中的存储形式。当数据从内存落盘，写入到 `SSTable` 后，应用程序对数据的修改将不会改变已经落盘的数据版本。
`OceanBase` 的磁盘层摒弃了传统文件系统离散分配页面的方式，将 `SSTable` 划分为两级**物理结构**：

- **宏块（Macro Block）：**
  
  - **尺寸：** 固定为 2 MB。
  - **作用：** 磁盘空间分配与物理 I/O 的基本单位。`OceanBase` 采用类似“文件系统”的连续块分配模式，管理更高效，基本消除了磁盘碎片。
- **微块（Micro Block）：**
  
  - **尺寸：** 默认为 16 KB 左右（可变长）。
  - **作用：** 数据编码（Encoding）与通用物理压缩（Compression）的基本单位，也是内存 Block Cache 载入的基本粒度。
  - **优势：** 查询时仅需解压命中的 16 KB 微块，而不需要读取整块 2 MB 宏块，极大节省了 CPU 与内存。

### 2.3 分层转储与合并机制

&emsp;&emsp;磁盘层的数据由 **转储（Minor Compaction）** 和 **合并（Major Compaction）** 动态生成，分为三种主要形态：

1. **Mini SSTable（L0 层）：**
   
   - **来源：** 内存中的 Active MemTable 冻结为 Frozen MemTable 后写盘生成，该过程称为 **Mini Compaction（转储）**。
   - **特点：** 写入速度极快，数据未做深度重排与重压缩，保留了全量增量数据版本，L0 层允许存在多个 Mini SSTable。
2. **Minor SSTable（L1 层）：**
   
   - **来源：** L0 层的多个 Mini SSTable 归并为一个 Minor SSTable，该过程称为 **Minor Compaction**。
   - **特点：** 消除多份 Mini SSTable 之间的冗余中间版本，降低读路径上的 SSTable 层数，通常只有一个 Minor SSTable。
3. **Major SSTable（L2 层 - 基线数据）：**
   
   - **来源：** 由 Minor SSTable 与原 L2 层的 Major SSTable 进行全量归并生成。用来存放基线数据，由 **Major Compaction（合并）** 产生。
   - **特点：** 包含了表的完整静态数据，应用自研的**行列混存编码**（如字典、RLE 等）与高级物理压缩算法，是数据压缩比最高的层级。

回顾完 `OceanBase` 的存储架构，`LSM-Tree` 之所以在现代分布式数据库中取代传统的 B+ 树，主要是针对其天然的“读放大”和“写放大”短板在**工程层面** ** 进行了如下突破：

1. **内存端：** 抛弃传统 `SkipList`，采用 **“BTree + Hash Table”双索引**，兼顾极致的点查与范围扫描；
2. **缓存端：** 引入 **Fuse Row Cache（熔合行缓存）**，避免每次点查都现场重组基线与增量数据；
3. **磁盘端：** 采用 **“2 MB 宏块 + 16 KB 微块”** 的两级连续分配架构，配合低峰期的每日大合并（`Major Compaction`），有效理顺了 LSM-Tree 在高并发 OLTP 场景下的读写性能。

这里是《实战派K8S&DB》—— 用**大白话**拆解晦涩的技术原理，并分享真正能落地的**实战干货**。**如果本文对你有所帮助，欢迎点赞、推荐和转发，也欢迎关注后续文章，一起学习 `OceanBase` 分布式数据库。**



在前面的文章中我们提到，OceanBase 和 TiDB 这两款主流分布式数据库并没有沿用传统的 HEAP 或 B+ 树存储引擎，而是选择了 LSM-Tree 架构。事实上，LSM-Tree 近年来在业界颇受欢迎——无论是大数据领域的 HBase、Cassandra，还是 LevelDB、Lucene（ES 的底层引擎），或是分布式 NewSQL 领域的 OceanBase 、TDSQL 新敏态存储（现名 TDSQL Boundless）以及 TiDB 底层的存储 RocksDB，都采用了 LSM-Tree 作为核心存储引擎。这期文章，我们就以 OceanBase 为例，来深入聊聊 LSM-Tree 的设计原理与工程实践。

从 LSM-Tree 原理到 OceanBase 存储架构实践

`LSM-Tree` 近年来在业界颇受欢迎——无论是大数据领域的 HBase、Cassandra，还是 LevelDB、Lucene（ES 的底层引擎），或是分布式 `NewSQL` 领域的 OceanBase 、TDSQL 新敏态存储（现名 TDSQL Boundless）以及 TiDB 底层的存储 `RocksDB`，都采用了 `LSM-Tree` 作为核心存储引擎。

数据库

架构设计

后端

LSM-Tree以顺序写替代随机写，实现高吞吐写入，但存在读放大与写放大问题。OceanBase采用双索引MemTable与多级缓存架构，配合宏块/微块分层存储，在OLTP场景下平衡读写性能，提升查询效率。

分布式数据库

数据存储

数据缓存

数据结构

文件系统

大数据

Cassandra

HBase

OLTP

2026上云采购 | AI焕新·智启新局

tddbms

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从 LSM-Tree 原理到 OceanBase 存储架构实践-腾讯云开发者社区-腾讯云

从 LSM-Tree 原理到 OceanBase 存储架构实践

从 LSM-Tree 原理到 OceanBase 存储架构实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐