2019ODCC开放数据中心峰会亮点剧透之KV SSD

时间:2019-08-06 14:51:36       来源:项城网
当前Key-Value数据库或存储引擎由于较高的存储性能被广泛的应用于企业中,但是由于Key-Value数据库写入或者读取KV键值对的时候, 需要完成从KV到file, file到LBA, 再从LBA到PBA的数据转换。这种数据存取模式在机械硬盘上并没有表现出太多的劣势,但是随着固态硬盘应用地越来越广泛,存储速度越来越快,这种数据转换所消耗的资源也越来越多,在某些情况下就会变成整个系统的性能瓶颈。

KV SSD software stack vs Block SSD S/W stack

为了解决这个问题,近来业界提出了一种新的解决方案,Key-Value SSD。这种SSD采用了一种增强的FTL(Flash Translation Layer),实现了KV存储的部分核心功能,向外提供KV接口,能够直接响应host端应用程序的KV请求。将KV SSD与KV数据库或KV存储引擎(如RocksDB)配合使用,在诸多方面都会带来较大的提升。

RocksDB vs KV Stack work flow

首先,KV数据库从KV SSD中读写数据时可以调用KV SSD提供的KV接口,将KV的读写请求直接转换为对PBA的请求,省去了从key到file,再从file到LBA的转换,简化了数据读写的流程,不但提高了数据读写的效率,还大大减少了主机端CPU和内存的消耗。其次,像RocksDB这样的KV存储引擎采用的是LSM Tree的方式来分层存储数据,对记录的更改不是在系统中找到旧的数据进行修改,而是直接将新的记录以Append的方式写入到内存中,然后再flush到数据库的第一层。每层的数据写到一定容量之后就会触发compaction操作,将该层的一些文件里的key-value重新排序,去除旧的数据记录,融合成新的文件写入到下一层。这种机制产生了很多Background IO,消耗了一定的SSD带宽,不但影响了系统的性能,还使得RocksDB在运行时有着高达10倍的写放大。而KV SSD提供了原生的KV接口,RocksDB可以将新的数据记录直接写入到SSD中,不需要再进行反复的compaction操作,从而将RocksDB的写放大减小到了1,而NAND本身就不支持覆盖写入的特性使得SSD端的写放大并没有显著增加,所以整体来看,KV SSD降低整个系统写入放大的效果还是很明显的。

另外,由于支持原生的key value操作和简易的软件协议栈,KV SSD结合优化过的Ceph应用时也会比传统解决方案有很大的优势。使用优化过的KVSstore替代原生Ceph的blue store后,性能和稳定性方面都有了很显著的提升。

KVCeph + KV SSD vs Ceph + Block SSD (4KB write)

KVCeph + KV SSD vs Ceph + Block SSD (4KB sequential read)

KVCeph + KV SSD vs Ceph + Block SSD (4KB random read)

虽然KV SSD在诸多方面都有着传统SSD无法比拟的优势,但是想方便地,广泛地在业务系统中部署KV SSD还需要配合优化过的软件协议栈。从前面的流程图中可以看到,KV SSD是一个系统的解决方案,需要SSD,驱动以及客户应用程序的相互配合才可以实现。同时由于客户的应用程序千差万别,对接口的需求也各不相同,所以需要客户针对自己的应用灵活适配标准的KV API或直接使用KV版本的RocksDB或Ceph等应用,以方便广大客户方便地在系统中部署KV SSD。目前KV SSD软件部分已经在GitHub上开源并持续迭代。(https://github.com/OpenMPDK/KVSSD)

如对该项目感兴趣,请参加9月3-4日2019开放数据中心峰会,会有更详细的解读。