2

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

想象一下，我有一个这样的索引：

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

遵循关于索引的 MongoDb 手册：

MongoDB 可以使用此索引来支持包括以下内容的查询：

  • 项目字段，
  • 项目字段和位置字段，
  • item 字段和 location 字段和 stock 字段，或
  • 只有 item 和 stock 字段；但是，该索引的效率低于仅针对商品和库存的索引。

MongoDB 无法使用此索引来支持包括以下内容的查询：

  • 只有位置字段，
  • 仅股票字段，或
  • 只有位置和库存字段。

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

  • 项目：字符串
  • 位置：字符串
  • 库存：字符串
  • 数量：数量

想象一下，我想确保每个查询都确实被索引。我会做：

对于item：

  • item, location, stock, qty
  • item, location, qty, stock
  • item, stock, qty, location
  • item, stock, location, qty
  • item, qty, location, stock
  • item, qty, stock, location

对于location：

  • ...你知道要点

现在……这似乎有点疯狂。如果您有一个数据库，其中有 10 个可搜索字段，那么随着索引数量呈指数增长，这显然不可行。

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

我是吗？

4

2 回答 2

2

我将尝试通过示例来解释这意味着什么。基于 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 个步骤）快速找到。

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

但它可以帮助我们解决其他问题。让我们看一个location看起来已经订购的查询。但如果你仔细看一下——你会发现这是一团糟。一个在开始，然后一个在结束。它根本无法帮助你。

我希望这可以澄清一些事情：

  • 为什么索引很好（将时间从 O(n) 减少到可能的 O(log(n)）
  • 为什么复合索引可以帮助一些查询但是我们还没有在那个特定的字段上创建一个索引来帮助一些其他的查询。
  • 复合索引涵盖哪些索引
  • 为什么索引会造成伤害（它会创建应维护的额外数据结构）

这应该说明另一件有效的事情：索引不是灵丹妙药。您无法加快所有查询的速度，因此认为通过在所有字段上创建索引一切都会非常快，这听起来很愚蠢。

于 2013-11-14T07:32:21.493 回答
0

你真正的查询模式是什么？您不太可能需要创建所有这些可能的索引组合。我也怀疑包含qty在索引中是否会有很大用处。您是否需要搜索 qty == 4 与位置和项目类型无关的东西？

索引不需要识别每条记录，它只需要足够具体以使任何最终扫描变得很小。给定一个项目代码或一个库存值，是否真的有那么多位置需要您对其进行索引？

我怀疑在这种情况下，索引 on item、索引 onlocation和索引 onstock足以以足够的速度回答最可能的查询。（但我们需要更多地了解这些字段名称的含义以及其中的值的计数和分布）。

与您的查询一起使用explain，您可以看到它们的执行情况。根据需要添加索引，不要创建所有可能的排序。

于 2013-11-14T07:21:08.780 回答