一、当数据库“写”得太累：认识写放大问题
想象一下，你有一个非常勤奋的仓库管理员。他的工作流程是这样的：每次收到一小箱新货物（新数据），他不是直接放到大仓库的某个空位，而是先把这一小箱货物搬进身边的一个小临时仓库（内存）。等小临时仓库快满了，他就把里面所有的箱子倒出来，和之前已经整理好的、同样大小的一批箱子（旧数据文件）全部拆开，重新按照货品编号从大到小排列，合并打包成一个崭新的大箱子，再存放到大仓库的指定位置。
这个过程听起来就很累，对吧？更累的是，随着仓库里的货物越来越多，这个“整理-合并-打包”的动作会越来越频繁，而且每次合并涉及的数据量也越来越大。这位管理员可能为了最终存放一箱新货，反复搬运、整理了成百上千箱旧货。这种“实际写入的物理数据量”远远超过“用户想要写入的数据量”的现象，在数据库世界里，就被称为“写放大”。它就像数据库引擎的一个隐形成本，消耗着额外的磁盘I/O和CPU资源，拖慢了整体的写入速度，也影响了硬件的寿命。
OceanBase使用的存储引擎，其核心结构叫做LSM-Tree，它天然就采用了类似上面描述的“先内存、再磁盘、定期合并”的工作模式。这种设计让它在大规模写入场景下拥有极高的吞吐量，但同时也让它更容易受到“写放大”问题的困扰。所以，对LSM树进行优化，核心目标之一就是减轻这位“仓库管理员”的工作负担，让他干活更聪明、更高效。
二、LSM树的日常工作：从写入到合并
要优化，我们得先彻底了解它是怎么工作的。LSM-Tree的工作流程可以简化成几个关键步骤，我们用 OceanBase 中的概念来具体说明。
技术栈：OceanBase
首先，数据写入时，会先进入一个叫做 MemTable 的内存表。你可以把它想象成那个“小临时仓库”，它结构简单，写入速度极快。当 MemTable 被填满后，它就会被“冻结”起来，变成只读状态，同时系统会立刻创建一个新的空 MemTable 来接收后续的写入。这个被冻结的 MemTable，会被转存到磁盘上，形成一个不可修改的文件，在 OceanBase 里称为 SSTable。
这些 SSTable 在磁盘上会分层存放。最新从 MemTable 转存下来的 SSTable 位于第0层。随着数据不断写入，第0层的 SSTable 会越来越多。这时，后台的“合并”线程就开始工作了。它会将第0层多个小的 SSTable，合并排序成一个大的 SSTable，然后放入第1层。同样的过程会发生在第1层和第2层之间，以此类推。层级越深，每个 SSTable 文件通常越大，包含的数据时间范围也越久。
这个合并过程，就是写放大的主要来源。为了让你有更直观的感受，我们来看一个高度简化的模拟示例。这个例子展示了数据从内存到磁盘，以及合并过程中数据被反复读写的情况。
-- 技术栈：OceanBase SQL (用于概念说明，实际合并由存储引擎自动完成)
-- 假设我们有一个用户表 `user_log`。
-- 1. 初始写入：数据快速写入内存中的 MemTable。
INSERT INTO user_log (user_id, action, log_time) VALUES (1001, 'login', '2023-10-27 10:00:00');
INSERT INTO user_log (user_id, action, log_time) VALUES (1002, 'click', '2023-10-27 10:00:01');
-- ... 持续写入，直到 MemTable 达到阈值（例如，容纳100条记录）。
-- 2. MemTable 冻结并刷盘，形成 L0 的 SSTable (SSTable_L0_A)。
-- 此时，SSTable_L0_A 包含了第1-100条记录。
-- 3. 继续写入新的 MemTable，写满后形成 SSTable_L0_B（包含第101-200条记录）。
-- 现在 L0 层有两个 SSTable 文件。
-- 4. 触发 L0 到 L1 的合并。
-- 后台线程需要：读取 SSTable_L0_A (100条) 和 SSTable_L0_B (100条) 的全部数据。
-- 在内存中对这200条记录按照主键（如 `(user_id, log_time)`）进行排序和去重（如果同一主键有更新）。
-- 将排序好的200条记录，写入一个新的、更大的 L1 层 SSTable (SSTable_L1_A)。
-- 最后，删除旧的 SSTable_L0_A 和 SSTable_L0_B。
-- 分析：用户实际写入了200条记录。
-- 但存储引擎的物理I/O包括：
-- * 写入 SSTable_L0_A: 100条
-- * 写入 SSTable_L0_B: 100条
-- * 读取 SSTable_L0_A 和 B: 200条
-- * 写入 SSTable_L1_A: 200条
-- 在这个小规模示例中，为了持久化200条用户数据，系统实际处理了600条数据的I/O。
-- 写放大系数 = 600 / 200 = 3。在真实海量数据场景下，这个问题会被急剧放大。
通过这个例子，我们可以看到，即使是最简单的合并，也会导致数据被多次读写。随着层级加深，一个数据条目可能会在L1, L2, L3...的多次合并中被反复处理，写放大效应会层层累积。
三、给LSM树“减负”：OceanBase的优化策略
知道了问题所在，OceanBase 的工程师们给这位“仓库管理员”配备了几样得力的工具和更智能的工作流程，来显著降低写放大。
策略一：分层合并与Major/Minor Compaction OceanBase 将合并动作细分为两种：Minor Compaction（小合并）和 Major Compaction（大合并）。
- Minor Compaction：主要发生在内存MemTable刷盘到L0，以及L0到L1的合并。它可能只合并部分数据文件，速度快，对系统影响小，目的是快速消化新的写入，避免内存积压。
- Major Compaction：这是全局性的深度合并。它会将多层（例如L0, L1, L2）的多个SSTable，合并成一个全新的、包含某个数据范围完整最新版本的大SSTable，并直接放到最高层。这个过程能彻底清理掉已删除或旧版本的数据，极大地减少后续合并需要处理的文件数量和冗余数据，是从根本上缓解写放大的关键操作。OceanBase 会智能地调度 Major Compaction，通常在系统负载较低时进行。
策略二：优化数据布局与编码 在将数据写入SSTable文件之前，OceanBase 会对数据进行压缩和编码。例如，使用字典编码、前缀压缩等技术，让同样内容的数据占用更少的磁盘空间。物理数据量变小了，在合并时需要搬运的“货物体积”自然就变小了，I/O压力随之减轻。这相当于给每个货物箱子做了真空压缩，一卡车能拉走的货，现在半卡车就够了。
策略三：智能触发与流控 不是一有数据就急着合并。OceanBase 的存储引擎会监控系统的实时状态。当写入流量突然激增时，它可能会适当推迟非紧急的合并任务，优先保障前台业务的写入性能，等流量高峰过去再慢慢清理。同时，合并任务本身也有流控机制，避免其占用过多的磁盘I/O和CPU资源，影响正常的读写服务。这就像管理员会在仓库业务最忙的时候（比如“双十一”），暂停大规模盘点整理，先全力保障收货发货。
让我们通过一个更具体的配置示例，看看如何利用 OceanBase 的参数来影响合并行为，从而优化写放大。
-- 技术栈：OceanBase SQL / 系统配置
-- 以下是一些与合并和写放大相关的重要配置项，可以通过系统表或命令查看和设置。
-- 1. 设置合并策略与时机
ALTER SYSTEM SET `_ob_compaction_schedule_interval` = '1h';
-- 注释：设置合并调度器检查是否需要发起合并的时间间隔。间隔拉长可以减少合并频率，
-- 但可能会让临时文件增多，需要平衡。
ALTER SYSTEM SET `enable_major_freeze` = true;
-- 注释：启用全局大合并（Major Freeze）。这是深度清理冗余数据的关键。
SET GLOBAL `ob_compaction_high_thread_score` = 100;
SET GLOBAL `ob_compaction_mid_thread_score` = 50;
-- 注释：设置高/中优先级合并任务的CPU资源权重。通过调整这些参数，
-- 可以控制合并任务对系统资源的消耗，避免合并拖慢在线业务。
-- 2. 调整MemTable和SSTable的相关参数
ALTER SYSTEM SET `writing_throttling_trigger_percentage` = 80;
-- 注释：设置写入速度限制的触发阈值。当MemTable使用率达到80%时，
-- 可能会触发流控，平滑写入峰值，给合并留出喘息之机。
ALTER TABLE user_log SET TABLEGROUP = 'large_tg' COMPRESS = 'lz4_1.0';
-- 注释：创建表或修改表时，可以指定压缩算法。`lz4`算法压缩解压速度快，
-- 能有效减少数据体积，直接降低合并时的I/O量。
-- 这里将 `user_log` 表放到一个指定了LZ4压缩的表空间里。
-- 3. 监控与诊断（示例查询）
-- 查看当前未完成的合并任务
SELECT * FROM `__all_virtual_compaction_diagnose` WHERE info LIKE '%pending%';
-- 查看各分区SSTable的层级和数量统计（近似）
SELECT svr_ip, table_id, count(*) as sstable_count, max(level) as max_level
FROM `__all_virtual_sstable`
GROUP BY svr_ip, table_id
ORDER BY sstable_count DESC LIMIT 10;
-- 注释：SSTable文件过多、层级过深是写放大可能较严重的直观迹象。
-- 这些信息有助于判断是否需要调整合并策略或进行手动干预。
四、实战思考：何时需要关注，利弊如何权衡？
应用场景： LSM树的优化和写放大问题的解决，在以下场景中至关重要：
- 高吞吐写入场景：如物联网数据采集、实时日志分析、电商交易流水等，这些场景下写入是持续且海量的，是写放大的重灾区。
- 使用SSD硬盘的环境：虽然SSD速度快，但寿命受擦写次数限制。过高的写放大会快速消耗SSD的寿命，优化写放大能有效延长硬件使用时间。
- 成本敏感型业务：在公有云上，磁盘I/O和容量都直接产生费用。降低写放大意味着更少的I/O操作和更高效的数据存储，直接节省成本。
- 追求稳定低延迟的在线业务：剧烈的后台合并可能引起I/O和CPU毛刺，导致前台查询和写入延迟不稳定。优化合并策略可以使系统性能更平滑。
技术优缺点：
- 优点：
- 提升写入吞吐：优化的核心目标，让系统吃得下更多的数据。
- 降低硬件损耗：减少不必要的磁盘写入，尤其保护SSD。
- 稳定系统性能：平滑的合并策略避免性能抖动，提升用户体验。
- 节约存储成本：通过压缩和减少冗余，提高磁盘空间利用率。
- 缺点/挑战：
- 复杂度增加：优化策略（如多级合并、智能流控）增加了系统的设计和维护复杂度。
- 可能增加读延迟：为了优化写，数据可能分布在更多文件中，有时读操作需要查询更多位置（但通过布隆过滤器等技术可以缓解）。
- 需要调优：没有放之四海而皆准的参数，需要根据业务负载进行监控和调优，有一定技术门槛。
注意事项：
- 监控先行：必须建立完善的监控体系，关注
磁盘写入量/业务写入量的比率、合并任务队列长度、各层SSTable数量等核心指标。 - 避免过度优化：不要为了追求极低的写放大而将合并间隔设得极长或完全关闭Major合并。这会导致读性能下降、空间回收不及时，甚至可能因为SSTable文件过多而在真正需要合并时引发更严重的I/O风暴。
- 理解业务模式：对于有明显潮汐效应的业务（如白天写多，晚上读多），可以配置在业务低峰期（如凌晨）自动触发强度更大的合并任务。
- 测试与验证：任何参数调整都应在测试环境充分验证，观察其对业务SQL延迟、吞吐以及系统资源的影响。
五、总结
写放大是LSM-Tree存储引擎在享受高写入性能盛宴时不得不支付的一道“隐形税”。OceanBase通过分层合并策略、智能的数据编码压缩、以及精细化的资源流控等手段，有效地为这道税打了折扣。这些优化不是魔法，其核心思想在于“权衡”——在写入速度、读取速度、空间利用和长期性能稳定性之间寻找最佳平衡点。
作为开发者或DBA，我们的任务不是消除写放大，而是理解其原理，并通过监控和配置，将其控制在合理且对业务无害的范围内。当你发现数据库磁盘I/O异常高、写入速度跟不上业务需求、或者SSD寿命预警时，不妨从LSM树的合并机制入手，检查一下是否是“写放大”在作祟。通过运用OceanBase提供的这些优化利器，你完全可以让你的数据库存储引擎工作得更轻松、更高效、也更长寿。
评论