关于rocksdb:RocksDB剖析系列-RocksDB的历史

57次阅读

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

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

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

正文完
 0