GIT 儲存服務效能分析與優化

git 本質是一套內容定址 (content-addressable) 檔案系統, 但由於其將內容雜湊成乙個 sha 作為索引, 故也稱物件儲存或鍵值儲存(key-value-store).

現在很多產品都帶有歷史回退功能, 筆記產品尤為常見, 這也是非常重要的, 特別對於一些文字工作相關的, 經常會寫一些東西然後改來改去, 最後發現還是之前的寫的好, 這時想回退舊版本, 就必須記錄歷史.

git 有三類物件blob, tree, commit, 這三類會以檔案形式儲存在 git 根目錄下 objects 目錄中, 每個物件都會有個對應的索引雜湊值(sha), 雜湊值(sha) 幾乎等同於其檔名(前兩位為目錄, 後面部分為檔名).

檔案回退流程:

遍歷 commit 鏈, 選擇需要的版本提交點.

通過 commit 記錄的根tree索引, 獲取指定版本的檔案樹, 遞迴遍歷查詢指定檔案項

根據檔案項記錄的記錄的檔案索引去讀取檔案內容.

詳細原理分析可讀此篇文章: git 原理分析

index 檔案

以根tree為起點是可以遞迴獲取整個倉庫的檔案索引資訊的, 但每個tree都是乙個檔案, 通過tree去獲取會不停的讀檔案, 效能很差. 為此git 會將整個倉庫的檔案索引資訊單獨記錄在乙個index檔案中,

每次通過讀取index檔案內容來獲取整個倉庫的檔案記錄.

git 服務效能問題

由於git通過index檔案記錄倉庫的檔案資訊. 因此當倉庫的檔案數越多, index 檔案大小就越大, git 服務程式越佔記憶體. 同時由於要保證index檔案正確性, git 服務是沒法支援併發寫同乙個倉庫的多個檔案.

當併發寫多個倉庫的檔案時, 程式會同時載入多個倉庫的index檔案到記憶體. 而硬體內容是有限的, 因此index檔案大小也直接影響到併發寫多個倉庫的數量. 由此可見倉庫檔案數過多確實會影響git服務的效能.

git 本職功能是**管理, 若 git 服務僅用於**管的話, 其效能問題其實還好, 因為沒有併發寫同一倉庫的問題存在. 但是將 git服務作為普通的儲存服務, 那麼併發寫同一倉庫的可能性會很高(倉庫內容越多, 可能性也越高).

也許有人會說 git 不適合此種場景, 本文暫不討論此說法, 是建立 git 做儲存服務上討論. 解決 git 效能最好的辦法便是降低單倉庫的檔案數, 而作為普通的儲存服務關心的是單檔案的歷史, 並不關心整個倉庫的整體的歷史.

所以降低單倉庫的思路是可行的. 而降低單倉庫的檔案數又便於管理直接辦法便是:目錄即倉庫, 將所有目錄都初始化為倉庫, 同時限制單目錄(倉庫)的檔案數.