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

最新推荐文章于 2025-12-17 14:20:19 发布

原创最新推荐文章于 2025-12-17 14:20:19 发布 · 301 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #数据库开发 #数据库架构

SplitKV是一种针对不同大小键值对优化的存储方案，利用持久性内存(PM)和SSD的特性，将小Item存储在PM中，大Item直接写入SSD。文章探讨了处理小Item的挑战，提出了热感知的KV迁移机制，并讨论了有效的索引管理和流控问题，以提高系统性能和减少写放大。评估结果显示SplitKV在多种工作负载下表现优越。

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中读。