论文阅读（２）：ｈａｓｈｋｖ

香港中文大学ｈｅｌｅｎ　HashKV: Enabling Efficient Updates　in KV Storage via Hashing

 

针对问题：ｋｖ分离设计中，ｖａｌｕｅｌｏｇ的ｇｃ的效率低下，尤其在ｕｐｄａｔｅ　ｉｎｔｅｎｓｉｖｅ负载中。

第一：环形日志维持严格ＧＣ顺序，总是在最近的ｋｖ对插入的位置开始进行ＧＣ。会造成不必要的数据移动。

第二：ｇｃ需要查询ＬＳＭ来检查ｋｖ的有效性，而这个查询有着很高的延迟。

 

ｈａｓｈｋｖ的解决方法：

１．对ｖａｌｕｅ　ｓｔｏｒａｇｅ进行基于ｈａｓｈ的数据分组设计。将ｖａｌｕｅ　ｓｔｏｒａｇｅ分成固定大小的分组，每个新插入的ｋｖ对根据ｈａｓｈ值选择ｇｒｏｕｐ进行ａｐｐｅｎｄ。

并在此基础上，提出了三点扩展：

动态的保留空间分配：如果原始的ｈａｓｈ分组满了，动态的分配保留空间给额外的ｗｒｉｔｅ

热点感知：分离ｈｏｔ和ｃｏｌｄ的键值对来提高ｇｃ效率。

选择性的ｋｖ分离：！！！！小ｓｉｚｅ的ｋｖ对完全保留在ＬＳＭｔｒｅｅ来简化查询。

 

实验，对ｌｅｖｅｌｄｂ，ｒｏｃｋｓｄｂ，ｋｖｓｅｐｅｒａｔｉｏｎ进行了对比，在ｌｏａｄ和ｕｐｄａｔｅ两种数据ｓｃｈｅｍｅ下，ｗｉｓｃｋｅｙｄｂ在ｕｐｄａｔｅ表现的很差。

ＳＳＤ分组，ｈｏｔ　ｋｖ对会进行更多ｇｃ，相应他们在ｌｓｍｔｒｅｅ也在更上层，查询更少。

 

ｈａｓｈｋｖ设计：

１．基于哈希的数据分区：分区隔离，使得一个ｋｅｙ的所有ｕｐｄａｔｅ都在一个分区里。确定性分区，一个ｖａｌｕｅ应该被存储的分区由ｈａｓｈ决定。

２．动态保留空间的分配，每个分区大小固定，有些分区可能增长的超出了这个限制，这时就分配保留空间给他。

３．热点感知：很多时候，热点数据和冷数据被分配到一个分区，那么对这样分区的垃圾回收会导致冷数据被反复重写。ｈａｓｈｋｖ通过标签技术将冷热数据分开。

４．选择性的ｋｖ分离：比较小的ｖａｌｕｅ就不适用ｋｖ分离的机制。

 

 

 

 

ｇｃ策略：

选择那个ｓｅｇｍｅｎｔｇｒｏｕｐ进行ｇｃ？

目前是贪婪算法，最多写操作的一个ｇｒｏｕｐ

怎么尽快判断一个ｋｖ对是否ｖａｌｉｄ？

将ｋｅｙ，ｍｅｔａ和ｖａｌｕｅ一起存在ｖａｌｕｅｌｏｇ中，这样就不用去ＬＳＭｔｒｅｅ里去找，直接通过ｓｃａｎ　ｖａｌｕｅｌｏｇ的对应ｇｒｏｕｐ就能知道。与ｇｒｏｕｐ　ｅｎｄ离得最近的一个版本的ｋｖ对必然是最新的。

 

热点感知：

标签技术，对ｓｅｇｇｒｏｕｐ中每个ｋｖ　ｐａｉｒ进行ｈｏｔ、ｃｏｌｄ分类

当前方法：上次插入之后至少ｕｐｄａｔｅ过一次的叫做热数据，热数据还存在ｓｅｇｇｒｏｕｐ，但冷数据就只将ｍｅｔａ放在ｇｒｏｕｐ里，而将ｋｖ放在另外的存储空间，并用ｔａｇ标示，等以后被更新过，在更新为热数据。而对于ｃｏｌｄｄａｔａ的ｖｌｏｇ的垃圾回收，就执行ｗｉｓｃｋｅｙｄｂ的ｖｌｏｇ　ｇｃ方法。

 

选择性的键值分离：

我当初的想法和他一致

 

范围查询：

使用ＬＳＭｔｒｅｅ的关键因素，键值在ｓｓｔａｂｌｅ中都是有序排列的。类似ｗｉｓｃｋｅｙｄｂ，通过ｐｒｅｒｅａｄ策略，减少范围查询的延迟，将值预取到ｐａｇｅｃａｃｈｅ中。

 

崩溃一致性：

元数据日志，ｆｌｕｓｈ写缓存，ｇｃ

元数据日志是用来记录每一次ｆｌｕｓｈ操作的。