mongodb文档太大_在MongoDB中存储非常大的文档

简而言之:如果您有大量不同大小的文档,那么相对较少的文档达到最大对象大小,那么在MongoDB中存储这些文档的最佳做法是什么?

我有一组文件,如:

{_id: ...,

values: [12, 13, 434, 5555 ...]

}

值列表的长度因文档的不同而异 . 对于大多数文档来说,它会有一些元素,少数元素会有数千万个元素,我将在MongoDB中达到最大对象大小限制 . 麻烦是我提出的任何特殊解决方案,因为那些非常大(而且相对较少)的文档可能会影响我如何存储小文档,否则这些文档会在MongoDB集合中幸福地生活 .

据我所知,我有以下选择 . 我将不胜感激任何关于这些的优点和缺点的输入,以及我错过的任何其他选项 .

1)使用另一个数据存储:这似乎太激烈了 . 我喜欢MongoDB,并不像我达到许多对象的大小限制 . 在单词的情况下,我的应用程序可以不同地处理非常大的对象和其他对象 . 它似乎并不优雅 .

2)使用GridFS存储值:像传统数据库中的blob一样,我可以保留文档中前几千个值的元素,如果列表中有更多元素,我可以将其余的元素保存在GridFS对象中二进制文件 . 我无法在这部分进行搜索,但我可以忍受这一点 .

3)滥用GridFS:我可以将每个文档保存在gridFS中 . 对于大多数(小)文档,二进制块将为空,因为文件集合将能够保留所有内容 . 其余的我可以将多余的元素保留在块集合中 . 与选项#2相比,这是否会带来开销?

4)真的滥用GridFS:我可以使用GridFS的文件集合中的可选字段来存储值中的所有元素 . GridFS是否也为文件集合进行智能分块?

5)使用额外的“关系”集合来存储一对多关系,但此集合中的许多文档很容易超过一千亿行 .

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值