MongoDB实战（3）固定集合与GridFS-Coder

忧郁者

　　一、固定集合（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 中能够存放的最大文档数。但这时也要指

　　定>
　　可以使用 validate()查看一个 collection已经使用了多少空间,从而决定>　　下面我们创建一个集合：
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.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
　　接下来我们进库里看一下是否有新的东西

　　字段说明:
　　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});