简而言之：如果您有大量不同大小的文档，而达到最大对象大小的文档相对较少，那么将这些文档存储在 MongoDB 中的最佳实践是什么？
我有一组文件，例如：
{_id: ...,
values: [12, 13, 434, 5555 ...]
}
值列表的长度因文档而异。对于大多数文档来说，它会有一些元素，对于少数文档来说，它会有数千万个元素，我会达到 MongoDB 中的最大对象大小限制。问题是我为那些非常大（并且相对较少）的文档提出的任何特殊解决方案都可能会影响我存储小文档的方式，否则这些小文档会愉快地生活在 MongoDB 集合中。
据我所知，我有以下选择。我将不胜感激有关这些优点和缺点的任何意见，以及我错过的任何其他选项。
1）使用另一个数据存储：这似乎太激烈了。我喜欢 MongoDB，而且我没有达到许多对象的大小限制。在单词的情况下，我的应用程序可以区别对待非常大的对象和其他对象。它似乎并不优雅。
2) 使用 GridFS 存储值：就像传统数据库中的 blob 一样，我可以将值的前几千个元素保留在文档中，如果列表中有更多元素，我可以将其余元素保留在 GridFS 对象中作为二进制文件。我无法在这部分进行搜索，但我可以忍受。
3) 滥用 GridFS：我可以将每个文档都保存在 gridFS 中。对于大多数（小）文档，二进制块将是空的，因为文件集合将能够保留所有内容。其余的我可以将多余的元素保留在块集合中。与选项 #2 相比，这会带来开销吗？
4）真正滥用GridFS：我可以使用GridFS文件集合中的可选字段来存储值中的所有元素。GridFS 是否也对文件集合进行智能分块？
5）使用一个额外的“关系”集合来存储一对多关系，但是这个集合中的文档数量很容易超过一千亿行。