共计 1200 个字符，预计需要花费 3 分钟才能阅读完成。
相干材料
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。