Rocksdb的基礎架構。
Rocksdb中引入了ColumnFamily(列族, CF)的概念，所謂列族也就是一系列kv組成的數據集。所有的讀寫操作都需要先指定列族。寫操作先寫WAL，再寫memtable，memtable達到一定閾值後切換為Immutable Memtable，只能讀不能寫。後臺Flush線程負責按照時間順序將Immu Memtable刷盤，生成level0層的有序文件(SST)。後臺合併線程負責將上層的SST合併生成下層的SST。Manifest負責記錄系統某個時刻SST文件的視圖，Current文件記錄當前最新的Manifest文件名。 每個ColumnFamily有自己的Memtable， SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。
架構分析
整個系統的設計思路很好理解，這種設計的優勢很明顯，主要有以下幾點：
1.所有的刷盤操作都採用append方式，這種方式對磁盤和SSD是相當有誘惑力的；
2.寫操作寫完WAL和Memtable就立即返回，寫效率非常高。
3.由於最終的數據是存儲在離散的SST中，SST文件的大小可以根據kv的大小自由配置， 因此很適合做變長存儲。
但是這種設計也帶來了很多其他的問題：
1.為了支持批量和事務以及上電恢復操作，WAL是多個CF共享的，導致了WAL的單線程寫 模式，不能充分發揮高速設備的性能優勢（這是相對介質講，相對B樹等其他結構還是有優 勢）；
2.讀寫操作都需要對Memtable進行互斥訪問，在多線程併發寫及讀寫混合的場景下容易形 成瓶頸。
3.由於Level0層的文件是按照時間順序刷盤的，而不是根據key的範圍做劃分，所以導致各 個文件之間範圍有重疊，再加上文件自上向下的合併，讀的時候有可能需要查找level0層的 多個文件及其他層的文件，這也造成了很大的讀放大。尤其是當純隨機寫入後，讀幾乎是 要查詢level0層的所有文件，導致了讀操作的低效。
4.針對第三點問題，Rocksdb中依據level0層文件的個數來做前臺寫流控及後臺合併觸發， 以此來平衡讀寫的性能。這又導致了性能抖動及不能發揮高速介質性能的問題。
5.合併流程難以控制，容易造成性能抖動及寫放大。尤其是寫放大問題，在筆者的使用過程中實際測試的寫放大經常達到二十倍左右。這是不可接受的，當前我們也沒有找到合適的解決辦法，只是暫時採用大value分離存儲的方式來將寫放大盡量控制在小數據。
適用場景
1.對寫性能要求很高，同時有較大內存來緩存SST塊以提供快速讀的場景；
2.SSD等對寫放大比較敏感以及磁盤等對隨機寫比較敏感的場景；
3.需要變長kv存儲的場景；
4.小規模元數據的存取；
不適合場景
1.大value的場景，需要做kv分離；
2.大規模數據的存取
