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
- 大小Item的边界问题,PM flush到SSD过程要竞争PM的读带宽和SSD的写带宽。balance 写PM开销和写SSD开销。
- Item冷热问题,在读写SSD中小数据时会导致写放大,尤其是需要考虑SSD垃圾回收(寿命)的问题。设计好的迁移过程避免对KVs性能产生影响。
- 索引问题,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写带宽问题,仍需解决。