如何構建下一代去中心化雲存儲
這個問題是4年前創業時提出的， 因為技術問題以及商業模式問題，一直沒有成功， 現在復盤整個心路過程，不是嚴肅的專業論文，權當聽故事。
在2013年， 當時阿里雲OSS存儲價格在1900元/TB/年， 成本價格高於（TFS成本）4000元，考慮到未來海量的數據需求， 存儲成本是一個不斷累積增長的成本， 任何公司都很難承受，就有了利用閑置設備做分散式存儲的想法！
基本想法是利用路由器、OTT機頂盒的存儲空間，構建一個分散式的可靠存儲體系， 每個設備的存儲空間不大，但長尾設備的數量巨大， 通過冗餘思想能對抗設備的不穩定性、在線率低等困難。
這個想法告訴了小米，於是有了小米路由器加一塊硬碟的產品出現。但顯然，小米並沒有理解分散式存儲的思想， 只是充分利用當時的技術， 加一塊硬碟做了本地存儲管理，當然商業價值還是有的。
先說說這個利用長尾資源做存儲的技術問題吧，這是一個世界級的挑戰。
每個設備假定只有1GB存儲空間， 共有 100萬同時在線設備， 這樣總存儲空間為1000TB。
假定我們存儲一個1GB的文件， 首先把文件分成1024個1MB的Chunk， 每個chunk在分成1024個1KB的piece， 對每個chunk的1024個piece 進行編碼， 這樣假設可以生成2048個完全不同的piece, 我們需要把這2048個pieces 放在2048個節點上。對1024個chunk 進行同樣的操作， 這樣我們可以在每個節點上存儲1024片piece， 但每個chunk 只保存一份， 這樣，每個節點只存儲 1GB原始文件的1MB數據量。 整個文件在2048個節點上有，數據冗餘量為2倍。
為了恢復這些數據， 從2048個節點中隨機取出1024個節點的數據即可恢復。
這就是去中心化存儲的基礎！ 但實現上述系統有著巨大的挑戰：
- 海量節點對中心伺服器的心跳衝擊
- 如果去掉中心存儲服務的備份，這個存儲系統必須可靠， 快速發現數據冗餘不夠是關鍵
- 發現冗餘不夠之後，快速修復是關鍵中的關鍵
- 安全
第一個問題是工程問題， 只能硬扛。
第二個問題， 可以分組來解決。
第三個問題，涉及到存儲的最核心問題，已經不是工程能高效解決了。分散的數據已經用噴泉編碼演算法進行了編碼， 如果只有這個編碼演算法， 則需要把數據恢復之後在重新編碼，然後在推送到新的設備節點上， 這樣修復成本就太高了。 而存儲中修復成本是有指標衡量的， 就是修復佔用的計算量及被修複數據量的百分比。 如果重新解碼在編碼，修復成本就是原始數據量的200%。 如果噴泉編碼能再次被編碼， 而且能生成原始噴泉編碼的域空間內， 則數據就能像基因複製一樣，用最小代價在節點間自由遷移，那就完美了， 這樣整個存儲系統甚至網路的架構就被完全顛覆！
這個技術就叫再生碼（regeneration code) , 我們首次提出再生碼在這個場景下應用, 藉助這個思想， 成功的獲得1000萬美元投資.
但再生碼的構造太困難了， 我們尋求復旦大學及香港大學頂級編碼專家研究這個問題，但只能構造O(n^2)的演算法， 而且還不知道結果是否正確， 難點在於這個矩陣構造必須稀疏，但兩個稀疏矩陣的運算得到的結果不稀疏，在工程上不可行，性能太差了，工程上必須達到O(n)。 這個問題留給科學家吧！
最終我們沒有選擇這個方向來做（現在想法有變化，但場景已不一樣），主要有如下的考慮：
- 單碟存儲能力在指數上升， 目前單硬碟容量已有120TB， 這樣導致集中式雲存儲的成本下降非常快
- 在2014年就知道了Facebook的雲存儲成本降到了400/TB/年，也就是說雲存儲的margin越來越低
- 雲存儲的的系統瓶頸在內部數據恢復的IO上， 集中式雲存儲在內部通訊上有巨大優勢，瓶頸不在存儲的容量上
- 去中心化雲存儲部署在每個小設備上，每個設備上行帶寬非常小， 導致數據通信及恢復很慢，效率比較低，而且為了對抗設備的不穩定性， 系統開銷也變大，冗餘倍數增加
- 在不安全的設備上做存儲， 很難消除客戶的顧慮， 安全性受到挑戰， 教育市場任重道遠。
總的來說，margin越來越低， 而且技術挑戰性太大， 不是一個很性感的生意。 但反過來說， 可能是切入點不對， 如果這麼好的技術，硬要去取代傳統的雲存儲， 是否是一個錯誤的想法？ 是否有適合霧計算的場景出現， 特別適合這種去中心化的雲存儲體系。 所以說不能單純技術思維去考慮商業問題。 每個創新一定有他合適的場景，只是沒有認識到罷了。
===========================
未完待續
推薦閱讀：
