TRIAD: Creating Synergies Between Memory, Disk and Log in Log Structured Key-Value

Stores

TRIAD（USENIX ATC'17），⼀个新的 LSM key-value 存储引擎，开发这个引擎的公司叫 Nutanix，⽤ RocksDB 做

核⼼企业系统 metadata 的管理。TRIAD 的设计以该公司的需求为基础，出⾝于⼯业界的产品会有较强的可参考
性。

1.Motivation

先介绍⼀下概念。

commit log：提交⽇志是驻留在磁盘上的⽂件。它的⽬的是临时记录对Memtable进⾏的更新，如果应⽤程序要
求在发⽣故障时不丢失数据的话。在Memtable上执⾏的所有更新都附加到提交⽇志中。通常，提交⽇志的⼤⼩保
持较⼩，以便在需要重放操作以从故障中恢复时提供快速恢复。

⽂章指出了rocksdb触发频繁⽽密集的I/O操作的原因，主要的三个⽅⾯：

1. Data skew unawareness：针对冷热数据写差别较⼤的场景（skewed workload），热数据的频繁更新会导

致 memtable 很⼩⽽ commit log 却很⼤，为了避免⽇志过多⽽导致数据库重启恢复时间（recovery time）
增加， memtable 必须频繁地 flush 从⽽让 commit log 可以清掉，⽽这对性能是⼀种损失。

2. Premature and iterative compaction：现有的LSM KV系统在compaction过程中存在双重限制。⼀些LSM

KV存储在L0中只保留⼀个⽂件，以避免在读取时在L0中查找多个sstable。因此，每次刷新内存组件时，都
会触发从L 0到底层的压缩，导致LSM树的频繁compaction。其他LSM⽅案将多个⽂件保存在l0中。这种⽅
法导致了现有LSM KV存储的第⼆个限制。问题在于，当L 0中存在多个sstable时，如果L 0中的两个⽂件共
享⼀个公共key，那么这个key将在下层的LSM tree中被压缩两次。数据倾斜加剧了这个问题，因为它增加了
多个L 0⽂件包含同⼀组hot key的可能性。显然，系统上的负载越⾼，该事件发⽣的概率就越⾼。

3. Duplicate writes：当Memtable刷新到L 0时，相应的提交⽇志将被丢弃，因为刷新已经确保了数据的持久

性。但是，L 0新⽂件中的每个KV对都对应于写⼊内存组件中的key的上⼀个版本，因此被附加到提交⽇志
中。因此，在L 0中将内存组件刷新到磁盘时，系统实际上是在重放在填充提交⽇志时已经执⾏的I/O。

2.TRIAD

⽂章提出了三种优化⽅案

1. TRIAD-MEM：解决了内存组件级别的数据倾斜不感知问题。
当MemTable刷新到L 0时，TRIAD-MEM将经常更新的热数据与很少更新的冷数据分开。热项保存在新的memtable
中，只有冷项写⼊磁盘。这样，热项只在内存中更新，⽽不会在磁盘上触发⼤量压缩。这避免了为确保LSM磁盘结
构中的key范围不重叠⽽触发的⼤量压缩操作。

在 Memtable ⾥⾯，每个 key 会有额外的 4 字节空间来统计 key 的频率，然后在 flush 的时候统计出最 hot 的 k 个
key。现在的算法⽐较简单，只要⼤于平均频率的 key 就是 hot key，这个算法其实在多数场景下⾯都是有效的。

此外，当然为了保证数据安全，会额外将flush后的热数据写⼊到⼀个 log ⾥⾯。实际上，在⾮常倾斜的⼯作负载的

情况下，flush可能引发不是因为Memtable full的，但是因为commit log full。为了避免拥有⼤量⼩⽂件，⽂章指出
将所有entry保存在内存中，丢弃旧的commit log，并创建⼀个新的commit log，并使⽤Memtable的最新值。

2. TRIAD-DISK：通过在磁盘组件级别明智地选择延迟compaction和批处理来解决过早和迭代compaction的问
题。

对于 Level 0 和 Level 1 compaction，TRIAD 采⽤了 Hyperloglog 来计算两层之间的重叠情况，如果如果有⾜够的

重叠了，就触发 compaction，否则则是延迟触发。计算重叠的公式为 UniqueKeys(file-1, file-2, ...
file-n) / sum( Keys( file-i ) ) ，其中 Keys( file-i ) 表明是第 I 个 SST 的总的 key 的个数，⽽
UniqueKeys 则是估算的所有 SST 的唯⼀ key 的个数。

RocksDB采⽤HLL算法检测哪些⽂件的键重叠最多，需要压缩，来在压缩期间将丢弃最⼤数量的重复键的⽬的。其
中L i和L i+1处⽂件中键重叠的估计是基于⽂件的键的范围和⼤⼩。

3. TRIAD-LOG：处理重复写问题，在提交⽇志级别绕过刷新期间创建的新⽂件。

核⼼思想是把 commit log 当做 SST 来⽤。因为 commit log 有⼀份持久化数据，L0 SST 再写⼀份的话是⼀种浪
费。把⽇志⽂件直接 rename 成 SST 岂不美哉？

将commit log视为L 0可稳定⽇志的优点是，可以避免由于从内存刷新引起的I/O。但是，与sstable不同的是，

commit log没有排序。经典SSTables的排序结构使得在压缩期间合并SSTables和从⽂件中检索信息变得很容易。为
了避免扫描整个MemTable-SSTable以在L 0⽂件中找到⼀个条⽬，⽂章指出将每个KV对的最近更新的提交⽇志⽂件
的偏移量保存在MemTable中。⼀旦触发了刷新操作，只有与提交⽇志中的偏移量相关联的⼩索引被写⼊磁盘。然
后将索引与其对应的提交⽇志⽂件分组，从⽽创建新的L 0 MemTable-SSTable格式。
基本上这个思想和 wisckey 很接近，主要思想是在在内存中维护 key -> latest log offset 的映射，这样对 point
read 没有影响，但对 range read 影响很⼤。