LSM樹是針對(duì)寫友好的，但是Rocksdb在實(shí)現(xiàn)時(shí)有很多地方的代碼不能充分發(fā)揮底層存儲(chǔ)的性能慨灭。比如：
? 單線程寫WAL，寫WAL的IO size上限寫死為65536字節(jié)岖免，不利于做IO聚合；
? 讀sst和寫sst的IO size設(shè)置為相同的照捡，寫速度的加快需要加大寫的io size颅湘，這樣做反過來又降低了讀的效率，因?yàn)樽x同一個(gè)kv需要從盤上讀更大的block栗精；
? 寫大的value時(shí)沒有將kv分離闯参，而是將kv一起都存到WAL和SST，造成寫放大不說悲立，后臺(tái)合并的數(shù)據(jù)量巨大帶來的帶寬和CPU及內(nèi)存占用對(duì)前臺(tái)的性能影響非常大鹿寨，常常導(dǎo)致劇烈的性能抖動(dòng)和性能降低。
? 所有的讀寫都是同步方式薪夕，導(dǎo)致寫wal和寫sst都不能并發(fā)脚草，不能充分發(fā)揮盤的帶寬。
? 當(dāng)前的流控策略根據(jù)內(nèi)存占用和后臺(tái)level0層文件的個(gè)數(shù)和體積來減緩或者停止前臺(tái)IO原献，這種方式導(dǎo)致了劇烈的性能抖動(dòng)馏慨。
筆者在HDD/NVME SSD/Ceph Rados上分別測(cè)試過Rocksdb的性能，這三者的同步寫性能分別是(170MB/s, 1200GB/s, 120MB/s)姑隅。不過最終的測(cè)試結(jié)果卻讓人大跌眼鏡写隶， Rocksdb的性能分別為(<1MB/s, 50MB/s, 4MB/s)，最多只能發(fā)揮存儲(chǔ)側(cè)的%5性能讲仰。根據(jù)測(cè)試結(jié)果和以上的5點(diǎn)分析慕趴，筆者整理了一下我們系統(tǒng)中的優(yōu)化方式，希望能給大家?guī)椭Ｅ蹋蚕Ｍ蠹夷芙o我們提出一些更好的優(yōu)化建議秩贰。
- 寫WAL size動(dòng)態(tài)調(diào)整
當(dāng)前的寫io大小上限為65536，不能動(dòng)態(tài)調(diào)整柔吼；筆者通過對(duì)log格式稍作修改毒费，將請(qǐng)求的上限擴(kuò)展到4GB。具體修改方式就不具體介紹了愈魏，修改log_reader/log_writer中的編解碼方式即可觅玻。 - 并發(fā)寫WAL優(yōu)化
而且各個(gè)寫請(qǐng)求串行執(zhí)行，不能并發(fā)培漏，這導(dǎo)致了寫的效率很低溪厘。筆者曾經(jīng)考慮將WAL做分核，每個(gè)寫都寫到當(dāng)前核上牌柄，無奈這種方法對(duì)寫流程改動(dòng)太大畸悬，同時(shí)還影響到flush, load, transaction流程，所以遲遲沒能動(dòng)手珊佣。后來我想到了一種簡(jiǎn)單辦法蹋宦，可以在只改動(dòng)env里面的寫操作流程就可以實(shí)現(xiàn)并發(fā)披粟，無需其他改動(dòng)。大概流程如下：
3.寫SST io size和讀SST IO size單獨(dú)設(shè)置
這個(gè)筆者還沒有仔細(xì)總結(jié)冷冗，應(yīng)該調(diào)整FlushBlockBySizePolicy中的block size即可守屉。但是合并過程中的SST 讀和業(yè)務(wù)的SST讀筆者認(rèn)為還是有必要分別設(shè)置的，這里還沒有找到簡(jiǎn)單合適的辦法蒿辙。希望有讀者知道的可以不吝賜教拇泛。
- 流控策略優(yōu)化
筆者建議通過合理的帶寬來做流控，在系統(tǒng)上線之前通過存儲(chǔ)的性能及系統(tǒng)的寫放大合理分配前臺(tái)和后臺(tái)的帶寬思灌。在我們的系統(tǒng)中俺叭，我通過前后臺(tái)的請(qǐng)求隊(duì)列深度來控制帶寬，基本上沒有觸發(fā)流控习瑰。不過由于僅僅是根據(jù)請(qǐng)求隊(duì)列而沒有更精細(xì)的流量控制绪颖，導(dǎo)致隊(duì)列滿時(shí)系統(tǒng)的性能還是會(huì)下降，但是比起原生的流控方式性能明顯更穩(wěn)定甜奄。后續(xù)還是希望能根據(jù)流量做流控柠横。
不早了，先睡覺课兄，明天繼續(xù)……
