当前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 write)
虽然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开放数据中心峰会，会有更详细的解读。
项目经理：豆坤
西安三星电子研究所 高级工程师
2019ODCC开放数据中心峰会：http://www.idcquan.com/Special/ODCC2019/
【凡本网注明“来源：中国IDC圈”的所有作品，均为中国IDC圈网站及所属新媒体号合法拥有版权或有权使用的作品，未经本网授权不得转载、摘编或任何方式加以利用。如有转载需求，欢迎与本网联系。已经本网授权使用作品的，应在授权范围内使用，并注明“来源：中国IDC圈”或相关新媒体号名称。违反上述声明者，本网将追究其相关法律责任。】
热门专题
