MongoDB multikey：最大（推荐，有效）键数？答案

【问题标题】：MongoDB multikey : max (recommended, effective) number of keys?MongoDB multikey：最大（推荐，有效）键数？
【发布时间】：2012-07-02 15:55:40
【问题描述】：

我有“提要”集合，每个提要都有 cmets。因此，当有人在 feed 上获取时，他会被添加到 Mongo 的多键字段“subsribers”中。

feeds: {
 _id: ...,
 text: "Text",
 comments: [{by: "A", text: "asd"},{by: "B", text: "sdf"}],
 subscribers: ["A","B"]

}

然后，当我需要为用户 A 获取所有带有新 cmets 的提要时，我会请求带有 {subscribers: "A"} 的提要。

通常有 2-5 个 cmets，但有时（在热源上）可能有 >100 个 cmets 和 >100 个订阅者。

我知道不建议使用包含太多键的多键字段。那么多少算太多？

我问是因为我需要决定 - 我是使用多键还是直接向每个用户发送 cmets 更好。在这种情况下，我必须为每个订阅者复制提要 - 而且集合会增长得非常快 - 我认为这也不好：1000 个用户，每个用户后面跟着 10 个用户，每个用户每天执行 10 个操作 = 每 10 个记录 1 000 000天！

【问题讨论】：

【解决方案1】：

虽然您可能会遇到处理非常大的文档的问题，尤其是当 MongoDB 必须扫描整个文档以完成查询时，如您所料；具有大量值的数组在 MongoDB 中并没有问题，即使它们是多键索引。

有一个警告：索引不会存储超过 1024 字节的键（在多键文档的情况下，这是数组中的项目）。只要数组中的项目比这个限制短，你应该没问题。

话虽如此，您确实希望避免使用数组或文档的其他部分将无限且永远增长的数据模型。虽然 MongoDB 为每个文档在磁盘上添加了一点填充，但如果文档在创建后大幅增长，数据库必须将其移动到磁盘上的另一个位置。无论您决定对数据进行建模，请确保您的文档在创建后不会增长太多。

参考：

【讨论】：

我想你误解了我的问题。我没有问过不断增长的文件——我知道这很糟糕。我询问了如果我将为每个订阅者创建新文档，集合会增长得非常快。第二个选择不是为每个订阅者复制文档，而是有一个多键字段，在大多数情况下会有 4-5 个键，但有时可能多达 100-150 个。
我在不了解您的查询、负载和底层系统架构/负载的情况下进行了一些编辑。高插入率完全应该没有问题，并且多键选项也可以工作，只要文档在创建后不增长（即具有 100-150 个项目的文档在创建时具有那么多键。）
您回答了我的问题 - 数组上的索引键是该数组中的元素。在此之前，我不是 100% 确定它是单个元素还是数组本身。谢谢。