Git-annex
最近幫客戶測試了大型檔案(>1G)放到Subversion與Git的效能問題, Git確實比Subversion快, 但是快的並是很讓客戶滿意, 觀察到了Git將檔案放到Local Repository會做
- 檢查檔案內容與上次版本的差異-->Git並不是存放每個版本的實體, 而是內容的差異部分, Binary檔案也是一樣, 所以這個動作鐵定會吃CPU的資源
- 存放到Local Repository前會先壓縮(壓縮比大約1:10)-->這個也是會吃CPU的資源
- Local Repository存放與log處理--> 如果只存放差異部份與做壓縮, 這部份Disk I/O並部會很慢
所以從以上3個程序, 將大型的檔案要做版本控制, 無論是Git或是用Subversion, 都會很慢, 所以用Google找了一些相關資源, 找到了這一篇http://stackoverflow.com/questions/540535/managing-large-binary-files-with-git, 從這個討論, 裡面有分享一個Open Source叫git-annex , 這個git的延伸功能, 專門處理要使用Git來做大型檔案的版本控制, 像ISO image, VM image, Video檔案等等. 而且與Git repository完全相容. 簡單摘要這個git-annex的功能
- git annex必須設定一個remote的storage, 這個remote storage就是用來存放大檔案的位置, 其存放格式使用key-value, 這個key應該就是git的revision, value是檔案的存放位置
- 當大檔案要進git repository, 必須用git annex來操作, 如git annex add, git annex commit
- 大檔案存放在git repository只是一個symbolic link告訴git annex真正的對應版本檔案放在哪裡
- 使用git annex commit的時候, 就省去了檔案內容比較, 與壓縮的時間, 但是要將檔案放到annex remote storage
- git annex remote storage支援許多, 例如目錄(可以指到外部磁碟), rsync, Amazon S3 等等
從Git annex的操作說明, 可以看出, Git annex省去了CPU時間, 但是Disk I/O可沒有省掉, 真的是有一好沒兩好, 不過目前Disk I/O可靠Raid 0 or SSD來提升應該不是太大問題, Git annex我看到還有一些缺點
- 安裝非常困難, Git annex使用The Haskell Platform開發, 不是每個Linux版本都有支援, 要自己編譯source code, 遇到許多dependency的問題, 所以建議使用Git annex已經支援的OS版本套件安裝
- 每個Client都要可以mount or 存取git annex所指定的remote storage, 不然checkout後的大檔案只是個link
- 目前還沒支援git annex checkout功能, 這對要checkout某特定revision, 會是個很惱人的問題
不過克服以上缺點, Git annex卻是很有企圖心要解決這種大型檔案版本控制的效能問題, 從Git annex身上可以看到git的瓶頸出在什麼地方. 不過也許Linus會說, Git原本就是用來管source code而不是big file的版本控制:-)
One more thing
筆者前幾年認識一位印度的工程師, 他是WANdisco的前CTO, 後來也發生類似Steve Jobs的故事, WANdisco其實是他創立的, 後來請了一位很會賣產品的人當CEO, 沒多久他離開了WANdisco, 他的個性很好, 但是那個WANdiso CEO可就不怎麼好相處了:-), 這位印度朋友後來開了一家公司叫http://www.evolphin.com/ 專門做大型檔案的版本控制, 據說其效能非常好, 他的客戶都是電影公司或是數位內容的多媒體公司, 電影剪接也是需要版本控制. 他的Solution還可比對每個版本的剪接改了哪些地方, 為何說起這個故事? 其實企業解決方案都有對應的商業軟體, 我在這個業界常看到很多公司為了省成本, 沒有用對的工具去正確解決問題, 而是在有問題的架構上修補, 其實最後並沒有省到money. Git, SVN這種工具原本就是用來管source code, 但是很多公司也用來管數位影像檔, 這個performance不好, 實在不能怪Git , SVN
留言