為什么我們要用分布式文件系統（經歷后的感觸）

1、為何散布式文件系統要采取特定的組織結構來存儲文件？

直接依照文件的原始路徑進行存儲和復制，這樣就能夠直接通過利用服務進行靜態化訪問，從而大幅度提升性能。怎樣樣，這個主張不錯吧？

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

       這樣的1個系統，大概是1個同享文件系統?或是1個文件分發系統。

如果只是同享文件系統，文件太多了怎樣辦？文件訪問壓力太大了怎樣辦？文件丟失了怎樣辦？文件錯了怎樣辦？文件服務器掛了怎樣辦？

       怎樣辦，怎樣辦，怎樣辦？

       沒有那末多怎樣辦，所以我們在經歷過這些實踐和使用以后，結論就是，用散布式文件系統，就這么辦。

2、散布式文件系統能夠幫我們做甚么（優點）

可以組建包括大量便宜服務器的海量存儲系統，這是文件分發和同步不容易做到的；

通過內部的冗余復制，保證文件的可用性，在海量存儲系統中，容錯能力非常非常重要；

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

在多個文件副本之間就進行負載均衡，可以通過橫向擴大來確保性能的提升。

進行特定的索引文件的計算等；

…

3、散布式文件系統的不足或說缺點

低延時訪問

散布式文件系統不太合適于那些要求低延時（數10毫秒）訪問的利用程序，由于散布式文件系統是設計用于海量數據處理的，這是以1定延時為代價的。對低延時訪問，經典和傳統的辦法就是數據庫，我們所愛好的ORACLE就很善于干這個事情。

       比如1個支付系統，對它的核心支付體系，后端用P590小型機+ORACLE，當支付的范圍愈來愈大的時候。小型機+ORACLE的支付體系會非常痛苦。對數據庫橫向擴大，水平切分都是方法，但是直接想把核心支付模塊切換到散布式文件系統上，確切有挑戰，當年沒有成功過。（1家之言，說不定你們能弄定，僅供參考）

頻繁修改的文件的利用

       目前經常使用的散布式文件系統，基本都是“1次寫屢次讀”的模式，如果觸及到大量數據的頻繁修改，那末這個問題就相對照較麻煩；

海量小文件

散布式文件系統把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是有限的。1般來講，每個文件、文件夾和Block需要占據150字節左右的空間，所以，如果你有100萬個文件，每個占據1個Block，你就最少需要300MB內存。當前來講，數百萬的文件還是可行的，當擴大到數10億時，對當前的硬件水平來講就很痛苦了。因此由于海量元數據的因素，散布式文件系統對待海量小文件相對照較乏力。

其他

1些直接通過http訪問的文件，比如腳本、CSS等。

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

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