[RocksDB剖析系列] 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倍的数据库上执行相同的基准测试时，性能结果令人沮丧。
【[RocksDB剖析系列] RocksDB的历史】此外，leveldb的单线程压缩，频繁的写暂停导致99%的延迟非常大。leveldb并不能消费闪存带来的io量。在闪存的发展下，需要一个能够在读放大、写放大和空间放大之间进行优雅权衡的数据库。所以，RocksDB诞生了。
RocksDB的愿景