SplitKV: Splitting IO Paths for Different Sized Key-Value Items with Advanced Storage Devices

SplitKV: Splitting IO Paths for Different Sized Key-Value Items with Advanced Storage Devices

Background

传统的块设备最求大粒度的顺序写，新的设备提供了新的特性，为高性能的KVs设计提供了新的选择。

Optane SSD与PM不同大小的Item写延迟差距

---

Problem

以前的KVs的I/O路径都是统一的，没有考虑到Item大小的影响。

在真实情况下，小Item占主导地位。

以Facebook三个工作负载为例，其平均Value大小为：

• social graph: 126.7B
• distributed KV store: 42.9B
• AI/ML services: 46.8B

---

Challenges

1. 大小Item的边界问题，PM flush到SSD过程要竞争PM的读带宽和SSD的写带宽。balance 写PM开销和写SSD开销。
2. Item冷热问题，在读写SSD中小数据时会导致写放大，尤其是需要考虑SSD垃圾回收(寿命)的问题。设计好的迁移过程避免对KVs性能产生影响。
3. 索引问题，PM访问一个Item只需要小于1微秒的时间(sub-microsecond)，需要构高效的索引去管理PM上小的Item和SSD上大的Item。

sub-microsecond 代表小于1微秒; sub-second 小于1秒;

---

Design

把小的KV item先存储在PM中然后在写入SSD中，大的KV item直接写入SSD。

PM空间有限，需要空间释放，SplitKV会选择一部分Item迁移到SSD上。迁移的数据会被排序生成Sorted Tables（等于RocksDB中的SST），对于大的Item，直接写入SSD不需要排序。

为了检索PM和SSD中的数据，维护了一个全局的B±tree索引**（存放在PM中）**。

---

问：持久性内存很大吗？对于TB级的数据能存放下B±tree索引结构吗？

答：持久性内存的三个特征：大、快、持久性；单台服务器使用持久性内存可以轻松达到TB级的内存容量。SSD<速度<DRAM ;

---

崩溃一致性采用的还是B±tree所采用的方式。

---

Size Boundary of KV Items

为了确定Item size Boundary，需要考虑写入PM+SSD所需时间和直接写入SSD的时间。

当Item = 4KB时Ratio开始下降。迁移线程为了迁移大的Item会竞争PM带宽。

因此Item >= 4KB 被认为是大的Item。在PM中的小Item，访问速度快，就地更新。

---

Direct Writing Small KV Items

不采用批处理I/O，采用批处理需要在DRAM中开辟一块内存空间。并不会带来吞吐量的收益，反而会增加内存拷贝的开销。此外批处理会有着崩溃不一致性的风险，为了保证一致性还需要额外的开销如log。

---

Hotness-aware KV Migration

小的Item写入SSD可能会导致严重的gc开销。使用热感知的 KV迁移机制，将不经常访问的数据进行迁移。

实现：为每个Item加一个访问计数器cnt，当PM的空间利用率达到80%时，将cnt小于等于cnt_avg的Item进行排序和迁移。将cnt>cnt_avg的减去平均值。

当迁移时Item会被排序和聚集在4KB blocks中然后写入SSD。有助于扫描操作，只需要读几个sorted tables。减少了写放大。

迁移过程中读线程会竞争PM的读带宽，需要考虑其对前台查询线程的影响。太快竞争带宽影响查询、太慢导致PM空间回收慢。

读带宽随着写线程个数增加的变化。读线程为2时吞吐量趋于稳定。

采用一个读线程，对写操作影响有限，且可以临时增加读线程数量来更快释放空间。

---

KV Operation

• Put：小item直接写入PM，大Item（批处理）写入队列，然后等待提交。写入SSD或PM，并创建B树索引返回给用户写入成功。
• Update：小item如果在PM直接就地更新，如果在SSD则写入PM，然后更新索引，最后将SSD上的数据标记为无效等待垃圾回收。大Item执行B树正常的就地更新策略。
• Get/Scan：根据全局索引从PM或SSD中读。

---

Evaluation

System and hardware configuration.

系统/硬件	配置信息
CPU	Intel Xeon Gold 5215 CPU (2.5GHZ)*2
Memory	64GB
SSD	Intel Optane SSD P4800
PM	Intel Optane DC PM
OS	CentOS Linux release 7.6.1810 with 4.18.8 kernel

RocksDB（Memtable Size 64MB）、KVell、NoveLSM（Memtable Size 64MB，8GB PM）、SplitDB（8GB PM）

Workloads

工作负载名称	组成
A	read: 50%,update: 50%
B	read: 95%,update: 5%
C	read: 100%
D	read: 95%,insert: 5%
E	scan: 95%,insert: 5%
F	read: 50%,read-modify-writes:50%

每种工作负载包括Uniform和Zipfan两种分布。B,C,D读密集型工作负载。

每个工作负载128GB，Item大小为256B或4KB（各占一半）。执行5次取平均。

---

Discussion Topics

Handling small items

SplitKV通过PM缩短了写I/O的路径，但是如何组织和更新在SSD上的小Item仍然是个问题。未来可以对migrated policy进一步优化。可以进一步研究PM和SSD的特性将Item划分为不同类型。从而进一步使PM保持Item，减少I/O次数。

---

Efficient indexig

PM的写延迟几乎是SSD的100倍，但是在系统层次只有10倍。

全局的B树索引拖累了在PM中的查询速度。

解决方法：针对PM和SSD建立各自的混合索引，重新考虑读写扫描的实现。

---

Flow control of PM

竞争PM读带宽，竞争SSD写带宽问题，仍需解决。