Facebook 中使用 NVM 来减少 DRAM 的占用

最近看到一篇论文 Reducing DRAM Footprint with NVM in Facebook，写的非常不错，讲的是 Facebook 的工程师是如何在 MyNVM 项目里面使用 NVM 来减少 DRAM 的使用的。

当然，对我的启发是非常大的，一方面的原因是从里面学到了如何对硬件进行更好的测试，另一方面，则是让后面自己做 engine 有了参考，知道在那些点上面需要关注。

NVM

NVM 在 Wiki 中的定义是 Non-volatile memory，可以认为是一种非常快速的，持久化的储存介质。相比于传统的 SSD，无论在带宽，还是延迟上面，都要优秀很多。当然，价格也是不便宜的，譬如我们买了 10 块 Optane 盘，每块盘都一万多了，不过比 DRAM 现在还是便宜太多了。下图是 Facebook 给出的一个性能对比

可以看到，相比于传统的 TLC Flash，NVM 在带宽上面优势比较明显，而且 read latency 也非常的低，虽然相比于 DRAM 差距还比较大，但 NVM 能存放更多的数据，同时考虑到成本，DRAM 能在一些场景（譬如二级 cache，DRAM 较小）下面有效的替换掉 DRAM。

减少 DRAM 使用的挑战

在 RocksDB 里面，很早就提供了 Persistent Read Cache 的功能，方便用户将数据 cache 持久化到特定的路径，所以我们可以非常方便的使用这个功能。但如果想用这个功能来减少 DRAM 的使用，还是有很多挑战的，主要包括：

NVM 的带宽比 DRAM 小很多，并且极大的依赖不同的 block size，所以如果只是单纯的替换 DRAM，我们很可能在读带宽上面就先遇到瓶颈，从而达不到想要的性能。
减少 DRAM 的使用也需要重新设计新的索引机制，因为只有一小部分数据现在会 cache 在 DRAM 里面了。
使用比较小的 block size 会减少压缩的比率，相应的就会增加整个数据库的大小。
不同于 DRAM，NVM 有耐用性约束，如果我们仅仅是像 DRAM 那样使用 NVM，很有可能就会造成 NVM 过早的报废。
因为 NVM 相比于其他的 disk 有更低的延迟了，所以系统调用的开销就会变得非常的明显。

知己知彼，百战百胜

虽然挑战很大，但还是有可行的空间的。不过首先，最重要的一件事情，就是当我们拿到手一块 NVM 盘，这个盘性能到底是怎样的，在哪一些场景下面性能最优，我们是需要知道的。只有知道了这个，后面对我们构建系统才会有明确的指导。对于盘的测试，自然，大家通常都会选择 Fio。

Facebook team 使用 Fio 做了非常充分的测试，主要集中在延迟和带宽上面，他们使用了非常多的维度来测量，主要有：

在 100% 和 70% read + 30% write 场景下面 mean 和 P99 的延迟还有带宽
使用不同 block size 下面的 read mean 和 P99 延迟
使用不同的 write block size 下面，从 100% 到 50% read，整体带宽

通常这些详细的测试，我们就能知道这个盘大概是什么样的情况，譬如，Facebook 就发现一次读取大的 block 并不划算，延迟会随着 size 的增大而增加。使用大的 write block size 在混合读写下能有效的防止整体带宽的衰减。

具体的测试指标，大家可以详细看论文。我个人觉得这个测试是很值得借鉴的，于是按照他们的测试用例，写了一个测试工具 fio-helper，这个会跑很多的测试，然后使用 Python 脚本解析好 Fio 输出的结果，生成 CSV 文件。然后就可以通过 pyplot 或者贴到 Excel 生成图表了。

实现

了解了盘的情况，有了性能测试工具，下面就是详细的设计了，其实对于 MyNVM 来说，整体的架构特简单：

