SSD如何应对高写入量数据库的持久化需求？含典型场景分析

一、场景回顾 #

以Cassandra或BigTable这类分布式数据库为例：100台服务器承载100万QPS，单台服务器处理1万次唯一写入请求；SSD页大小为4KB，单台服务器拥有100GB存储空间。
若不执行Compaction，每秒1万次4KB的写入，在完成25000000次写入（100GB ÷ 4KB）后磁盘就会被填满，计算可得仅需41分钟就会耗尽存储空间：

25000000 / 10000 / 3600 * 60 = 41min

但执行Compaction又会导致吞吐量下降、延迟升高，这就带来了SSD高写入场景下的核心矛盾。

二、SSD高写入的处理分工：固件与数据库引擎的职责 #

• SSD固件层面：负责底层的垃圾回收（GC），属于硬件级别的空间回收。它会自动回收被标记为无效的页（比如被覆盖、删除的旧数据页），将有效数据迁移到空白页后释放原页空间。但固件无法感知业务数据的语义（比如重复键、过期数据），只能被动处理无效页，无法从根源降低业务层面的写入放大。
• 数据库引擎层面：负责业务语义上的Compaction。数据库能感知数据的生命周期、重复键等信息，通过合并数据文件、清理过期/重复数据，减少写入到SSD的无效数据量。即使需要持久化数据，数据库也会先通过内存缓存（如MemTable）批量攒够数据，再写入磁盘形成有序文件（如SSTable），避免频繁小写入触发SSD的GC，同时降低Compaction的触发频率。

三、数据结构对写入放大的影响：LSM树优于B树的原因 #

你的猜测完全正确，LSM树在SSD上的表现远优于B树，核心差异在于写入模型：

• B树采用原地更新模型，每次写入/更新需要定位到对应的磁盘页，修改后写回。但SSD不支持原地覆盖，必须写入新页并标记原页为无效，这会产生大量无效页，触发频繁GC，写入放大极高。
• LSM树采用追加写入模型，所有写入先存入内存的MemTable，满了之后批量写入磁盘形成SSTable；后续通过后台Compaction合并多个SSTable，清理重复、过期数据。这种批量写入+后台合并的方式，大幅减少小写入次数，同时降低SSD的写入放大，完美适配SSD的硬件特性。

四、深入学习的资料推荐 #

• 《大数据存储系统：原理、架构与实践》：详细讲解LSM树、Compaction机制以及SSD适配优化逻辑
• 《SSD原理与性能优化》：从硬件层面解析SSD的GC、磨损均衡等机制，以及与上层软件的协同优化方案
• Cassandra、BigTable官方技术文档：直接查看这些分布式数据库针对SSD的存储优化实现细节
• 《Designing Data-Intensive Applications》：其中章节对比了不同存储引擎的数据结构，分析了它们在不同存储介质上的表现差异

内容的提问来源于stack exchange，提问作者user21872982