1、為什麼分散式檔案系統要採用特定的組織結構來儲存檔案？

直接按照檔案的原始路徑進行儲存和複製，這樣就可以直接通過應用服務進行靜態化訪問，從而大幅度提升效能。怎麼樣，這個主意不錯吧？

等等，我們好像又繞回去了…..

這樣的一個系統，大概是一個共享檔案系統?或者是一個檔案分發系統。

如果只是共享檔案系統，檔案太多了怎麼辦？檔案訪問壓力太大了怎麼辦？檔案丟失了怎麼辦？檔案錯了怎麼辦？檔案伺服器掛了怎麼辦？

怎麼辦，怎麼辦，怎麼辦？

沒有那麼多怎麼辦，所以我們在經歷過這些實踐和使用之後，結論就是，用分散式檔案系統，就這麼辦。

2、分散式檔案系統能夠幫我們做什麼（優點）

可以組建包含大量廉價伺服器的海量儲存系統，這是檔案分發和同步不容易做到的；

通過內部的冗餘複製，保證檔案的可用性，在海量儲存系統中，容錯能力非常非常重要；

可擴充套件性很強，增加儲存節點和追蹤器都比較容易；

在多個檔案副本之間就進行負載均衡，可以通過橫向擴充套件來確保效能的提升。

進行特定的索引檔案的計算等；

…

3、分散式檔案系統的不足或者說缺點

低延時訪問

分散式檔案系統不太適合於那些要求低延時（數十毫秒）訪問的應用程式，因為分散式檔案系統是設計用於海量資料處理的，這是以一定延時為代價的。對於低延時訪問，經典和傳統的辦法就是資料庫，我們所喜愛的ORACLE就很擅長幹這個事情。

比如一個支付系統，對於它的核心支付體系，後端用P590小型機+ORACLE，當支付的規模越來越大的時候。小型機

頻繁修改的檔案的應用

目前常用的分散式檔案系統，基本都是“一次寫多次讀”的模式，如果涉及到大量資料的頻繁修改，那麼這個問題就相對比較麻煩；

海量小檔案

分散式檔案系統把檔案系統的元資料放置在記憶體中，所以檔案系統所能容納的檔案數目是有限的。一般來說，每一個檔案、資料夾和Block需要佔據150位元組左右的空間，所以，如果你有100萬個檔案，每一個佔據一個Block，你就至少需要300MB記憶體。當前來說，數百萬的檔案還是可行的，當擴充套件到數十億時，對於當前的硬體水平來說就很痛苦了。因此由於海量元資料的因素，分散式檔案系統對待海量小檔案相對比較乏力。

其他

一些直接通過http訪問的檔案，比如指令碼、CSS等。

要進行復雜的計算，比如計算要發射火箭到火星上去，順便在宇宙飛船上要配置一桌麻將，需要計算有多少的能力，要有多少的著力點；