相干材料

The History of RocksDB: http://rocksdb.blogspot.com/2...

RocksDB的诞生起因

2011年中时，Dhruba Borthakur曾经在HBase/HDFS方面做了五年的开发工作，他十分青睐Hadoop优良的生态，但同时他想挑战一些新的货色：晋升HBase/HDFS的查问服务工作负载。

事实证明他在这方面做得很胜利，在对HBase/HDFS进行了多轮加强后，他曾经可能使HBase/HDFS的提早速度仅为MySQL服务器的两倍，并且HBase/HDFS在雷同硬件雷同工作负载下应用的IOPs仅为MySQL的三倍。

但这时，闪存存储成为了事实，数据集从旋转磁盘迁徙到闪存。而他通过测试后发现，2012年的HDFS/HBase存在一些软件瓶颈，因而无奈无效地应用闪存。如果数据存储在闪存中，那么就须要一个新的存储引擎，以便可能无效地为数据上的随机工作负载提供服务。

为什么RocksDB是嵌入式的？

假如说，旋转磁盘上的读取或写入大概须要10毫秒，闪存的读取或写入大概须要100微秒。两台机器之间的网络提早放弃在50微秒。那么在CS架构中，通过网络拜访旋转磁盘上的数据会导致10.05毫秒的提早，网络施加的开销仅为0.5%。而假如用闪存驱动器代替磁盘，对于本地连接的闪存，数据拜访工夫为100微秒，通过网络拜访雷同数据的工夫为150微秒。这种状况下，网络数据拜访的开销比本地数据拜访高50%。简而言之，当闪存提供了极高的IO速度时，网络成为了性能的瓶颈。

为什么不应用现有的嵌入式数据库？

过后现有的数据库曾经有很多了：BerkeleyDB, KyotoDB, SQLite3, leveldb。在这些数据库的开源基准测试中，leveldb仿佛是最快的那一个。但并非所有这些数据库都适宜在闪存上存储数据。因为闪存的写持久性无限，对闪存上数据块的更新通常会引入写入放大（write-amplification）。当对leveldb进行测试时，他发现它不适宜现实的服务器工作负载。开源基准测试后果乍一看十分棒，但只是针对一个大小小于测试机器的RAM的数据库。当在一个至多比main memory大5倍的数据库上执行雷同的基准测试时，性能后果令人丧气。

此外，leveldb的单线程压缩，频繁的写暂停导致99%的提早十分大。leveldb并不能生产闪存带来的io量。在闪存的倒退下，须要一个可能在读放大、写放大和空间放大之间进行优雅衡量的数据库。所以，RocksDB诞生了。

RocksDB的愿景

带有点查找和范畴扫描的嵌入式键值存储
针对疾速存储进行优化，例如闪存和RAM
提供全面生产反对的服务器端数据库
随CPU内核数和存储IOPs线性扩大

须要留神的是，RocksDB不是分布式数据库。它没有内置容错或复制性能。它对数据分片无所不知。目前比拟多的计划应该是Raft+RocksDB。