華爲雲TaurusDB性能挑戰賽比賽記錄

原創

2020-06-17 06:01

華爲雲TaurusDB性能挑戰賽KV_Store_Engine_TaurusDB_Race

A C++ KV Store Engine (華爲雲TaurusDB性能挑戰賽，司機隊，初賽第11名，複賽第26名)
Github：https://github.com/chenshuaihao/KV_Store_Engine_TaurusDB_Race

Introduction

簡介：華爲雲TaurusDB性能挑戰賽，基於C++編寫的簡易KV數據庫存儲引擎。

比賽結果：初賽279.911s，複賽使用nanomsg：5270.72s，後期替換成asio庫後速度飛躍，但是線上一直有bug沒來得及debug，只跑出了寫入成績260-350s。

賽後感想：三個學生黨第一次參加這種工程類的比賽，接觸並學到了很多新東西，拿到這個排名已經很開心了。

團隊成員（排名不分先後）：
YohannLiang
Shuaihao Chen
Alan-Paul

目錄：
KV_Store_Engine_TaurusDB_Race_stage1 初賽代碼，計算/存儲不分離
KV_Store_Engine_TaurusDB_Race_stage1 複賽代碼，計算/存儲分離的設計，緩存設計。
進入對應的目錄，再編譯構建，具體可參見目錄下的readme

隨機寫入階段：
文件劃分：key文件、value文件、metadata文件；
KV寫入方式：KV均採用mmap緩衝區，保證kill -9後KV數據不丟失，所有key全部存mmap，value緩衝區湊夠16個value（參數可調）就刷盤；
key文件：16個測試線程各自對應一個key文件，set時候直接向key文件對應的mmap內存追加key數據；
value文件：採用DIO方式順序寫入，16個測試線程各自對應一個value文件，先寫入mmap緩衝區，湊夠16個value調用pwrite向文件追加數據；
metadata文件：保存元數據信息，用於數據恢復，具體保存了kill時候的文件偏移以及緩衝區已有value個數的信息
順序讀取階段：
線程模型：每個測試線程開啓18個存儲IO線程（生產者線程）在後臺運行，18個存儲IO線程各自對應4MB內存分區，分區加載value文件到內存緩衝區，這樣可以儘可能地打滿SSD的IO帶寬；
當測試線程get完當前分區數據後，喚醒對應的存儲IO線程加載新的分區數據，並開始get下一個分區數據，典型的生產者消費者模型；
索引：採用STL的map實現，但是由於順序讀取特徵，直接用計數器代替了。
隨機讀取階段：
華爲這次初賽中隨機讀取階段並不隨機，採用倒序讀的方式，所以思路和順序讀取一樣，只不過是存儲IO線程變成倒序加載文件分區而已；
待補充完善

計算節點：
思路：1.將存儲節點的索引構建、查找等過程分離到了計算節點執行，計算節點只需要傳遞偏移pos給store節點即可；
2.創建多個網絡IO線程分區向store發請求，加載數據到緩存；
網絡模型：爲了把網絡IO帶寬打滿，每個測試線程都開了n個網絡IO線程，向store端get請求數據，加載到計算節點的緩存中；
get讀取階段：16個線程首先向store請求各自文件的key，並行構建好16個索引（每個文件一個），然後遍歷16個hash索引，直到查找key對應的文件及其偏移pos；
索引部分：16個線程並行構建索引，爲了降低內存消耗，採用sparse_hash_map，內存佔用低，性能也較高；
網絡部分：開始使用nanomsg實現通信，可能我們使用方式不對，網絡性能很低，帶寬只用了一點，最後兩天才急忙替換成asio庫，速度瞬間提升，但是線上測評始終有點問題，結果來不及Debug了；
存儲節點：
思路：存儲節點的進程開了16個storeEngine實例，每個實例都有一個Server，每個實例各自負責維護自己的文件；
set：set後來改成異步落盤，採用雙緩衝區設計（可以改參數爲多緩衝區），一個後臺的存儲IO線程調用pwrite刷盤；
網絡部分：使用asio庫，參考asio例程實現服務器；
其他：其他地方與原來區別不大；
待補充完善

Enjoy!

發表評論

所有評論

還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.