《WiscKey: Separating Keys from Values in SSD-conscious Storage》阅读笔记

abstract

  我们提供了WiscKey，这是一个持久的基于LSM树的键值存储，具有面向性能的数据布局，它将键与值分离，以最小化I/O放大值。WiscKey的设计是高度SSD优化的，利用了设备的顺序和随机性能特性。我们用微基准测试和YCSB工作负载演示了WiscKey的优势。微基准测试结果显示，WiscKey比LevelDB快2.5×-111×，比随机查找快1.6×-14×。在所有六个YCSB工作负载中，WiscKey比LevelDB和RocksDB都要快。

introduction

  对于写密集型workload，基于对数结构化合并树(LSM-trees)的键值存储已经成为SOTA。由于LSM在background持续进行读、排序、写 k-v对，因此相同的数据被读写多次，I/O放大达到了50倍甚至更高。
  对于传统的classic hard-disk drives (HDDs）顺序I/O比随机I/O快100倍以上，因此，对连续排序的键执行额外的顺序读取和写，并启用有效的查找是一种很好的权衡。
  存储领域飞快地变化：1）对于SSD来说，顺序I/O和随机I/O的差距变小了；2）SSD具有很大程度的内部并行性；构建在SSD之上的LSM必须精心设计，以利用并行性；3）ssd通过重复写入而磨损

  WiscKey背后的核心思想是键和值的分离，只有键在LSM树中保持排序，而值则单独存储在日志中，换句话说，我们在WiscKey中解耦键分类和垃圾收集，而LevelDB将它们捆绑在一起。这种简单的技术可以通过避免排序时不必要的值移动，从而显著减少写放大。此外，LSM-树的大小明显减小，导致更少的设备读取和更好的缓存在。查找期间。WiscKey保留了LSMtree技术的优点，包括出色的插入和查找性能，但没有过多的I/O放大。
 WiscKey适合于大value和小range query场景。这符合实际情况。在6个YCSB workloads下，都优于levelDB和 rocksDB。

Background and Motivation

Log-Structured Merge-Tree

介绍LSM tree的一些概念，可以看看LSM的综述。

LevelDB

  介绍LevelDB中LSMTree的实现，大体上是Figure 1的过程，注意一点是L0层中数据是有可能重叠，且并不是完全有序的（即每个immutable memtable 转成sstable之后直接放到L0层，再L0层满了之后，挑一个SStable合并到L1层中）。
  loopup的过程依次是memtable->immutable memtable-> L0（所有）->L1->L2…->L6，因为L0中可能有重叠，因此L0层要search多个文件。

Write and Read Amplification

  理论和实验分析了独写放大的情况

Fast Storage Hardware

  尽管顺序读比随机读快（并没有HDD的差距这么明显），但是当SSD并发多个线程并且读的数据很大时，随机的速度读是可能达到并发读的。

WiscKey

1. WiscKey将键和值分开，只保留LSM树中的键，将值保存在单独的日志文件中。
2. 为了处理未排序的值（在范围查询期间需要随机访问），WiscKey使用了SSD设备的并行随机读取特。
3. WiscKey利用独特的crash-consistency和garbage-collection技术来有效地管理valuelog。
4. WiscKey通过在不牺牲一致性的情况下删除LSM-tree日志来优化性能，从而减少了来自小写操作产生的系统调用开销。

Design Goals

1. Low write amplification
2. Low read amplification
3. SSD optimized
4. Feature-rich API
5. Realistic key-value sizes

Key-Value Separation

一般情况下key比value写的多，因此能极大的缓解写放大，而又优于sstable只存key减小了大小，因此很load到内存里去。那么读的时候拿到key对应的value的地址，再去磁盘里拿value。删的时候只删除key,value交给之后的gc来处理。

Challenges

garbage collection和crash consistency挑战

Parallel Range Query

  range query时需要发出随机I/O，为了提高随机I/O的性能，用到了之前说的SSD的并发请求。
prefetch框架可以很容易地适应当前的范围查询接口。在当前界面中，如果用户请求范围查询，则将向用户返回一
个迭代器。对于在迭代器上请求的每个Next()或Prev()，WiscKey将跟踪范围查询的访问模式。一旦请求了一个连续的键值对序列，WiscKey就开始从LSM树中依次读取一些接下来的一些键。从LSM树中检索到的相应值地址被插入到一个队列中；多个线程将在后台同时从vLog中获取这些地址。

Garbage Collection

   如图5，每次插入value时插入到head，每次gc时候移动tail，在LSM中查询依次tail的key，如果有，则将tail的东西同时插入到head，如果没有，就直接移动tail不干其他事情了。

Crash Consistency

   比较简单，就是要么有key无value则在lsm中删除key返回user Not Found，要么有value无key什么都不干，gc一下就完事了。
   如果用户特别请求同步插入，那么LSM-tree实现还保证了系统崩溃后键值对的用户持久性。WiscKey通过在执行同步插入到其LSM-tree之前刷新vLog来实现同步插入。

Optimizations

未看待续