業界在大數據量存儲方面存在著兩種解決方案：集中式存儲和分布式存儲。
集中式存儲的代表廠商：NetApp，EMC，使用集中式存儲的互聯網代表企業Facebook；
分布式存儲的代表廠商兼互聯網企業：google。
集中式存儲相比分布式存儲最大的問題在於購置整個解決方案的成本太高。而分布式存儲可以通過軟件技術整合利用眾多低廉的存儲設備，來支撐海量的存儲，最大的問題在於研發門檻和成本高。
原型選擇
針對目前的文件系統業務場景虛擬機存儲。多部分都是小文件存儲，將來擴展也是往
數據庫、日志存儲。符合這樣的基礎場景可以有如下的篩選條件：
1）可擴展性；
能動態擴展結點，單個存儲結構支持上億數量級的存儲；最好能避免meta data的單點故障和存儲限制問題；
2）高可用性；
支持repli
cation，實現數據的自動復制和結點的failover；replication在高並發時也可分減單台存儲設備IO；
3）可管理性；
能方便地管理存儲結點的增刪和配置策略更改，變更生效無需中斷服務；（弱管理性可通過定制啟動器來加強）
4）可維護性；
要有良好的社區支持和發展前景，最好有明確的Roadmap。
5）性能；
吞吐量越大越好。前提條件是要能夠符合當前的業務需求。
6）成功案例；
是否有成功的商業案例，尤其是大型互聯網公司的（國內大的互聯網公司基本上都是自己實現小文件存儲）；
7）可選：Stripe功能，適合於存儲大文件；分布式計算，適合於日志分析；
3. 可選擇的方案
從開源中國分布式文件存儲列表的30多個項目中，用上述的標准進行了初步的分析和篩選。最後被保留下來進行進一步分析的候選項目有：
1）Hadoop+SeqFile（MapFile）；
2）SheepDog；
3）Lustre；
4）Cassandra；
5）MooseFS；
6）GlusterFS；
7）XtreemFS；
8）KFS；
接下來，我們對以上的這幾個項目分別進行了深入了解和分析，排除了以下一些項目：
1）Hadoop+SeqFile（MapFile）；
根據之前對Hadoop做的測試，NameNode是Hadoop最大的一個瓶頸，所以試圖通過把小文集聚合存儲的方式來解決NameNode的瓶頸問題。而在實驗中發現Hadoop目前支持的append是有很大的局限性的，文件的append是建立在write once的基礎上的，也就是說一個創建的文件被關閉後就不能再續寫。所以Hadoop+SeqFile的方式走不通。
2）SheepDog；
一個非常雛形的項目，部署跟操作系統支持緊密結合，缺乏文檔、社區支持和商業案例；
3）Lustre；
Lustre同樣存在master單點，但使用nas/san來解決了metadata的單點問題，但是依賴於硬件，另外Lustre的部署需要往linux內核中增加許多自己的模塊，安裝部署過程過於復雜。其主要的應用場景也是實驗室。缺乏成功的商業案例。
4）Cassandra；
增刪結點會引起存儲數據的移動；同時文件的replication需要被寫入文件先完整緩存在內存中，在並發量大時有可能引起內存溢出。
5）MooseFS；
MooseFS的metadata使用內存加載整個文件系統的meta信息，使用鏡像文件和editlog來持久化存儲，跟Hadoop的metadata存儲機制非常相似，Metadata存在擴展的瓶頸；
6）KFS；
Metadata存在瓶頸問題，文檔極其稀缺，社區支持比較薄弱。目前在sourceforge上還是alpha版。未有顯著的商業案例。
最後候選的項目剩下：
1） GlusterFS；
特點：無Metadata結點，不存在單點失敗的問題，不存在容量擴展的瓶頸問題，可支持上PB級的數據；有較多的成功案例，社區支持和發展勢頭很好；
Replication、Stripe、DHT等功能模塊化，能根據需要靈活配置、組合。
優點：下載的性能表現出色，文件大小從300K增長到3M對速度幾乎沒有影響；
缺點：
1） GlusterFS跟JAVA的文件操作不是很兼容，在配置了備份功能的場景下，存在數據一致性的安全隱患。若客戶端在使用JAVA刪除文件時，某存儲結點宕機，當宕機結點重新起來，被刪除的數據會再次被生成；
2） GlusterFS的可管理性很差，增刪結點需要修改配置，同時客戶端需要短暫中斷服務進行目錄的mount和
umount
3） 文件上傳不夠穩定，存在間歇性停頓的問題，即使只是單線程訪問；
4） 上傳耗時跟備份數成正比，且在高並發下效率很差，如 300K文件200個並發下，上傳需要27s。同一條件下FastDFS只需要2s；
2） XtreemFS；
特點：增加了一個角色DIR，與metedata數據存儲角色（MRC）區分，用於管理結點的注冊、剔除等。MRC可冗余可分割，DIR可冗余（當前版本未實現）。
如此一來既避免了Hadoop/MooseFS類存儲系統的metadata瓶頸和單點問題，也避免了GlusterFS的可管理性差問題。
優點：提供了便捷詳盡的服務器狀態監控界面，提供了方便的配置策略操作命令。
缺點：
1）性能表現較差，且隨著並發數增加或文件大小增加，上傳下載速度有明顯下降，舉例，300K單線程上傳需要450ms，而FastDFS只需要12ms；3m單線程上傳需要接近6s，而2m單線程FastDFS只需要62ms。
2）多個備份，停止其中一個osd後，上傳下載都不成功；
3）客戶端操作命令常有死鎖現象，死鎖進程甚至有kill -9仍然無法停止，很不穩定；
綜合 測試結論可以嘗試一下：FastDFS 。
