【发布时间】：2012-06-26 07:33:50
【问题描述】：
简而言之：如果您有大量不同大小的文档，而达到最大对象大小的文档相对较少，那么将这些文档存储在 MongoDB 中的最佳实践是什么？
我有一组文件，例如：
{_id: ...,
values: [12, 13, 434, 5555 ...]
}
值列表的长度因文档而异。对于大多数文档来说，它会有几个元素，对于少数几个来说，它会有数千万个元素，而且我会达到 MongoDB 中的最大对象大小限制。问题是我为那些非常大（并且相对较少）的文档提出的任何特殊解决方案都可能会影响我存储小文档的方式，否则这些小文档会愉快地生活在 MongoDB 集合中。
据我所知，我有以下选择。我将不胜感激任何关于这些优点和缺点的意见，以及我错过的任何其他选项。
1) 使用另一个数据存储：这似乎太激烈了。我喜欢 MongoDB，而且我没有达到许多对象的大小限制。在单词的情况下，我的应用程序可以以不同的方式处理非常大的对象和其他对象。它看起来并不优雅。
2) 使用 GridFS 存储值：就像传统数据库中的 blob 一样，我可以将值的前几千个元素保留在文档中，如果列表中有更多元素，我可以将其余元素保留在 GridFS对象作为二进制文件。我无法在这部分进行搜索，但我可以忍受。
3) 滥用 GridFS：我可以将每个文档保存在 gridFS 中。对于大多数（小）文档，二进制块将是空的，因为文件集合将能够保留所有内容。其余的我可以将多余的元素保留在块集合中。与选项 #2 相比，这会带来开销吗？
4) 真正滥用 GridFS：我可以使用 GridFS 文件集合中的可选字段来存储值中的所有元素。 GridFS 是否也对文件集合进行智能分块？
5) 使用一个额外的“关系”集合来存储一对多关系，但是这个集合中的文档数量很容易超过一千亿行。
【问题讨论】：
-
是否需要以任何方式查询这些可选字段？
-
“GridFS 是否也对文件集合进行智能分块？”。不可以。文件元数据必须适合单个 BSON 文档。
-
更新/插入需要什么样的原子性？
-
感谢 cmets Thilo。 1）我希望能够查询那些可选字段，但我可以放弃这个要求。 2）谢谢，这就是我的怀疑。 3) 原子性并不重要，我可以在应用层处理它——例如，手动分块大文档并将它们保存为两个或三个常规对象是一种选择。
-
只是补充一点，这里有一些细节 - mongodb.org/display/DOCS/When+to+use+GridFS - 关于何时以及何时不使用 GridFS。如果您不需要查询，那么 Gridfs 应该适合您的场景。