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