论文阅读（３）：ｐｅｂｂｌｅｓｄｂ

ｐｅｂｂｌｅｓｄｂ：ｐａｎｄｉａｎ　ｒａｊｕ（德克萨斯大学）等

 

 

摘要：针对ＬＳＭ写放大问题，依据ｓｋｉｐｌｉｓｔ的概念灵感，提出了ｆｌｓｍ结构。引入ｇｕａｒｄ的概念来管理ｌｏｇ，避免同一ｌｅｖｅｌ内重写数据。本文是在ｈｙｐｅｒｌｅｖｅｌｄｂ的基础上加上ｆｌｓｍ的结构设计。与ｒｏｃｋｓｄｂ以及在ｍｏｇｏｄｂ，ｈｙｐｅｒｄｅｘ中使用ｐｅｂｂｌｅｓｄｂ，在写放大以及写带宽上，均有明显优化。

 

ｋｖｓｔｏｒｅ应用场景：图数据库中存储状态，任务队列，流处理引擎，应用数据缓存，事件追踪系统，ｎｏｓｑｌ存储和分布式系统。

内存有效性的工作：９，１７，３４，４２，５８

减少写放大相关工作：３８，５５要求特定硬件，５７牺牲查询性能。牺牲写读带宽３４。１９，２２，ｃｏｍｐａｃｔ不做ｍｅｒｇｅ，单纯加ｓｓｔａｂｌｅ在每个ｌｅｖｅｌ。

设计概述：用ｇｕａｒｄ将数据分成小的ｃｈｕｎｋ。为了写带宽会牺牲读性能。

其他优化设计：并行ｓｅｅｋ，基于ｓｅｅｋ的主动ｃｏｍｐａｃｔ，ｓｓｔａｂｌｅ级别的布隆过滤器。

ＦＬＳＭ的设计：

将ｓｓｔａｂｌｅ分为小的ｓｅｇｍｅｎｔ，在ｃｏｍｐａｃｔ中，比起重写，直接把一个ｆｒａｇｍｅｎｔ　ａｐｐｅｎｄ到新ｓｓｔａｂｌｅ后面。

每层多个ｓｓｔａｂｌｅ可以有ｒａｎｇｅ的交叠，可以有重复的键。采用跳表中ｇｕａｒｄ的概念来快速在每个ｌｅｖｅｌ查找ｋｅｙ。随着ｌｅｖｅｌ的升高，ｇｕａｒｄ的粒度越来越细，ｇｕａｒｄ是从ｋｅｙ中选出来的。每个ｇｕａｒｄ都有一些列相关的ｓｓｔａｂｌｅ。每个ｓｓｔａｂｌｅ都是有序的。

感觉每层ｇｕａｒｄ的设计，就是一种混合设计，结合了原始ｌｓｍ的全部有序与，单纯ａｐｐｅｎｄ　ｓｓｔａｂｌｅ的纯粹无序。这样，每个到下层的ｓｓｔａｂｌｅ不需要ｃｏｍｐａｃｔ，只需要ｆｉｔ进ｇｕａｒｄ的ｒａｎｇｅ中。

 

关键：ｇｕａｒｄ的选择，尽量保证每个ｇｕａｒｄ包括的ｓｓｔａｂｌｅ数尽量平均，不然跟单纯ａｐｐｅｎｄ基本一样。

ｇｕａｒｄ　ｐｒｏｂａｂｉｌｉｔｙ：类似跳表的升级概率。随着ｌｅｖｅｌ升高，概率升高。如果一个ｋｅｙ在ｌｅｖｅｌｉ被选为ｇｕａｒｄ，那么在ｉ＋１之后，都作为ｇｕａｒｄ，即使这些ｌｅｖｅｌ可能没有这个ｋｅｙ。

ｇｕａｒｄ的添加，先是添加到内存中ｕｎｃｏｍｍｉｔｅｄｇｕａｒｄ的表中，因为添加ｇｕａｒｄ本身有很多附带操作，包括ｓｐｌｉｔ一个ｓｓｔａｂｌｅ，移动ｓｓｔａｂｌｅ。所以等到下次ｃｏｍｐａｃｔ的操作，再将所有ｕｎｃｏｍｍｉｔｅｄｇｕａｒｄ一起添加。

ｇｕａｒｄ的删除，主要是因为ｇｕａｒｄ不包括ｓｓｔａｂｌｅ，或者ｓｓｔａｂｌｅ在ｇｕａｒｄｓ间分布不均匀。此时也是，先缓存在内存中，等到下次ｃｏｍｐａｃｔ在一起删除。

 

并且因为，ｉ－ｌｅｖｅｌ的ｇｕａｒｄ都会出现在ｉ＋１中，所以在ｃｏｍｐａｃｔ，可以并行操作每个ｇｕａｒｄ　ｒａｎｇｅ。而不会影响其他ｇｕａｒｄ的合并。

 

关于读性能的优化措施：

ｌｅｖｅｌｄｂ，ｒｏｃｋｓｄｂ都有ｂｌｏｃｋ级别的ｂｆ，ｐｅｂｂｌｅｓｄｂ采用ｓｓｔａｂｌｅ级别的ｂｆ而放弃了ｂｌｏｃｋ级别的ｂｆ，提升ｇｅｔ效率。

范围查询优化：

ｓｅｅｋｂａｓｅｄ－ｃｏｍｐａｃｔｉｏｎ　：ｌｅｖｅｌｄｂ也有这个特性但删除了。

并行ｓｅｅｋ：对每个ｓｓｔａｂｌｅ的查询都单开一个线程，再将结果合并，给ｓｅｅｋ正确的位置。ｔａｂｌｅ有在ｏｓ中有缓存的时候不能用，开销大于提升？没明白为什么。