OceanBase为何采用LSM-Tree存储架构？优势、缺点与写放大分析

---

OceanBase为何采用LSM-Tree存储架构？优势、缺点与写放大分析

OceanBase数据库自诞生以来，始终坚持以 LSM-Tree（Log-Structured Merge-tree） 为核心存储引擎架构，并在此基础上进行了大量创新与优化，形成了独特的“基线+增量”混合存储模型。该设计兼顾了高写入性能、极致压缩比、事务能力与读写平衡，使其能够在金融级 OLTP 场景下稳定运行。

本文将系统解析 OceanBase选择LSM-Tree的原因、优势与不足、写放大问题及缓解机制。

---

一、为什么OceanBase选择LSM-Tree架构？

OceanBase的首要目标是：在保证强一致性和事务完整性的前提下，最大化写入吞吐并降低存储成本。

• B+树数据库的局限
  在传统关系型数据库中，基于B+树的存储引擎在高并发写入场景下容易受制于 随机 I/O 和频繁刷脏页，导致写入瓶颈。

• LSM-Tree的突破
  LSM-Tree通过“先写内存，异步落盘，批量合并”的模式，将随机写转化为顺序写，从而显著提升了写入效率。

  具体流程：

  1. DML 操作写入 MemTable（内存表，可读写）
  2. MemTable 达到阈值后触发转储，生成 SSTable（磁盘只读文件）
  3. 查询时同时访问 MemTable 与多个 SSTable，进行结果归并

这种“增量数据（MemTable）+ 基线数据（SSTable）”模式，使OceanBase既继承了LSM-Tree的高效写入能力，又能保证关系型数据库的事务一致性与SQL能力。

官方说明

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002013392 存储架构概述

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002014007 转储和合并概述

---

二、OceanBase基于LSM-Tree的优势

1. 高吞吐写入能力

   • 随机写转化为顺序写，减少随机 I/O
   • 批量落盘提升写入效率
   • 大幅优于 B+ 树架构在高并发写入场景下的性能

2. 极致压缩，降低存储成本

   • 基线数据只读且连续存储，适合高效压缩
   • 采用 行列混合编码 + 通用压缩算法（如 zstd）
   • 压缩率可达 10 倍以上，存储成本降低 70%~90%

3. 支持大事务与长事务

   • 与 RocksDB 等NoSQL不同，OceanBase支持 活跃事务落盘
   • 确保大事务、长事务不会因内存溢出而失败

4. 多级缓存优化读性能

   • Block Cache：缓存数据块
   • Row Cache：缓存热点行，加速点查
   • Bloom Filter Cache：快速判断行是否存在，减少空查开销
   • 结合缓存与计算下压，使点查性能接近内存数据库

5. 原生支持 HTAP（TP+AP混合负载）

   • OceanBase 4.3 实现 行列存一体化
   • 行存：高并发点查、事务处理
   • 列存：复杂分析型查询
   • 在一套存储引擎中同时满足 TP 与 AP 场景

---

三、LSM-Tree的缺点与挑战

尽管LSM-Tree具备明显优势，但其典型问题也十分突出：

1. 写放大（Write Amplification）

定义：实际写入磁盘的数据量远大于用户逻辑写入量。

成因：

• 每次Compaction都需读取旧SSTable并重写新文件
• 多层结构导致数据被多次重写
• 合并过程中涉及排序和归并

OceanBase缓解策略：

• 宏块粒度重用：以2MB为基本单位，未修改的宏块直接复用，避免重复写入

• 分层+层级Compaction混合模式：

  • L0 层：Tiered 模式，减少小文件频繁合并
  • L1/L2 层：Leveled 模式，控制跨层代价

• 每日基线合并（Major Compaction）：定期全量合并，消除碎片

2. 读放大（Read Amplification）

问题：查询需要同时访问 MemTable 和多个 SSTable，增加CPU和I/O负担。

OceanBase优化：

• Bloom Filter：快速定位Key所在文件
• 多级缓存：热点数据尽量命中内存
• 计算下压 + 向量化执行：减少跨层合并和CPU消耗

---

四、Compaction机制详解

Compaction 是 LSM-Tree 的核心维护机制，OceanBase针对写放大和读放大问题，设计了精细化的多级合并策略：

类型	触发条件	功能
Minor Compaction（转储）	MemTable 达到阈值	冻结并刷盘为 L0 SSTable，轻量顺序写
Tiered Compaction	L0 文件数过多	合并多个小文件，减少查询文件数
Leveled Compaction	L1/L2 数据超出容量	类似 LevelDB，分层压缩，控制层数
Daily Minor Compaction	每日定时	集中转储增量，清理过期版本
Major Compaction（基线合并）	周期性执行	全量合并，去重冗余，重建索引与Bloom Filter

调度与资源控制：

• I/O 低优先级，避免影响前台事务
• CPU 使用限额，防止合并过度抢占资源
• 动态调整并发度，负载高时降低Compaction任务

---

五、总结

OceanBase选择LSM-Tree架构并非简单模仿NoSQL，而是在其基础上 深度演进：

• 增量+基线模型：写入高效，事务持久化友好
• 宏块复用 + 混合Compaction：缓解写放大
• 缓存体系 + Bloom Filter：降低读放大
• 行列存一体化：原生支持 HTAP

凭借这些创新，OceanBase不仅解决了传统LSM-Tree的缺陷，还实现了 高性能、低成本、强一致性 的统一存储引擎，能够支撑如“双十一”这样的极端高并发业务场景。

---

要不要我帮你把 OceanBase 的写放大数值对比（例如 B+ 树 vs LSM-Tree vs OceanBase 优化后） 也整理成一张表格？这样更直观地展示优化效果。