我有超过 16MB 的文档。这些文档由许多键/值对及其包含的子文档（字典）和数组（列表）组成，它们可能嵌套了好几层。
如果我尝试插入其中一个超 16MB 文件，则会收到有关文档大小大于 16MB 的错误。所以，我开始研究 GridFS。GridFS 似乎非常适合分块文件，例如二进制数据。但是，我不清楚如何像上面描述的那样“分块”高度嵌套的 K/V 文档。我在想我可能只需要将这些巨大的文档分解成更小的文档并咬紧牙关并实施事务，因为在多个文档上插入没有原子性。
我对 GridFS 的理解有偏差吗？将文档分解为具有事务支持的较小文档是最好的前进方式，还是有办法在这里使用 GridFS？
非常感谢您的关注。
只是好奇为什么将键/值对存储在文档而不是集合中？
如果您需要其中很多，您可以将它们存储在一个集合中（假设它们都是唯一的，而不是任何类型的嵌套结构）。
或者，您可以将该数据迁移到 redis，这样在查找键/值时性能会更高，并且没有合理的限制。可以混合多个存储引擎。
针对评论 1 进行编辑：
如果您在文档中使用 16 兆的键值对，我实际上会质疑您现在如何对数据进行建模。仅仅因为数据库是无模式的并不意味着在 mongo 中存储键值的正确方法是在一个大文档中。
您能否提供更多关于您正在尝试做的事情的信息，以便我们更好地帮助了解您的需求并提供更好的答案？我相信我们可以为您提供的帮助远不止这些。
GridFS 将文件视为不透明的二进制 blob。它不区分“键/值文档”和图像文件。
如果您想对文档中包含的值进行查询等，您需要自己手动将它们拆分为较小的文档。另一方面，如果您的文档实际上只是碰巧具有内部结构的不透明数据块（您只关心程序内部，而不关心数据库），那么 GridFS 是一个不错的选择。
另一个考虑是性能：你真的需要读写16MB+的巨型文档吗？还是您通常只处理每个文档的一个子集？如果是前者，则使用 GridFS；如果是后者，请将您的文档拆分到不同的集合中，并在它们之间进行引用。