LSM樹是針對寫友好的，但是Rocksdb在實現時有很多地方的代碼不能充分發(fā)揮底層存儲的性能。比如：
? 單線程寫WAL，寫WAL的IO size上限寫死為65536字節(jié)，不利于做IO聚合；
? 讀sst和寫sst的IO size設置為相同的，寫速度的加快需要加大寫的io size，這樣做反過來又降低了讀的效率，因為讀同一個kv需要從盤上讀更大的block；
? 寫大的value時沒有將kv分離，而是將kv一起都存到WAL和SST，造成寫放大不說，后臺合并的數據量巨大帶來的帶寬和CPU及內存占用對前臺的性能影響非常大，常常導致劇烈的性能抖動和性能降低。
? 所有的讀寫都是同步方式，導致寫wal和寫sst都不能并發(fā)，不能充分發(fā)揮盤的帶寬。
? 當前的流控策略根據內存占用和后臺level0層文件的個數和體積來減緩或者停止前臺IO，這種方式導致了劇烈的性能抖動。
筆者在HDD/NVME SSD/Ceph Rados上分別測試過Rocksdb的性能，這三者的同步寫性能分別是(170MB/s, 1200GB/s, 120MB/s)。不過最終的測試結果卻讓人大跌眼鏡， Rocksdb的性能分別為(<1MB/s, 50MB/s, 4MB/s)，最多只能發(fā)揮存儲側的%5性能。根據測試結果和以上的5點分析，筆者整理了一下我們系統(tǒng)中的優(yōu)化方式，希望能給大家?guī)椭?，也希望大家能給我們提出一些更好的優(yōu)化建議。
- 寫WAL size動態(tài)調整
當前的寫io大小上限為65536，不能動態(tài)調整；筆者通過對log格式稍作修改，將請求的上限擴展到4GB。具體修改方式就不具體介紹了，修改log_reader/log_writer中的編解碼方式即可。 - 并發(fā)寫WAL優(yōu)化
而且各個寫請求串行執(zhí)行，不能并發(fā)，這導致了寫的效率很低。筆者曾經考慮將WAL做分核，每個寫都寫到當前核上，無奈這種方法對寫流程改動太大，同時還影響到flush, load, transaction流程，所以遲遲沒能動手。后來我想到了一種簡單辦法，可以在只改動env里面的寫操作流程就可以實現并發(fā)，無需其他改動。大概流程如下：
3.寫SST io size和讀SST IO size單獨設置
這個筆者還沒有仔細總結，應該調整FlushBlockBySizePolicy中的block size即可。但是合并過程中的SST 讀和業(yè)務的SST讀筆者認為還是有必要分別設置的，這里還沒有找到簡單合適的辦法。希望有讀者知道的可以不吝賜教。
- 流控策略優(yōu)化
筆者建議通過合理的帶寬來做流控，在系統(tǒng)上線之前通過存儲的性能及系統(tǒng)的寫放大合理分配前臺和后臺的帶寬。在我們的系統(tǒng)中，我通過前后臺的請求隊列深度來控制帶寬，基本上沒有觸發(fā)流控。不過由于僅僅是根據請求隊列而沒有更精細的流量控制，導致隊列滿時系統(tǒng)的性能還是會下降，但是比起原生的流控方式性能明顯更穩(wěn)定。后續(xù)還是希望能根據流量做流控。
不早了，先睡覺，明天繼續(xù)……
