GridFS是一種將大型文件存儲在MongoDB的文件規范：
數據庫支持以BSON格式保存二進制對象。 但是MongoDB中BSON對象最大不能超過4MB。
GridFS 規范提供了一種透明的機制，可以將一個大文件分割成為多個較小的文檔。
為實現這點，該規范指定了一個將文件分塊的標準。每個文件都將在文件集合對象中保存一個元數據對象，一個或多個塊對象可被組合保存在一個塊集合中。
文件如何被分塊保存的細節可以參看GridFS Specification。
mongo自帶有一個實現mongofliles，基本操作如下：
列出所有文件：

mongofiles list

上傳一個文件：

mongofiles put xxx.txt

下載一個文件：

mongofiles get xxx.txt

查找文件：

mongofiles search xxx //會查找所有文件名中包含“xxx”的文件 mongofiles list xxx //會查找所有文件名以“xxx”為前綴的文件

參數說明：

–d 指定數據庫 ，默認是fs，Mongofiles list –d testGridfs -u –p 指定用戶名，密碼 -h 指定主機 -port 指定主機端口 -c 指定集合名，默認是fs // 這個好像不對 -t 指定文件的MIME類型，默認會忽略 //這個沒有測試過

原理：
GridFS在數據庫中，默認使用fs.chunks和fs.files來存儲文件。
1.fs.files集合存放文件的信息；
2.fs.chunks存放文件數據；

> show collections; fs.chunks fs.files system.indexes

fs.files集合包含了文件的元數據，而fs.chunks集合則存儲實際的以256KB尺寸進行分割的文件塊。如果你有分片的集合，那么文件塊會分布到多臺服務器上，或許能獲得比文件系統更好的性能。

> db.fs.files.findOne(); { "_id" : ObjectId("530cf1bf96038f5cb6df5f39"), "filename" : "./conn.log", "chunkSize" : 262144, "uploadDate" : ISODate("2014-02-25T19:40:47.321Z"), "md5" : "6515e95f8bb161f6435b130a0e587ccd", "length" : 1644981 }

MongoDB還在files_id和文件塊數中創建了復合索引，以幫助快速訪問這些文件塊

> db.fs.chunks.getIndexes(); [{ "v" : 1,"key" : { "_id" : 1 }, "ns" : "files.fs.chunks", "name" : "_id_" }, { "v" : 1, "key" : { "files_id" : 1, "n" : 1 }, "ns" : "files.fs.chunks", "name" : "files_id_1_n_1" } ] }

一個fs.files集合中的一條記錄內容如下，即一個file的信息如下：

{"_id" : ObjectId("4f4608844f9b855c6c35e298"), //唯一id，可以是用戶自定義的類型"filename" : "CPU.txt", //文件名"length" : 778, //文件長度"chunkSize" : 262144, //chunk的大小"uploadDate" : ISODate("2012-02-23T09:36:04.593Z"), //上傳時間"md5" : "e2c789b036cfb3b848ae39a24e795ca6", //文件的md5值"contentType" : "text/plain" //文件的MIME類型"meta" : null //文件的其它信息，默認是沒有”meta”這個key，用戶可以自己定義為任意BSON對象 }

對應的fs.chunks中的chunk如下：

{"_id" : ObjectId("4f4608844f9b855c6c35e299"), //chunk的id"files_id" : ObjectId("4f4608844f9b855c6c35e298"), //文件的id，對應fs.files中的對象，相當于fs.files集合的外鍵"n" : 0, //文件的第幾個chunk塊，如果文件大于chunksize的話，會被分割成多個chunk塊"data" : BinData(0,"QGV...") //文件的二進制數據，這里省略了具體內容 }

默認chunk的大小是256K:

public static final int DEFAULT_CHUNKSIZE = 256 * 1024;

寫入：

如果文件大于chunksize，則把文件分割成多個chunk，再把這些chunk保存到fs.chunks中，最后再把文件信息存入到fs.files中。
讀取:
先據查詢的條件，在fs.files中找到一個合適的記錄，得到“_id”的值，再據這個值到fs.chunks中查找所有“files_id”為“_id”的chunk，并按“n”排序，最后依次讀取chunk中“data”對象的內容，還原成原來的文件。

自定義Gridfs的hash函數：
盡管從理論上，無論用什么hash函數，都有可能出現hash值相同，但內容不相同的文件，但是對于GridFS默認使用的md5算法，目前已出現長度和md5值都相同但內容不一樣的文件。
如果想要自已改用其它hash算法，可以從驅動入手。因為GridFS在MongoDB中實際也只是兩個普通的集合，所以完全可以自已修改驅動，替換下hash算法即可。

注意事項：

GridFS不自動處理md5相同的文件，對于md5相同的文件，如果想在GridFS中只有一個存儲，要用戶自已處理。Md5值的計算由客戶端完成。

因為GridFS在上傳文件過程中是先把文件數據保存到fs.chunks，最后再把文件信息保存到fs.files中，所以如果在上傳文件過程中失敗，有可能在fs.chunks中出現垃圾數據。這些垃圾數據可以定期清理掉。

GridFS的模塊

如果你想把存儲在MongoDB的GridFS的文件直接服務于Web服務器或文件系統，那么你可以使用下面的GridFS插件：
1）GridFS-Fuse：讓GridFS的文件直接服務于文件系統
2）GridFS-Nginx：讓GridFS的文件直接服務于Nginx

GridFS的局限性

GridFS也并非十全十美的，它也有一些局限性：
1）工作集
伴隨數據庫內容的GridFS文件會顯著地攪動MongoDB的內存工作集。如果你不想讓GridFS的文件影響到你的內存工作集，那么可以把GridFS的文件存儲到不同的MongoDB服務器上。
2）性能
文件服務性能會慢于從Web服務器或文件系統中提供本地文件服務的性能。但是這個性能的損失換來的是管理上的優勢。
3）原子更新
GridFS沒有提供對文件的原子更新方式。如果你需要滿足這種需求，那么你需要維護文件的多個版本，并選擇正確的版本。

轉載于:https://www.cnblogs.com/weloveshare/p/5752000.html

總結

以上是生活随笔為你收集整理的mongodb--GridFS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。