也就是将 NVM 作为二级 block cache。虽然看起来比较简单，但实际还是要处理很多问题的。同时，为了更好的验证相关的实现能否 work，MyNVM 使用的是 Facebook 的 LinkBench 这个性能测试工具。至于这个工具的使用这里就不说了，重点来看看他们是如何克服之前提到的 NVM 的挑战的。

满足读带宽

从前面 Fio 的测试知道，NVM 的读带宽是 2.2 GB/s，但在正常情况下面，MyNVM 需要的带宽量会远远大于这个值。主要是因为 MyNVM 默认使用的是 16 KB 的 block size，读取一点数据，也需要读取 16 KB。

为了解决这个问题，一个直观的做法就是减少 block size，但 MyNVM team 发现，单纯的减少竟然增大了带宽的使用。

主要的原因就在于当 block size 减少之后，整个 index 的大小就会增加，导致降低了 DRAM 的 cache 命中率，从而让更多的数据从 NVM 上面读取。为了解决这个，MyNVM 将 index 进行切分，并用一个 top index 来索引这些 index。这个应该就是RocksDB 里面的 Partitioned Index Filter。

当从 disk 上面读取一个 index block 的时候，只有 top level 的 index 会被载入到 DRAM，同时也只有相关的 index 分片会缓存到 DRAM。使用这种方式，即使 4 KB 的 block，整体的 cache 命中率在 LinkBench 测试下面也跟 16 KB 的差不了太多。

使用 4 KB 还有一个问题，就是 RocksDB 会开启压缩，所以通常一个 4 KB 的 block 实际比 4 KB 小，一个 page 用不满，page 剩下的空间就会存另一个 block 的数据，这样就会导致一些 block 跨了多个 page，一次读取会读取 8 KB 数据了。

为了解决这个问题，MyNVM 使用 6 KB 的 block，通常的压缩都会稍微小于 4 KB，当然也有一些超过 4 KB 的。如果一个 page 还有剩余，并且存不下下一个 block，MyNVM 会尝试用 0 来填充。这样就能保证所有 block 都大概率的按照 NVM 的 4 KB 来对齐。使用这个方式，能减少整个读带宽，并且减少读延迟，因为读取的 page 会更少，但相应的会稍微增大一点写带宽，毕竟会补 0 多写一点数据。

数据库大小

因为使用了 6 KB 的 block size，压缩就不会特别高效了，相应的整体的数据库大小就会膨胀。为了解决这个问题，MyNVM 会预先将从多个 block 采样好的压缩 dictionary 给载入进来，这样对于模式比较固定的数据，就能增加压缩率。这个应该是使用的 zstd 来完成的。

中断延迟

对于 NVM 这种盘来说，硬件的延迟已经非常低了，所以很有可能软件就会成为瓶颈，这个我在之前的文章中分析 NOVA 也有过相关说明。对于 block I/O 来说，会触发中断，产生 context switch，这些都是有开销的。

为了减少中断造成的开销，MyNVM 使用 polling 的方式，当发起一次 I/O 之后，操作系统会一直循环的检查 I/O 是否完成，这样就没有了 context switch。这个主要是通过操作系统提供的 pvsync2 engine 来完成的。但一直 polling 会造成 CPU 占用比较高，系统负载偏大，为了解决这个问题，MyNVM 使用了一种混合模式 - 系统会收集之前 I/O 操作的平均延迟，并以此来决定是否 polling。譬如，假设之前的平均延迟是 M ns，那么当 polling 超过 M / 2 ns 之后，就触发中断。

混合 polling 和中断的方式需要给操作系统上个补丁，另外 polling 的方式也有缺陷，所以 MyNVM 并没有在现阶段使用。

小结

上面只是简单了介绍了下 Facebook 在构建 MyNVM 时候遇到的问题，以及相关的技术选型。对我们来说，也是很有参考意义的，毕竟现阶段我们已经在开始进行存储引擎的研发工作，理念就是 design for the future disk 以及 design for the cloud。如果你对这块感兴趣，欢迎联系我 tl@pingcap.com。