MongoDB實戰(3)固定集合與GridFS

一、固定集合(Capped Collection)

capped collections 是性能出色的有着固定大小的集合,以 LRU(Least Recently Used 最近最少使用)規則和插入順序進行 age-out(老化移出)處理,自動維護集合中對象的插入順序,在創建時要預先指定大小。如果空間用完,新添加的對象將會取代集合中最舊的對象。
可以插入及更新,但更新不能超出 collection 的大小,否則更新失敗。不允許刪除,但是可以調用 drop() 刪除集合中的所有行,但是 drop 後需要顯式地重建集合。


常見用處:

1、 logging
MongoDB 中日誌機制的首選,MongoDB 沒有使用日誌文件,而是把日誌事件存儲在數
據庫中。在一個沒有索引的 capped collection 中插入對象的速度與在文件系統中記錄日
志的速度相當。
2、 cache
緩存一些對象在數據庫中,比如計算出來的統計信息。這樣的需要在 collection 上建立
一個索引,因爲使用緩存往往是讀比寫多。
3、 auto archiving
可以利用 capped collection 的 age-out 特性,省去了寫 cron 腳本進行人工歸檔的工作。

推薦用法:

1、 爲了發揮 capped collection 的最大性能,如果寫比讀多,最好不要在上面建索引,否則
插入速度從"log speed"降爲"database speed"。
2、使用"nature ordering"可以有效地檢索最近插入的元素,因爲 capped collection 能夠保證
自然排序就是插入時的順序,類似於 log 文件上的 tail 操作。

實際案例:

可以在創建 capped collection 時指定 collection 中能夠存放的最大文檔數。但這時也要指
定 size,因爲總是先檢查 size 後檢查 maxRowNumber。
可以使用 validate()查看一個 collection已經使用了多少空間,從而決定 size 設爲多大。

下面我們創建一個集合:

db.createCollection('mycappc1',{capped:true,size:100000,max:10})

這是一個最多10行記錄的固定集合。

151830737.png

當我們插入10條記錄後,再有新的插入時,最老的一條將會被剔除,看看如下效果:

152138817.png

查看以使用多少空間:

191757534.png

上 述 的 createCollection 函 數 也 可 以 用 來 創 建 一 般 的 collection , 還 有 一 個 參 數
"autoIndexID",值可以爲"true"和"false"來決定是否需要在"_id"字段上自動創建索引。

如下:

db.createCollection('mycappc2',{capped:true,size:100000,max:10,autoIndexId:false})

則表沒有索引,對於寫多讀少的表非常合適

192109530.png


二、GridFS

GridFS 是一種將大型文件存儲在 MongoDB 數據庫中的文件規範。
由於 MongoDB 中 BSON 對象大小是有限制的,所以 GridFS 規範提供了一種透明的機制,可
以將一個大文件分割成爲多個較小的文檔,這樣的機制允許我們有效的保存大文件對象,
特別對於那些巨大的文件,比如視頻、高清圖片等。

GridFS 使用兩個表來存儲數據:
files 包含元數據對象
chunks 包含其他一些相關信息的二進制塊
爲了使多個 GridFS 命名爲一個單一的數據庫,文件和塊都有一個前綴,默認情況下,前綴
是 fs,所以任何默認的 GridFS 存儲將包括命名空間 fs.files 和 fs.chunks。各種第三方語言的
驅動有權限改變這個前綴,所以你可以嘗試設置另一個 GridFS 命名空間用於存儲照片,它
的具體位置爲:photos.files 和 photos.chunks。下面我們看一下實際的例子吧。
這裏使用命令行工具

/usr/bin/mongofiles put /tmp/testfile
#結果如下
connected to: 127.0.0.1
added file: { _id: ObjectId('5280bfc58bf9a82c5ba2abc4'), filename: "/tmp/testfile", chunkSize: 262144, uploadDate: new Date(1384169413607), md5: "21395b76d80f48cc069fa90d0c639513", length: 29 }
done!
#查看
/usr/bin/mongofiles list
connected to: 127.0.0.1
/tmp/testfile   29

接下來我們進庫裏看一下是否有新的東西
193542269.png

字段說明:
Filename: 存儲的文件名
chunkSize: chunks 分塊的大小
uploadDate: 入庫時間
md5: 此文件的 md5 碼
length: 文件大小, 單位”字節”
看來 fs.files 中存儲的是一些基礎的元數據信息

193700268.png

其中比較重要的字段是”n”,它代表的是 chunks 的序號,此序號從 0 開始,看來 fs.chunks
中存儲的是一些實際的內容數據信息。

我們即然能將此文件存進去,我們就應該有辦法將其取出來,下面看一下實例:
194359896.png

-校驗 md5,結果跟庫裏相同
db.fs.chunks.ensureIndex({files_id:1, n:1}, {unique: true});
這樣,一個塊就可以利用它的 files_id 和 n 的值進行檢索。注意,GridFS 仍然可以用 findOne
得到第一個塊,如下:
db.fs.chunks.findOne({files_id: myFileID, n: 0});
194745561.png


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章