2019ODCC開放數據中心峰會亮點劇透之KV SSD

  ICCSZ訊 當前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開放數據中心峰會，會有更詳細的解讀。