聊聊和猜想下 Nutanix 对 RocksDB 的一些研究

96
siddontang 11f8cfa8 ec9f 4f82 be92 d6a39f61b5c1
1.0 2018.12.16 20:14 字数 1621

Nutanix 是一家做超融合的云计算厂商,实话,我之前对这家公司是一无所知,但在 2018 年 RocksDB meetup 上面,他们做了一个如何在 RocksDB 支持 coroutine read 以及 async write 的 talk 之后,我突然对这家厂商有了兴趣。佩服他们对 RocksDB 有非常深的研究,顺带在 Scholar 上面查了查,然后又发现了 TRIAD: Creating synergies between memory, disk and log in log structured key-value stores 这篇 Paper,觉得有必要整理下他们公司对 RocksDB 的研究了。

需要注意,下面的东西只是根据 Nutanix 公开的 talk 和 paper 做的一些调研以及猜想,具体他们怎么做的,我其实是不清楚的。

Filter + Async I/O

对于 RocksDB 来说,它的读写 I/O 都是同步的,大家都知道,一般同步的东西,代码写起来是挺简单,但性能其实并不是特别的高效。所以 RocksDB 的 team 一直想引入 Async I/O,也有了一些讨论,也有了一些 PR,但无奈改动太大了。

Nutanix 采用了另一种方案来支持 Async I/O,也就是使用 coroutine,而且对 RocksDB core 几乎代码没有改动。

原理也比较简单,因为 RocksDB 提供了比较好的抽象,对于文件的操作,都是使用一个 Env 对外提供的,所以只需要实习一个自己的 Env,就能控制 RocksDB 的文件读写了。

Nutanix 实现了一个自己的应用线程池,类似于 Folly 的 Fibers 库,然后实现了一个 Async I/O 的 thread pool,用来提交和处理 RocksDB 的 I/O 请求,然后这个 AIO pool 再去跟底层真正的 AIO 交互。

因为他们没有透漏更多,我猜想 Nutanix 的流程应该是:

  1. 操作跑在一个单线程上面,基于 Fibers
  2. RocksDB 需要读取某个文件的数据
  3. RocksDB 将请求发给 AIO thread pool
  4. 挂起当前的 coroutine
  5. AIO pool 发给底层的 AIO
  6. 等 I/O 处理结束在重新 resume 挂起的 coroutine 继续处理

其实这个跟通常的 coroutine 方式差不多,Nutanix 在 talk 里面说到对于单个线程,吞吐能提升 8 倍,还是很猛的一个数字了。

Async Write

上面提到的主要是 Nutanix 对于 Async I/O 的优化,在写入上面,他们也做了优化。

对于 LSM 这种数据结构来说,一次 Write,我们会先将数据 append 到 WAL 上面,然后在写入 memtable。RocksDB 支持多线程写,虽然它提供了 lock-free 的 memtable,但在 append WAL 仍然是不可能做到多线程并发的。所以 RocksDB 做了一些优化。一个是会选出一个 leader 线程,收集其他所有线程的写入,做个 batch,批量写入 WAL。另外就是引入了 pipeline 机制,一个线程先写 WAL,然后写 memtable,这时候另外的线程可以写 WAL 了。

虽然有这些优化,但对于 write 来说,仍然可以认为是同步的,Nutanix 这里引入了 async write,其实原理很简单,就是在 write 的时候带上一个 callback,内部启动了一个新的 leader 线程用来收集数据,batch 写入,然后等写入成功之后调用 callback。这里,Nutanix 额外提到使用了 direct I/O 来操作 WAL,这个还是比较有意思的,因为我以前一直以为对于 append 这种 I/O 操作,direct I/O 其实没啥太大的作用,所以也不知道他们是如何实现的。

基于这个优化,Nutanix 说写入提升了 3 到 4 倍,latency 减少了 2 倍,这个已经很猛了。

TRIAD

最后再来聊聊 TRIAD 这篇论文,这里来个小插曲,Facebook 的技术大佬 Mark 也提到了这篇 Paper,他说到之前竟然没看到这篇文章(毕竟是 2017 年发布的),我猜想他其实之前也没怎么关注 Nutanix,然后也是因为 RocksDB meetup 知道了,然后在 Google 出来的。。。

TRIAD 的原理还是非常简单的,对于一些热点频繁更新的数据,在 Memtable flush 到 Level 0 的时候,并不会 flush 到 Level 0,而是重新写回到 memtable,当然为了保证数据安全,会额外将这些数据写入到一个 log 里面。

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

对于 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 的个数。

对于 LSM 来说,一个被刷到 Level 0 的 memtable,通常数据其实也存在 WAL 里面,所以 TRIAD 做了一些改进,在 flush 到 Level 0 的时候,只是将一个 index(CL-SSTable) 刷到了 Level 0,这样通过 index 就能在 WAL 找到对应的数据了。然后在 Level 0 compacted 到 Level 1 的时候,WAL 才会被删除。

关于 TRIAD,大家可以直接去看源码

总结

上面只是一些我自己的理解,直观的感受就是 Nutanix 这家公司在 RocksDB 上面也做了很多东西,但网上能 Google 出来的东西挺少的。对于我们来说,这些优化如果 RocksDB 能引入那当然最好,如果不能,短期对我们意义不大,毕竟我们现在没太多的人力去开发相关的东西,如果你对这块感兴趣,欢迎联系我 tl@pingcap.com

编程之路
编程之路
22.3万字 · 50.9万阅读 · 328人关注