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