更新:我需要补充一点，这个问题的重点是允许我为 Json Rest Stores 定义模式。用户可以通过任意一个键或多个键进行搜索。因此，我无法轻易预测用户将搜索什么——可能是 1、2、5 个字段(对于人员、预订等数据丰富的字段尤其如此)

假设我有一个这样的索引:

{ "item": 1, "location": 1, "stock": 1 }

在 MongoDb manual on indexes 之后:

MongoDB can use this index to support queries that include:

• the item field,
• the item field and the location field,
• the item field and the location field and the stock field, or
• only the item and stock fields; however, this index would be less efficient than an index on only item and stock.

MongoDB cannot use this index to support queries that include:

• only the location field,
• only the stock field, or
• only the location and stock fields.

现在，假设我有一个包含这些字段的模式:

• 项目:字符串
• 位置:字符串
• 股票:字符串
• 数量:数量

想象一下，我想确保每个查询确实都已编入索引。我会这样做:

对于项目:

• 商品、位置、库存、数量
• 商品、位置、数量、库存
• 商品、库存、数量、位置
• 商品、库存、位置、数量
• 商品、数量、位置、库存
• 商品、数量、库存、位置

对于位置:

• ...你知道要点

现在……这看起来有点疯狂。如果您的数据库中有十个可搜索字段，那么随着索引数量呈指数增长，这显然是行不通的。

我错过了什么吗？我的想法是定义一个模式，定义哪些字段是可搜索的，并编写一个函数来组成所有需要的索引，而不管哪些字段存在，哪些字段不存在。但是，我正在考虑它，而且...好吧，我一定错过了什么。

我是吗？

最佳答案

我将尝试通过示例来解释这意味着什么。基于 B-tree 的索引不是 mongodb 特有的。相比之下，这是一个相当普遍的概念。

因此，当您创建索引时 - 您向数据库展示了一种更容易查找内容的方法。但是这个索引存储在某个地方，指针指向原始文档的位置。此信息是有序的，您可以将其视为具有非常好的属性的二叉树:搜索从 O(n) 减少。 (线性扫描)到 O(log(n)) .这要快得多，因为每次我们将空间减半(可能我们可以将时间从 10^6 减少到 20 次查找)。例如，我们有一个包含字段 {a : some int, b: 'some other things'} 的大集合如果我们用 a 索引它，我们最终会得到另一个按 a 排序的数据结构。 .它看起来是这样的(我并不是说它是另一个集合，这只是为了演示):

{a : 1, pointer: to the field with a = 1}, // if a is the smallest number in the starting collection
...
{a : 999, pointer: to the field with a = 990} // assuming that 999 is the biggest field

所以现在我们正在搜索一个字段 a = 18。我们不是一个一个地遍历所有元素，而是在中间取一些东西，如果它大于 18，那么我们将下半部分分成两半并检查那里的元素。我们继续直到找到 a = 18。然后我们查看指针并知道我们提取原始字段。

复合索引的情况类似(不是按一个元素排序，而是按多个元素排序)。例如你有一个集合:

{ "item": 5, "location": 1, "stock": 3, 'a lot of other fields' }  // was stored at position 5 on the disk
{ "item": 1, "location": 3, "stock": 1, 'a lot of other fields' }  // position 1 on the disk
{ "item": 2, "location": 5, "stock": 7, 'a lot of other fields' }  // position 3 on the disk
... huge amount of other data
{ "item": 1, "location": 1, "stock": 1, 'a lot of other fields' }  // position 9 on the disk
{ "item": 1, "location": 1, "stock": 2, 'a lot of other fields' }  // position 7 on the disk

并想要一个索引 { "item": 1, "location": 1, "stock": 1 }。查找表看起来像这样(再来一次 - 这不是另一个集合，这只是为了演示):

{ "item": 1, "location": 1, "stock": 1, pointer = 9 }
{ "item": 1, "location": 1, "stock": 2, pointer = 7 }
{ "item": 1, "location": 3, "stock": 1, pointer = 1 }
{ "item": 2, "location": 5, "stock": 7, pointer = 3 }
.. huge amount of other data (but not necessarily here. If item would be one it would be somewhere next to items 1)
{ "item": 5, "location": 1, "stock": 3, pointer = 5 }

看到这里所有的东西基本上都是按项目排序，然后是位置，然后是指针。 与使用单个索引的方式相同，我们不需要扫描所有内容。如果我们有一个查找 item = 2, location = 5 and stock = 7 的查询我们可以快速识别带有 item = 2 的文件在哪里是然后以相同的方式快速识别这些项目中的哪些项目带有 location 5等等。

现在是一个有趣的部分。同样我们只创建了一个索引(虽然这是一个复合索引，但它仍然是一个索引)我们可以用它来快速找到元素

• 仅由 item .实际上，我们需要做的只是第一步。所以没有必要创建另一个索引 {location : 1} 因为它已经被复合索引覆盖了。
• 我们也可以通过 item and by location 快速找到(我们只需要 2 个步骤)。

Cool 1 索引但以三种不同的方式帮助我们。但是等一下:如果我们想通过 item and stock 查找怎么办？ .哦，看起来我们也可以加快这个查询。我们可以在 log(n) 中找到具有特定项目的所有元素，然后......在这里我们必须停止 - 魔术已经完成。我们需要遍历所有这些。但还是很不错。

但它可以帮助我们解决其他问题。让我们看一下 location 的查询看起来已经订购了。但是如果你仔细观察它——你会发现这是一团糟。开头一个，结尾一个。它根本帮不了你。

我希望这能澄清一些事情:

• 为什么索引很好(将时间从 O(n) 减少到潜在的 O(log(n))
• 为什么复合索引可以帮助处理某些查询，但我们尚未在该特定字段上创建索引并帮助处理其他一些查询。
• 复合索引覆盖了哪些索引
• 为什么索引会造成伤害(它创建了应该维护的额外数据结构)

这应该说明另一件事:索引不是 Elixir 。您无法加快所有查询的速度，因此认为通过在所有字段上创建索引一切都会超快的想法听起来很愚蠢。

关于MongoDb:如何为具有许多可搜索字段的数据创建正确的(复合)索引，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19971059/