[RocksDB剖析系列] RocksDB的历史

相关资料

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的愿景

1. 带有点查找和范围扫描的嵌入式键值存储
2. 针对快速存储进行优化，例如闪存和RAM
3. 提供全面生产支持的服务器端数据库
4. 随CPU内核数和存储IOPs线性扩展

需要注意的是，RocksDB不是分布式数据库。它没有内置容错或复制功能。它对数据分片一无所知。目前比较多的方案应该是Raft+RocksDB。