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