SoftHub关联区 - Facebook在Google LevelDB后为何发布自己的RocksDB[转贴]

您的位置：首页 >> SoftHub关联区 >> 主题: Facebook在Google LevelDB后为何发布自己的RocksDB[转贴] [回主站] [分站链接]

您的位置：首页 >> SoftHub关联区 >> 主题: Facebook在Google LevelDB后为何发布自己的RocksDB[转贴] [最新] [回主站]

Facebook在Google LevelDB后为何发布自己的RocksDB[转贴]

clq

浏览(284) - 2018-03-01 17:07:08 发表编辑

关键字: leveldb

Facebook在Google LevelDB后为何发布自己的RocksDB[转贴]

那么可以总结，如果不需要排序的话实际上可以直接使用 hash 就行了。然后前端加个全内存缓存或者命中率缓存就可以了。
--------------------------------------------------
Facebook在Google LevelDB后为何发布自己的RocksDB

影子工程师
百家号12-0813:08

Google LevelDB目前已经被广泛应用在各种公司内部的系统中，作为write-friendly的可持久化引擎而得到推广和应用。然而，2011年推出的LevelDB，为什么到了2013却被Facebook加以改进并命名为RocksDB重新发布呢？主要的原因在于LevelDB（包括RocksDB）本质上是LSM-Tree（Log-Structured Merge-Tree）的模型，发表在1996的LSM-Tree模型与生俱有的一个缺陷就是Write/Read Amplification，即写放大和读放大问题。

LSM-Tree模型是全序模型（ordered key-value storage），换句话说里面的数据是按照key有序排列的；这么做的好处在于能采用类似于二分查找的方式快速定位，可以采用前缀压缩等手段进行有效数据管理；更重要的是支持前缀scan数据。这些技术特点能很好地为存储系统所扩展成更高级的应用模式（例如，表格存储系统，图存储系统等等）。但是，为了做到全序，在LSM-Tree引擎中，除了通常对外暴露的Put/Get/Scan操作外，还有一个非常重要的内部操作：Compact。Compact操作的目的是整理内部的数据，将随机写入的乱序数据整理成有序的数据排布到磁盘上。为了充分利用SATA磁道特点，在LSM-Tree引擎中，Compact会采用多路归并的方式，顺序读取多个数据文件，并归并排序顺序写入磁盘。这个多路归并过程需要额外读取的数据量和额外写入的数据量，处于用户实际读取和写入的数据量，就是读放大率和写放大率。

写放大问题最直接的影响就是浪费资源。打个比方说，如果写放大率是N，那应用层（用户）要获取1单位的写入吞吐，那意味着需要N个单位的资源。真正用过LevelDB的码农们都有一个感触，随着写入压力持续的时间不断增长，LevelDB写入吞吐在不停地下降，但磁盘util（可以通过iostat）却越来越高，甚至出现100MB/s的爆满情况。下图给出在压测5小时下（8个写线程，1个删除线程；key-value为20KB）LevelDB的用户吞吐与disk实际承受吞吐的对比情况，从中可以看出15x-20x的写放大率，以及用户实际有效写入吞吐衰减的过程。

LSM-Tree模型的这些潜在问题，使得在大规模工业应用中受到严重的制约——成本太高。为此，Facebook的工程师在Google LevelDB的基础上改进了整个Compact的策略和调度算法，从而分化出了自己具有代表性的Size-tiered LSM模型，并且从理论上推导出Write Amplification系数比LevelDB要好。

写放大引来的第二个严重隐患就是加速SSD盘片的淘汰速度，进而引发系统稳定性问题。在Compaction整理过程，其实是大量小文件的读写过程，这个过程实质上加剧了盘片的擦写次数，导致盘块的快速老化。SSD固件中有一个重要的参数，DWPD，定义了每天能够擦写的数据总量占总空间的比例。以4年生命周期的400GB的SSD为例，DWPD为0.375，意味着每天最大擦写量为400GB * 0.375这么大的数据量。如果超过这个量，那不到4年这个盘块就进入淘汰期，这个时候盘片可靠性大幅度下降并容易引发系统故障。

在Facebook之后，又出现了很多LSM的变种，都试图在某些特定的应用场景下能优化写放大，或者读延时等等单方面的特性。比较有代表性的是：Basho LevelDB,  HyperLevelDB, bLSM。然而，这些都没有从根本上改变LSM-Tree的模型。在学术界，2010发表的TokuDB,  2013年发表在ICDE的BW-Tree, 2011年发表在SOSP的SILT，以及2016年发表在FAST的WiscKey是从设计新引擎的角度来改变LSM-Tree引擎的写放大缺点，不同的思路也为我们在工业应用中解决Write Amplification问题提供了参考和解决思路。

在本人三年多对LSM-Tree的使用和引擎优化中，总结出一些经验来减缓甚至消除写放大所带来的问题：

（1）读写分离：读写混合的情况下，写放大问题会耗尽disk的IO资源。如果能在业务上实现read和write分离，那就有办法保证写吞吐最大和读延时最优。简单的说，无论用LevelDB还是RocksDB，可以在write-only阶段，将level 0配置成无限大，可以让write以最大吞吐写入；当write完成后，让Compaction进行全速进行，将各level数据进行压缩；之后进入read-only阶段，这个时候读的latency是最好的。

（2）将随机写改变成顺序写：Compaction过程被调度通常情况下是因为随机写入level低层的某些新数据的key scope覆盖（overlay）了高层level的数据集。如果能够在写入数据的时候先将数据排好序，那因为各level数据之间没有overlay关系，Compaction过程只是move数据而不存在多路归并的数据整理。这样也能消除写放大问题。

（3）引擎改造：写放大是由于Compaction对数据进行整理所导致的，整理的目的是为了排全序。如果我们应用场景不需要排全序，那实际上这个功能可以弱化甚至废弃。例如，在高延时的在线kv系统中，因为不需要全序的特点，因为可以将Compaction进行改造，变成全hash序的整理方式，从而大大降低写放大率。

以上方法在公司各种实际应用场景下均得到验证和应用，在实际业务中不失为一种可选的解决方案。

总数：0　页次：1/0　首页尾页　　

所在合集/目录

发表评论:

本帖子属于以下条目(leveldb)

leveldb相关数据库收集帖子

SSDB

NEWBT官方QQ群1: 276678893
可求档连环画,漫画;询问文本处理大师等软件使用技巧;求档softhub软件下载及使用技巧.
但不可"开车",严禁国家敏感话题,不可求档涉及版权的文档软件.
验证问题说明申请入群原因即可.