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行记录的固定集合。
当我们插入10条记录后，再有新的插入时，最老的一条将会被剔除，看看如下效果：
查看以使用多少空间：
上 述 的 createCollection 函 数 也 可 以 用 来 创 建 一 般 的 collection , 还 有 一 个 参 数
"autoIndexID",值可以为"true"和"false"来决定是否需要在"_id"字段上自动创建索引。
如下：
db.createCollection('mycappc2',{capped:true,size:100000,max:10,autoIndexId:false})则表没有索引，对于写多读少的表非常合适
二、ＧridFS
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.1added file: { _id: ObjectId('5280bfc58bf9a82c5ba2abc4'), filename: "/tmp/testfile", chunkSize: 262144, uploadDate: new Date(1384169413607), md5: "21395b76d80f48cc069fa90d0c639513", length: 29 }done!#查看/usr/bin/mongofiles listconnected to: 127.0.0.1/tmp/testfile 29接下来我们进库里看一下是否有新的东西
字段说明:
Filename: 存储的文件名
chunkSize: chunks 分块的大小
uploadDate: 入库时间
md5: 此文件的 md5 码
length: 文件大小, 单位"字节"
看来 fs.files 中存储的是一些基础的元数据信息
其中比较重要的字段是"n",它代表的是 chunks 的序号,此序号从 0 开始,看来 fs.chunks
中存储的是一些实际的内容数据信息。
我们即然能将此文件存进去,我们就应该有办法将其取出来,下面看一下实例:
-校验 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});
