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

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

Design Goals

Low write amplification
Low read amplification
SSD optimized
Feature-rich API
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

未看待续

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

trainer setup_Detectron2源码阅读笔记-(一)Configamp;Trainer
一.代码结构概览 1.核心部分 configs:储存各种网络的yaml配置文件 datasets:存放数据集的地方 detectron2:运行代码的核心组件 tools:提供了运行代码的入口以及一切可 ...
VoxelNet阅读笔记
作者:Tom Hardy Date:2020-02-11 来源:VoxelNet阅读笔记
Transformers包tokenizer.encode()方法源码阅读笔记
Transformers包tokenizer.encode()方法源码阅读笔记_天才小呵呵的博客-CSDN博客_tokenizer.encode
源码阅读笔记 BiLSTM+CRF做NER任务流程图
源码阅读笔记 BiLSTM+CRF做NER任务(二) 源码地址:https://github.com/ZhixiuYe/NER-pytorch 本篇正式进入源码的阅读,按照流程顺序,一一解剖. 一.流 ...
Mina源码阅读笔记（一）-整体解读
2019独角兽企业重金招聘Python工程师标准>>> 今天的这一节,将从整体上对mina的源代码进行把握,网上已经有好多关于mina源码的阅读笔记,但好多都是列举了一下每个接口或者 ...
“CoreCLR is now Open Source”阅读笔记
英文原文:CoreCLR is now Open Source 阅读笔记如下: CoreCLR是.NET Core的执行引擎,功能包括GC(Garbage Collection), JIT(将CIL代 ...
QCon 2015 阅读笔记 - 团队建设
QCon 2015阅读笔记 QCon 2015 阅读笔记 - 移动开发最佳实践 QCon 2015 阅读笔记 - 团队建设中西对话:团队管理的五项理论和实战 - 谢欣.董飞(今日头条,LinkedI ...
05《软件需求模式》阅读笔记
剩下的两个阅读笔记写第二部分.各类需求模式,共八个领域和它的需求模式,这一次写前四个. 基础需求模式,它是所有种类的系统都可能需要的一些东西.系统间接口需求模式使用系统间接口需求模式定义被定义的系统和 ...
[置顶] Linux协议栈代码阅读笔记（一）
Linux协议栈代码阅读笔记(一) (基于linux-2.6.21.7) (一)用户态通过诸如下面的C库函数访问协议栈服务 int socket(int domain, int type, int p ...
大型网站技术架构：核心原理与案例分析阅读笔记二
大型网站技术架构:核心原理与案例分析阅读笔记二网站架构设计时可能会存在误区,其实不必一味追随大公司的解决方案,也不必为了技术而技术,要根据本公司的实际情况,制定适合本公司发展的网站架构设计,否则会变 ...

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