CKB 为什么选择了 RocksDB 呢?

很好奇为什么 CKB 选择了 RocksDB。

我本人不是会上手的那种开发人员,也没有接触过数据库相关的东西。
但是我随便查了一下感觉,LevelDB 和 RockDB,在我看来没有什么特别大的区别,效率方面好像读快一些,写慢一些。整体感觉差别不大?
比如:https://www.influxdata.com/blog/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/

同时根据 RocksDB 的 wiki,它是被 Facebook 从 LevelDB fork 过来的。做出的改进主要是在多核利用率的提升,和针对快速存储(SSD)的优化。我们在这些方面又特别强的需求吗?

1 Like

CKB 开发团队对使用什么数据库保有最终解释权…

目前阶段使用 RocksDB ,但不排除更换的可能。现在是比较粗糙的数据都放到 RocksDB, 以后会根据具体情况去优化这里。

不禁为 CKB 开发团队严谨的态度鼓掌👏

我稍微站 levelDB。
因为以太坊和比特币都是 levelDB。
做 CKB 的 SDK 的话可能有可以借鉴的部分。

这个我当初看过一点,可以做个无责任推测:

  • 比特币开始做的时候,LevelDB 已经是个成熟的产品(毕竟在开源之前 LevelDB 就应该在 Jeff Dean 的手里已经跑了几年),而 RocksDB 还在开发初期,不一定那么成熟
  • 以太坊仅限于 geth 是 LevelDB,parity 记得还是 RocksDB。这里其实有个很无聊的原因:geth 是 Go 写的,而 Go 受限于 cgo 性能的原因,在这种底层库上通常都只能用 Go 写的来避免 latency。而 Go 写的话,只有这个仿 LevelDB 的库: https://github.com/syndtr/goleveldb

所以如果我的推测是正确的话,已有的 LevelDB 更多的是处于无奈和 legacy 的选择。

2 Likes

我觉得你说的有道理。

那本质上 RocksDB 比 LevelDB 好在哪呢?
从 benchmark 上看感觉没有明显优势?

RocksDB 本身有个很明显的优势,就是传统的 LevelDB 只是单线程处理,这样有大 value 的 key 的时候,性能会有明显衰减。但是 RocksDB 添加了多线程支持,在很多场景下性能会有明显提升。

但是要注意的另一个问题是 LevelDB/RocksDB 这一系下层都是用的 Log Structured Merge Trees 这个数据结构,这个数据结构其实最开始是为解决传统的机械硬盘随机写速度很慢的场景实现的。在 SSD 时代,首先随机写不是问题,其次 LSMT 在某些场景下会撞到 SSD 的一些特性,反而造成写放大导致性能损失。这个损失在 LevelDB 场景下通常还好,在某些 RocksDB 的使用模式下速度会体现出来慢很多。

当然不是说写放大的问题没有解决方案,只是说要具体做 benchmark 才能确定每个场景适合的选型。

5 Likes

我记得 RocksDB 在立项宣传的时候的目标之一,就是实现一个针对 SSD 优化版的 LevelDB。

2 Likes

这个我有点记不清了。只是记得哪怕后来,写放大对 RocksDB 也是很重要的一个问题。

楼上都是大佬,学习了

1 Like