ICCSZ訊 當前Key-Value數據庫或存儲引擎由于較高的存儲性能被廣泛的應用于企業(yè)中,但是由于Key-Value數據庫寫(xiě)入或者讀取KV鍵值對的時(shí)候, 需要完成從KV到file, file到LBA, 再從LBA到PBA的數據轉換。這種數據存取模式在機械硬盤(pán)上并沒(méi)有表現出太多的劣勢,但是隨著(zhù)固態(tài)硬盤(pán)應用地越來(lái)越廣泛,存儲速度越來(lái)越快,這種數據轉換所消耗的資源也越來(lái)越多,在某些情況下就會(huì )變成整個(gè)系統的性能瓶頸。
KV SSD software stack vs Block SSD S/W stack
為了解決這個(gè)問(wèn)題,近來(lái)業(yè)界提出了一種新的解決方案,Key-Value SSD。這種SSD采用了一種增強的FTL(Flash Translation Layer),實(shí)現了KV存儲的部分核心功能,向外提供KV接口,能夠直接響應host端應用程序的KV請求。將KV SSD與KV數據庫或KV存儲引擎(如RocksDB)配合使用,在諸多方面都會(huì )帶來(lái)較大的提升。
RocksDB vs KV Stack work flow
首先,KV數據庫從KV SSD中讀寫(xiě)數據時(shí)可以調用KV SSD提供的KV接口,將KV的讀寫(xiě)請求直接轉換為對PBA的請求,省去了從key到file,再從file到LBA的轉換,簡(jiǎn)化了數據讀寫(xiě)的流程,不但提高了數據讀寫(xiě)的效率,還大大減少了主機端CPU和內存的消耗。其次,像RocksDB這樣的KV存儲引擎采用的是LSM Tree的方式來(lái)分層存儲數據,對記錄的更改不是在系統中找到舊的數據進(jìn)行修改,而是直接將新的記錄以Append的方式寫(xiě)入到內存中,然后再flush到數據庫的第一層。每層的數據寫(xiě)到一定容量之后就會(huì )觸發(fā)compaction操作,將該層的一些文件里的key-value重新排序,去除舊的數據記錄,融合成新的文件寫(xiě)入到下一層。這種機制產(chǎn)生了很多Background IO,消耗了一定的SSD帶寬,不但影響了系統的性能,還使得RocksDB在運行時(shí)有著(zhù)高達10倍的寫(xiě)放大。而KV SSD提供了原生的KV接口,RocksDB可以將新的數據記錄直接寫(xiě)入到SSD中,不需要再進(jìn)行反復的compaction操作,從而將RocksDB的寫(xiě)放大減小到了1,而NAND本身就不支持覆蓋寫(xiě)入的特性使得SSD端的寫(xiě)放大并沒(méi)有顯著(zhù)增加,所以整體來(lái)看,KV SSD降低整個(gè)系統寫(xiě)入放大的效果還是很明顯的。
另外,由于支持原生的key value操作和簡(jiǎn)易的軟件協(xié)議棧,KV SSD結合優(yōu)化過(guò)的Ceph應用時(shí)也會(huì )比傳統解決方案有很大的優(yōu)勢。使用優(yōu)化過(guò)的KVSstore替代原生Ceph的blue store后,性能和穩定性方面都有了很顯著(zhù)的提升。
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在諸多方面都有著(zhù)傳統SSD無(wú)法比擬的優(yōu)勢,但是想方便地,廣泛地在業(yè)務(wù)系統中部署KV SSD還需要配合優(yōu)化過(guò)的軟件協(xié)議棧。從前面的流程圖中可以看到,KV SSD是一個(gè)系統的解決方案,需要SSD,驅動(dòng)以及客戶(hù)應用程序的相互配合才可以實(shí)現。同時(shí)由于客戶(hù)的應用程序千差萬(wàn)別,對接口的需求也各不相同,所以需要客戶(hù)針對自己的應用靈活適配標準的KV API或直接使用KV版本的RocksDB或Ceph等應用,以方便廣大客戶(hù)方便地在系統中部署KV SSD。目前KV SSD軟件部分已經(jīng)在GitHub上開(kāi)源并持續迭代。(https://github.com/OpenMPDK/KVSSD)
如對該項目感興趣,請參加9月3-4日2019開(kāi)放數據中心峰會(huì ),會(huì )有更詳細的解讀。