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

2023-01-31 01:01:01 集合 固定 实战

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


相关文章