Table of Contents Leveldb 2011年7月开源, 到现在有3年了, 原理上已经有很多文章介绍了, 我们就不多说. 其中最好的是淘宝那岩写的 leveldb 实现解析 和 TokuMX作者写的那个300页ppt: A Comparison of Fractal Trees toLog-Structured Merge (LSM) Trees (这个PPT 对读放大写放大分析很好, 值得再读一次) 最近基于LevelDB, RocksDB 做了一点东西, 我们的目标场景是存储平均50K大小的value, 遇到一些问题, 总结一下: 1 问题1.1 compaction不可控.当L0文件达到12个, 而compaction来不及的时候, 写入完全阻塞, 这个阻塞时间可能长达10s. LevelDB实现上是L0达到4个时开始触发compaction, 8个时开始减慢写入, 12个时完全停止写入. 具体配置是写死的, 不过可以在编译时修改: // Level-0 compaction is started when we hit this many files. static const int kL0_CompactionTrigger = 4; // Soft limit on number of level-0 files. We slow down writes at this point. static const int kL0_SlowdownWritesTrigger = 8; // Maximum number of level-0 files. We stop writes at this point. static const int kL0_StopWritesTrigger = 12; RocksDB这几个数字都可以通过参数设置, 相对来说好一些: options.level0_slowdown_writes_trigger options.level0_stop_writes_trigger 但是
1.2 写放大基准数据100G的情况下, 50K的value, 用200qps写入, 磁盘带宽达到100MB/s 以上. 真实写入数据大约只有50K*200=10MB/s, 但是磁盘上看到的写大约是10-20倍, 这些写都是compaction在写, 此时的性能瓶颈已经不是CPU或者是LevelDB代码层,而是磁盘带宽了, 所以这个性能很难提上去, 而且HDD和SSD在顺序写上性能差别不大, 所以换SSD后性能依然很差. 其它同学发现的issue:
1.3 其它问题这几个问题只针对LevelDB, RocksDB已经解决了:
2 小结
|
|