是否有MongoDB最大BSON大小的解决方法？

Question

我正在处理的文档非常大。它收集了类似于SurveyMonkey的极长调查中用户的输入，并将答案存储在MongoDB数据库中。

并不出乎意料，我遇到了以下错误：

Error: Document exceeds maximal allowed bson size of 16777216 bytes

如果我无法更改文档中的字段，我该怎么办？是否有一种方法可以通过删除空白等方式压缩文档？

编辑：

这是文档的结构。

Schema({
    id : { type: Number, required: true },
    created: { type: Date, default: Date.now },
    last_modified: { type: Date, default: Date.now },
    data : { type: Schema.Types.Mixed, required: true }
});

数据字段的示例：

{
    id: 65,
    question: {
        test: "some questions",
        answers: [2,5,6]
    }
    // there could be thousands of these question objects
}

- bejm

---

你能否提供一个文档的示例，展示其结构的子集即可，这将有助于诊断。 - Tom Swifty

没有一些上下文，很难说。可以给我们提供一些额外的细节吗？你是否需要能够搜索所有字段？是否需要原子更新单个文档？ - zero323

你确定你永远不会查询这些数据吗？为什么又要使用MongoDB？ - Sammaye

@Sammaye 不太清楚你的意思。我查询文档，并在网页中显示数据字段的内容，但我不需要对该数据进行任何搜索。 - bejm

哦，好的，这意味着GridFS真的不是一个好选择，我想你可以将数据字段存储在GridFS中，但是嗯。 - Sammaye

Answer 1

你可以做的一件事是构建自己的mongoDB :-). Mongodb是一个开放源代码，文档大小的限制相当随意，以强制实施更好的架构设计。你只需修改此行并为自己构建它。但要小心。

最直接的想法是将每个小问题放在不同的文档中，并带有一个引用其父级的字段。

另一个想法是限制父级中的文档数量。假设您的限制是N个元素，则父级如下：

{
  _id : ObjectId(),
  id : { type: Number, required: true },
  created: { type: Date, default: Date.now },  // you can store it only for the first element
  last_modified: { type: Date, default: Date.now }, // the same here
  data : [{
    id: 65,
    question: {
        test: "some questions",
        answers: [2,5,6]
    }
  }, ... up to N of such things {}
  ]
}

通过修改数字N，您可以确保在16 MB的BSON内。为了阅读整个调查内容，您可以选择

db.coll.find({id:您需要的ID})，然后在应用程序级别上组合整个调查内容。同时不要忘记在id上进行ensureIndex。

尝试不同的方法，在数据上做基准测试，看看哪种方法适合您。

- Salvador Dali

---

我认为我将不得不采用你提到的方法 - “每个小问题在不同的文档中”。 - bejm

有趣的解决方案，不过“伟大的力量带来伟大的责任”！ - EmptyArsenal

这并不能解决大小问题，因为数据字段实际上比 blob 格式要大，解决方案是将问题分离到一个问题集合中。 - Sammaye

我只是想强调一下，MongoDB是开源的，你可以自由地以任何方式修改它。但是当然，你需要知道自己在做什么。 - Salvador Dali

Answer 2

你应该使用gridfs。它允许你将文档分块存储。这是链接：http://docs.mongodb.org/manual/reference/gridfs/。

- EmptyArsenal

---

在这种情况下，GridFS 不是一个好主意，因为使用索引来搜索这些文档是不可能的。 - Sammaye

根据@bejm的评论，他们不进行任何搜索。 - EmptyArsenal

这取决于需求是什么，以及他期望的性能类型是什么，但速度挑战方面提出了很好的观点。 - EmptyArsenal

是的，需要澄清的是他需要查询文档本身，GridFS 不适用。 - Sammaye

一个模式更改比存储大量二进制文档要好得多。这几乎完全破坏了使用MongoDB的价值。 - WiredPrairie

我的理解是他只查询了顶层字段，而没有查询分块数据。然而，我并没有对GridFS进行过多的测试。 - EmptyArsenal