RocksDB介绍:一个比LevelDB更彪悍的引擎

jopen 6年前


RocksDB基本介绍:


嵌入式数据库RocksDB是非死book基于LevelDB开发的一种嵌入式Key-value存储系统,该数据库能够充分利用闪存的性能,大大提升应用服务器的速度。

Rocksdb. 这个开源引擎是基于 Google 的 leveldb 1.5 版本, 但据称做了许多优化, 性能相对 leveldb 有了很大的提升, 而且解决了 leveldb 主动限制写的问题.

非死book 用RocksDB来驱动一些面向用户的应用,这些应用由于需要通过网络访问外部存储而性能低下,此外非死book还用RocksDB来解决固态硬盘 IO利用率不高相关的一些问题。非死book的数据库工程师Dhruba Borthakur在其个人博客介绍了RocksDB的设计原由和原理,但实际上催生RocksDB的最大动力来自服务器闪存存储卡的价格大幅下滑,非死book的定制服务器已经开始全面采用闪存。

随着闪存存储时代的到来,一些新的应用可以在闪存中管理并快速访问自己的数据集,无需通过网络访问外部数据。这些新应用使用的就是我们所说的嵌入式数据库。

数据库查询如果在本地闪存中进行,速度理论上会比通过数据中心内部网络查询快一倍,因为数据库中心内部网络有50微妙的延迟。

RocksDB 的能够充分利用闪存的高IOPS性能,同时也能利用多核服务器的计算性能,非死book目前已经在RocksDB的GitHub页面上发布了 RocksDB在Fusion-io服务器上的跑分基准测试结果,非死book声称其速度比Google的LevelDB嵌入式key-value存储系统快很多。



RocksDB和LevelDB的区别:


关于LevelDB的资料网上还是比较丰富的,如果你尚未听说过LevelDB,那请稍微预习一下,因为RocksDB实际上是在LevelDB之上做的改进。本文主要侧重在架构上对RocksDB对LevelDB改进的地方做个简单介绍并添加一些个人的看法,更详细的信息读者可参考其官网:http://rocksdb.org/

RocksDB是在LevelDB原来的代码上进行改进完善的,所以在用法上与LevelDB非常的相似。如下,就是简单的把原来Leveldb信息替换为Rocksdb,从继承的角度看,Rocksdb就像是Leveldb的后辈。


RocksDB:

#include "rocksdb/db.h"     rocksdb::DB* db;  rocksdb::Options options;  options.create_if_missing = true;     rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);     assert(status.ok());     status = db->Get(rocksdb::ReadOptions(), key1, &value);  status = db->Put(rocksdb::WriteOptions(), key2, value);  status = db->Delete(rocksdb::WriteOptions(), key1);     delete db;

LevelDB:

#include "leveldb/db.h"     leveldb::DB *db;  leveldb::Options options;  options.create_if_missing = true;     leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);     assert(status.ok());     status = db->Get(leveldb::ReadOptions(), key1, &value);  status = db->Put(leveldb::WriteOptions(), key2, value);  status = db->Delete(leveldb::WriteOptions(), key1);     delete db;   

RocksDB 虽然在代码层面上是在LevelDB原有的代码上进行开发的,但却借鉴了Apache HBase的一些好的idea。在云计算横行的年代,开口不离Hadoop,RocksDB也开始支持HDFS,允许从HDFS读取数据。而 LevelDB则是一个比较单一的存储引擎,有点我就是我,除了我依然只有我的感觉。也是因为LevelDB的单一性,在做具体的应用的时候一般需要对其作进一步扩展。

RocksDB支持一次获取多个K-V,还支持Key范围查找。LevelDB只能获取单个Key

RocksDB 除了简单的Put、Delete操作,还提供了一个Merge操作,说是为了对多个Put操作进行合并。站在引擎实现者的角度来看,相比其带来的价值,其实现的成本要昂贵很多。个人觉得有时过于追求完美不见得是好事,据笔者所测(包括测试自己编写的引擎),性能的瓶颈其实主要在合并上,多一次少一次Put 对性能的影响并无大碍。

RocksDB提供一些方便的工具,这些工具包含解析sst文件中的K-V记录、解析MANIFEST文件的内容等。有了这些工具,就不用再像使用LevelDB那样,只能在程序中才能知道sst文件K-V的具体信息了。

RocksDB 支持多线程合并,而LevelDB是单线程合并的。LSM型的数据结构,最大的性能问题就出现在其合并的时间损耗上,在多CPU的环境下,多线程合并那是 LevelDB所无法比拟的。不过据其官网上的介绍,似乎多线程合并还只是针对那些与下一层没有Key重叠的文件,只是简单的rename而已,至于在真正数据上的合并方面是否也有用到多线程,就只能看代码了。

RocksDB增加了合并时过滤器,对一些不再符合条件的K-V进行丢弃,如根据K-V的有效期进行过滤。

压缩方面RocksDB可采用多种压缩算法,除了LevelDB用的snappy,还有zlib、bzip2。LevelDB里面按数据的压缩率(压缩后低于75%)判断是否对数据进行压缩存储,而RocksDB典型的做法是Level 0-2不压缩,最后一层使用zlib,而其它各层采用snappy。

在故障方面,RocksDB支持增量备份和全量备份,允许将已删除的数据备份到指定的目录,供后续恢复。

RocksDB支持在单个进程中启用多个实例,而LevelDB只允许单个实例。

RocksDB 支持管道式的Memtable,也就说允许根据需要开辟多个Memtable,以解决Put与Compact速度差异的性能瓶颈问题。在LevelDB里面因为只有一个Memtable,如果Memtable满了却还来不及持久化,这个时候LevelDB将会减缓Put操作,导致整体性能下降。笔者目前写的引擎在这方面竟然跟RocksDB不谋而合,这里偷偷乐一下,呵呵。

看完上面这些介绍,相比LevelDB是不是觉得RocksDB彪悍的不可思议,很多该有的地方都有,该想的都想到了,简直不像在做引擎库,更像是在做产品。不过虽然RocksDB在性能上提升了不少,但在文件存储格式上跟LevelDB还是没什么变化的, 稍微有点更新的只是RocksDB对原来LevelDB中sst文件预留下来的MetaBlock进行了具体利用。

个人觉得RocksDB尚未解决的地方:

  1. 依然是完全依赖于MANIFEST,一当该文件丢失,则整个数据库基本废掉。
  2. 合并上依然是整个文件载入,一些没用的Value将被多次的读入内存,如果这些Value很大的话,那没必要的内存占用将是一个可观的成本。

关于这两个问题,尤其是后面那个问题,笔者已有相应的解决方案,至于结果如何只等日后实现之后再作解说了。



如何给RocksDB使用类似C/S的架构:


为了满足各位对 非死book 出品的 rocksdb 的爱好, SSDB 数据库也可以使用 rocksdb.

这个项目就是 ssdb-rocks: https://github.com/ideawu/ssdb-rocks

据说 rocksdb 性能不错, 在某些场景比 leveldb 更佳, 欢迎各位试用. 注意, rocksdb 和 leveldb 不兼容, 所以, 旧数据不能直接用于这两个引擎. 原来你用了 leveldb, 就能不直接换成 rocksdb, 你必须自己写脚本导数据.




RocksDB官网:http://www.rocksdb.org/ 

RocksDB源码:https://github.com/非死book/rocksdb/