MongoDB实战（3）固定集合与Gri

一、固定集合（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

二、Ｇ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

接下来我们进库里看一下是否有新的东西

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