RocksDB系列二十二:RocksDB使用场景和特性

  存储和访问数百PB的数据是一个非常大的挑战,开源的RocksDB就是FaceBook开放的一种嵌入式、持久化存储、KV型且非常适用于fast storage的存储引擎。
  传统的数据访问都是RPC,但是这样的话访问速度会很慢,不适用于面向用户的实时访问的场景。随着fast storage的流行,越来越多的应用可以通过在flash中管理数据并快速直接的访问数据。这些应用就需要使用到一种嵌入式的database。
  使用嵌入式的database的原因有很多。当数据请求频繁访问内存或者fast storage时,网路延时会增加响应时间,比如:访问数据中心网络耗时可能就耗费50ms,跟访问数据的耗时一样多,甚至更多。这意味着,通过RPC访问数据有可能是本地直接访问耗时的两倍。另外,机器的core数越来越多,storage-IOPS的访问频率也达到了每秒百万次,传统数据库的锁竞争和context 切换会成为提高storage-IOPS的瓶颈。所以需要一种容易扩展和针对未来硬件趋势可以定制化的database,RocksDB就是一种选择。
  RocksDB是基于Google的开源key value存储库LevelDB,主要满足以下目标:

1、适用于多cpu场景

  商业服务器一般会有很多cpu核,要开发一个随着CPU 核数吞吐量也随之增大的数据库是很困难的,更别提是线性的递增关系。但是,RocksDB是可以高效地运行在多核服务器上。一个优点是RocksDB提供的语义比传统的DBMS更简单。例如:RocksDB支持MVCC,但是仅限于只读的transaction。另一个优点是数据库在逻辑上分片为read-only path和read-write path。这两种方法可以降低锁竞争,而降低锁竞争是支持高并发负载的前提条件。

2、高校利用storage(更高的IOPS、高效的压缩、更少的写磨损)

  现在的存储设备都可以支持到每秒10w的随机读,如果有10块存储卡的话就可以支持每秒100w的随机读。RocksDB可以在这种快速存储上高效运行且不会成为性能瓶颈。
  和实时更新的B-tree相比,RocksDB有更好的压缩和更小的写放大。RocksDB由于压缩更优,所以占用更少的storage;由于更小的写放大,flash 设备可以更持久。

3、弹性架构,支持扩展

  RocksDB支持扩展。比如,我们可以新增一个merge operator,这样就可以使用write-only来替代read-modify-write。然而,read和Write是会增加存储的读写IOPS。在写频繁的负载下,这种措施可以降低IOPS。

4、支持IO-bound、in-memory、write-once

  IO-bound workload是指数据库大小远大于内存且频繁地访问storage。in-memory workload是指数据库数据都在内存中且仍然使用storage来持久化存储DB。write-once workload是指大部分的key都只会写入一次或者insert且没有更新操作。现在RocksDB很好支持IO-bound,要想更好地支持in-memory,需要做一些工作。支持write-once的话,还有很多遗留问题待解决。

  RocksDB不是一个分布式的DB,而是一个高效、高性能、单点的数据库引擎。RocksDB是一个持久化存储keys和values的c++ library。keys 和values可以是任意的字节流,且按照keys有序存储。后台的compaction会消除重复的和已删除的key。RocksDB的data以log-structured merge tree的形式存储。RocksDB支持原子的批量写入操作以及前向和后向遍历。
  RocksDB采用“可插拔式”的架构,所以很容易替换其中的组件,允许用户很容易在不同的负载和硬件设备上进行调优。


1441593_10151976018697200_1580274673_n.png

  比如,用户可以添加不同的压缩模块(snappy, zlib, bzip, etc),且使用不同模块时不用修改源码。这可用于在不同负载下通过配置使用不同的压缩算法。同理,用户可以在compaction时加载个性化的compaction filter来处理keys,例如,可以实现DB的key的"expire-time"功能。RocksDB有可插拔式的API,所以应用可以设计个性化的数据结构来cache DB的写数据,典型应用就是prefix-hash,其中一部分key使用hash存储,剩下的key存储在B-tree。storage file的实现也可以定制开发,所以用户可以实现自己的storage file格式。
  RocksDB支持两种compaction style(level style和universal style)。这两种style可做读放大、写放大、空间放大之间做tradeoff。compaction也支持多线程,所以打的DB可以支持高性能的compaction。
  RocksDB也提供在线的增量备份接口,也支持bloom filters,这可以在range-scan时降低IOPS。
  RocksDB可以充分挖掘使用flash的IOPS,在随机读、随机写和bulk load时性能优于LevelDB。在随机写和bulk load时,性能优于LevelDB 10倍,在随机读时性能优于LevelDB 30%。
  LevelDB是单线程执行compaction,在特定的server workload下表现堪忧,但是RocksDB在IO-bound workload下性能明显优于LevelDB。在测试中发现,LevelDB发生频繁的write-stall,这严重影响了DB的99%延迟,另外也发现,把文件mmap到OS cache会引入读性能瓶颈。测试表明,应用不能充分使用flash的高性能,这是因为数据的带宽瓶颈引起了LevelDB的写放大。通过提高写速率和降低写放大,可以避免很多问题,同时提高RocksDB性能。
RocksDB的典型场景(低延时访问):
1、需要存储用户的查阅历史记录和网站用户的应用
2、需要快速访问数据的垃圾检测应用
3、需要实时scan数据集的图搜索query
4、需要实时请求Hadoop的应用
5、支持大量写和删除操作的消息队列

推荐阅读更多精彩内容