RocksDB的缺点
LevelDB是由Google开源的,基于LSM Tree的单机KV数据库,其特点是高效,代码简洁而优美。Rocksdb则是Facebook基于LevelDB改造的,它在level的基础上加了很多实用的功能,例如Column Family等,具体的差别大家可以Google,也可以实际用一下体验一下,这里就不再赘述了。
Rocksdb目前已经运用在许多知名的项目中,例如TiKV,MyRocks,CrockRoach等。
Rocksdb使用上的缺点
rocksdb是通过wal来保证数据的持久性的,当rocksdb出现问题当机后,可以通过重做wal来使rocksdb恢复到当机前的状态。但是这里存在两个问题
1、当你为了读性能把memtable设置的足够大时,WAL也可能变得很大(Flush频率下降),此时如果发生当机,rocksdb需要足够长的时间来恢复。
2、如果机器硬盘出现损坏,wal被破坏,那么会出现数据损坏。即使你做了Raid,也需要很长时间来恢复数据。
因此可用性是个大问题。
另外由于LSM架构,rocksdb的读性能存在问题。
怎么解决?
为了一致性,大部分的解决方案都是将一致性协议置于rocksdb之上,每份数据通过一致性协议提交到多个处于不同机器的rocksdb实例中,以保证数据的可靠性和服务的可用性。
典型如TiKV
但这也还是有缺点,本身LSM Tree架构的一大问题就是写放大。每个rocksdb为了提高读性能,都会进行Compaction,而似这样的多份(一般3份)写入rocksdb,等于CPU消耗确定会*3,并且写放大由于提高了写的次数,即提高SSD的擦写次数,会显著减少SSD的寿命,提高系统的成本。
来源 https://zhuanlan.zhihu.com/p/162052214
相关文章