How to Write to SSDs

该论文提出了一套跨数据库与 SSD 层的“非原地写入”优化方案,通过重新设计 LeanStore 存储引擎,显著降低了写放大并提升了 OLTP 工作负载下的吞吐量与 SSD 寿命,同时兼容 ZNS 等新型 SSD 接口。

Bohyun Lee, Tobias Ziegler, Viktor Leis

发布于 Wed, 11 Ma
📖 1 分钟阅读☕ 轻松阅读

Each language version is independently generated for its own context, not a direct translation.

这篇论文讲述了一个关于如何让数据库(DBMS)和固态硬盘(SSD)“握手言和”,从而跑得更快、寿命更长的故事

想象一下,你的数据库是一个繁忙的图书馆,而 SSD 就是图书馆的书架

1. 核心问题:为什么现在的图书馆效率低且容易坏?

在传统的图书馆管理方式(原地写入/In-place)中,规则是这样的:

  • 死板的规则:如果你要修改一本书(数据页),管理员必须把旧书从架子上拿下来,撕掉,然后把新书严丝合缝地塞回原来的那个位置
  • 双重搬运(Doublewrite):为了防止停电导致书没写完(数据损坏),管理员会先复印一份放在“临时复印区”(Doublewrite Buffer),确认无误后,再正式替换书架上的旧书。这相当于每改一次书,就要搬运两次
  • SSD 的“强迫症”:SSD 这种“书架”有个怪脾气。它不能只擦除“一页纸”,它必须把整“一大块”(Block)都擦掉才能重写。如果这块里还有几页没坏的书,管理员就得先把那些好书搬出来,擦掉整块,再把好书搬回去,最后才放新书。

后果是什么?

  • 写放大(Write Amplification):你只想改 1 本书,结果因为要复印、要搬来搬去、要擦整块书架,实际上 SSD 内部可能写了 5 本书的内容。
  • 寿命缩短:SSD 的擦写次数是有限的。这种“过度搬运”就像让一个搬运工干 5 个人的活,书架很快就磨损报废了。
  • 速度慢:大家都在忙着搬运和擦除,没空真正处理读者的请求。

2. 解决方案:ZLeanStore(新式图书馆管理法)

这篇论文提出了一套全新的管理策略,核心思想是:别死守原来的位置,哪里有空位就放哪里(Out-of-place)。

这就好比图书馆不再要求“书必须放回原架”,而是允许管理员把新书直接放在任何有空位的架子上,然后更新一张“索引卡”告诉读者:“那本书现在在 3 号架的 5 层”。

基于这个核心改变,作者提出了几个“魔法技巧”:

技巧一:打包压缩(Compression & Page Packing)

  • 比喻:以前每本书都占一个固定的大格子(4KB),哪怕书里只有几行字,格子也是满的。现在,管理员把书的内容压缩(像把衣服塞进真空袋),然后智能打包
  • 效果:把几本压缩后的书塞进一个格子里,既省空间,又减少了搬运次数。而且,他们设计了一种“打包法”,确保读者拿书时,一次就能拿到完整的一包,不用拆开再拼凑。

技巧二:按“死亡时间”分组(Grouping by Deathtime)

  • 比喻:有些书是“畅销书”(经常改),有些是“古籍”(几乎不改)。
    • 旧做法:不管什么书,都混在一起放。结果清理书架时,为了拿一本旧书,不得不把旁边还没过期的畅销书也搬来搬去,效率极低。
    • 新做法:管理员预测每本书大概什么时候会“过期”(被修改),把寿命相似的书放在同一个区域
  • 效果:当需要清理时,整个区域的书可能都“过期”了,直接一次性清空,不需要把好书搬来搬去。这大大减少了无谓的搬运。

技巧三:与书架管理员(SSD)配合

  • 背景:SSD 内部也有自己的清理机制(垃圾回收 GC)。如果数据库乱塞,SSD 就会疯狂搬运。
  • 新做法
    • 对于普通 SSD:数据库会计算好,确保自己塞书的方式,正好符合 SSD 内部清理的“节奏”。就像两个人跳舞,步调一致,就不会踩脚。
    • 对于高级 SSD(ZNS/FDP):这些新型书架允许图书馆直接指挥:“请把书放在第 3 区”。数据库利用这个功能,彻底消除了 SSD 内部的额外搬运。

3. 结果:发生了什么奇迹?

通过这套“新式管理法”(ZLeanStore),论文在实验中取得了惊人的效果:

  • 速度翻倍:图书馆处理读者的速度(吞吐量)提高了 1.65 到 2.24 倍
  • 寿命延长:SSD 实际受到的磨损(写入量)减少了 6 到 9 倍。这意味着原本只能用 1.5 个月的硬盘,现在可能用 1 年甚至更久。
  • 兼容性:这套方法不仅适用于普通硬盘,还能完美适配最新的 ZNS 和 FDP 技术。

总结

这篇论文告诉我们:不要试图让 SSD 去适应数据库,也不要让数据库盲目地适应 SSD。

最好的办法是打破“原地修改”的旧规矩,让数据库掌握主动权,利用“哪里有空位放哪里”的灵活性,配合压缩和智能分组,把数据写得更少、更整齐。这样,SSD 就不用做那些累死累活的“搬运工”工作了,整个系统自然跑得更快、更久。

一句话概括:把“死板地原地修补”变成“灵活地哪里有空放哪里”,让数据库和 SSD 配合得天衣无缝,既快又省。