1秸弛、概述
? ????? GridFS是基于mongodb存儲引擎是實現(xiàn)的“分布式文件系統(tǒng)”医咨，底層基于mongodb存儲機制构舟，和其他本地文件系統(tǒng)相比灰追，它具備大數(shù)據(jù)存儲的多個優(yōu)點堵幽。GridFS適合存儲超過16MB的大型文件，不過16M數(shù)據(jù)在當今互聯(lián)網(wǎng)時代弹澎，已經(jīng)不足為奇朴下。我們可以使用GridFS構(gòu)建大規(guī)模的“圖片服務器”、“文檔服務器”苦蒿、“視頻殴胧、音頻”文件服務器，GridFS對于web應用佩迟，可以結(jié)合nginx插件“ningx-gridfs”能夠簡單的實現(xiàn)負載均衡等特性团滥，非常便捷；可以簡單認為GridFS是為web應用而生报强。個人認為灸姊，目前架構(gòu)比較簡單的NoSQL文件系統(tǒng)中GridFS是最優(yōu)秀的。
? ? ????GridFS并不是將單個文件直接存儲為一個document秉溉，而是將文件分成多個parts或者說chunks力惯，然后將每個chunk作為作為一個單獨的document存儲，然后將chunks有序保存召嘶。默認情況下父晶，GridFS的chunk大小位255k。GridFS使用2個collections來存儲這些文件弄跌，一個collection存儲文件的chunks（實際文件數(shù)據(jù)）甲喝，另一個則存儲文件的metadata（用戶自定義的屬性，filename铛只，content-type等）俺猿。
? ????? 當用戶查詢GridFS中的文件時，客戶端或者driver將會重新按序組裝這些chunks格仲。用戶可以range查詢文件押袍，也可以獲取文件的任意部分的信息，比如：跳過（skip）視頻或者音頻（任何文件）的中間部凯肋，實現(xiàn)“range access of single file”谊惭。
????????對于mongodb而言，每個document最大尺寸為16M侮东，如果想存儲一條數(shù)據(jù)（比如一個文件）超過16M圈盔，那么只能使用GridFS支持；GridFS可以支持單個文件尺寸達到數(shù)G悄雅，讀取文件時可以分段讀取驱敲。此外，GridFS可以從Mongodb的高性能宽闲、高可用特性中獲益众眨，比如我們可以在“replica set”或者“sharding”架構(gòu)模式下使用GridFS握牧。
2、使用場景
????????document的大小超過16M是使用GridFS的條件之一娩梨，因為mongodb普通的collection無法支持16M以上的document沿腰，我們不得不選擇其他方案；在一些情況下狈定，將這些大文件存儲在GridFS中颂龙，比直接存儲在本地文件系統(tǒng)中更加適合：
????????1）如果你的文件系統(tǒng)對每個目錄下文件的個數(shù)有限制（或者太多，將會影響文件的打開速度等）纽什。
????????2）如果你的文件數(shù)據(jù)措嵌，有分數(shù)據(jù)中心鏡像保存（大數(shù)據(jù)情況，可用性保證）芦缰。
????????3）如果你希望訪問一個超大的文件企巢，而不希望將它全部加入內(nèi)存，而是有“range access”的情況饺藤，即分段讀取包斑，那么GridFS天生就具備這種能力流礁，你可以隨意訪問任意片段涕俗。
? ? 對于一個大文件，如果你希望原子性的更新它的全部內(nèi)容神帅，那么GridFS將不適合再姑；比如同時更新一個文件的多個chunk，因為mongodb本身沒有事務機制找御。
????????對于小于16M的文件元镀，比如一些圖片、CSS霎桅、js文件等栖疑，應該將它們直接存儲在普通的collection中而非GridFS（bindata，參見org.bson.types.Binary）滔驶，因為它們通常較小遇革，GridFS無法發(fā)揮其優(yōu)勢。當然揭糕，你為了統(tǒng)一application的“文件系統(tǒng)”存儲方式萝快，也可以將這些小文件保存在GridFS中，性能也不會差的太多著角，為了提升性能揪漩，對這些小文件，可以在存儲時手動設置它的chunkSize吏口，避免文件被切分成多個chunks來提高性能奄容。
? ? ? ? 另外冰更，如果你的數(shù)據(jù)庫不用MongoDB，那么不用為了做大文件存儲而選擇MongoDB嫩海，MongoDB畢竟不是專門做分布式文件存儲的冬殃，使用GridFS只不過是為了性能要求不是太高的情況下，統(tǒng)一存儲架構(gòu)而做出的選擇叁怪。專業(yè)的分布式文件存儲最好還是選擇FastDFS审葬。
