有效的 MongoDB 索引

阅读数:49 2019 年 11 月 29 日 10:19

有效的MongoDB索引

在优化 MongoDB 性能时,理解和使用索引是非常重要的。本次给大家整理了 MongoDB 索引的相关文章,来帮助大家提升对 MongoDB 索引的理解。

索引是一个拥有自己唯一存储的对象,它为集合提供了一条快速访问路径。索引的存在主要是为了提高性能,因此,在优化 MongoDB 性能时,有效理解和使用索引是非常重要的。

1 B- 树索引

B- 树索引是 MongoDB 的默认索引结构。以下是 B- 树索引结构高等级的概述。

有效的MongoDB索引

B- 树索引具有分层树结构。树顶部是头部块。此块包含指向任何给定范围的键值的适当分支块的指针。分支块通常会指向适当的叶子块以获得更具体的范围,或者对于更大的索引,则指向另一个分支块。 叶子块包含一个键值列表和指向磁盘上文档位置的指针。

查看上面的图,让我们想象一下 MongoDB 如何遍历这个索引。 如果我们需要访问“BAKER”的记录,我们首先会查阅头部块。 头部块会告诉我们,从 A 到 K 开始的键值存储在最左边的分支块中。 访问这个分支块,我们发现从 A 到 D 开始的键值存储在最左边的叶子块中。 咨询这个叶子块,我们发现值“BAKER”以及它关联的磁盘位置,我们将用它来获得有关的文件。

叶子块包含前一个和后一个叶子块的链接。 这允许我们以升序或降序扫描索引,并且允许使用 gtlt 操作符的范围查询使用索引进行处理。

与其他索引策略相比,B- 树索引具有以下优点:

  1. 由于每个叶子节点处于相同的深度,所以性能是非常可预测的。 从理论上讲,集合中的任何文档都不会超过三或四次 I/O。

  2. B 树为大型集合提供了良好的性能,因为深度最多为四个(一个头部块,两个分支块级别和一个叶子块级别)。 一般来说,没有任何文件需要四个以上的 I/O 来定位。 实际上,因为头部块几乎总是已经加载到内存中,而分支块通常加载到内存中,所以实际的物理磁盘读取次数通常只有一次或两次。

  3. 因为与前一个和后一个叶子块的链接,所以 B- 树索引支持范围查询以及精确的查找是可行的。

B- 树索引提供了灵活高效的查询性能。但是,在更改数据时维护 B- 树可能很昂贵。例如,考虑在上面的图表中插入一个键值为“NIVEN”的文档。要插入集合,我们必须在“L-O”块中添加一个新条目。如果在这个区域内有空闲空间,那么成本是很大的,但也许不会过多。但是如果块中没有可用空间会发生什么?

如果叶子块中没有空闲空间用于新条目,则需要索引拆分。必须分配新块,并将现有块中的一半条目移入新块。除此之外,还需要在分支块中添加一个新条目(以便指向新创建的叶子块)。如果分支块中没有空闲空间,则分支块也必须分割。

这些索引拆分是一项昂贵的操作:必须分配新块,并将索引条目从一个块移到另一个块。

2 索引选择性

属性或属性组的选择性是对这些属性的索引的有用性的常用度量。如果文档或索引具有大量的唯一值或重复值很少,则它们是有选择的。例如,DATE_AND_TIME_OF_BIRTH 属性将非常有选择性,而 GENDER 属性将不会被选择。

选择性索引比非选择性索引更有效,因为它们更直接地指向特定的值。MongoDB 优化器通常会使用最有选择性的索引。

3 唯一索引

唯一的索引是阻止组成索引的属性的任何重复值的索引。如果你尝试在包含此类重复值的集合上创建唯一索引,则会收到错误消息。同样,如果尝试插入包含重复唯一索引键值的文档,也会收到错误。

通常会创建一个唯一索引,以防止重复值而不是提高性能。 但是,唯一的索引文件通常非常有效 - 它们只能指向一个文件,因此非常有选择性。

4 连接索引

连接索引只是一个包含多个属性的索引。连接键的优点在于它比单个键索引更具有选择性。属性的组合将指向比由单个属性组成的索引更少数量的文档。包含 find() 或 $match 子句中引用的所有属性的连接索引将特别有效。

如果你经常查询集合中的多个文档,那么为这些文档创建一个连接索引是一个很好的主意。例如,我们可以通过 Surname(姓氏) 和 Firstname(名字) 查询 people 集合。在这种情况下,我们可能希望在 Surname 和 Firstname 上创建一个索引。例如:

复制代码
db.people.createIndex({ "Surname":1 ,"Firstname":1} );

使用这样的索引,我们可以快速找到 people 中所有匹配给定的 Surname \ Firstname 组合。 这样的索引比单独的 Surname 索引或单独的 Surname 和 Firstname 索引要有效得多。

如果连接索引只能在所有键出现 find() 或 $match 时使用,则连接索引的使用可能会非常有限。幸运的是,连接索引可以非常有效地使用,提供任何初始或主要属性。主要属性是在索引定义中最早指定的属性。

有效的MongoDB索引

上图显示了将属性添加到连接索引时获得的改进。涉及的查询是在一个 1,000,000 个文档的 people 集合上:

复制代码
db.people.find(
{ Firstname: "KAREN",
Surname: "SMITH",
dob: ISODate("2006-01-21T05:55:32.520Z")
},
{ _id: 0, tel: 1 }
);

例如,我们通过提供 Surname,Firstname 和 dob 来检索电话号码。

全面集合扫描要求我们访问所有 1,000,000 个文档。仅索引 surname 就减少到 20,028 个文件 - 实际上是收集中的所有“SMITHS”。添加 firstname 将文档数减少到 188 个。通过添加 dob,我们只需可以访问两个:访问一个索引条目并从那里访问集合以获取电话号码。 最后的优化是添加电话号码 tel 属性。 现在我们根本不需要访问集合 - 我们需要的就是索引。 这有时被称为“覆盖”指数。

请注意,覆盖索引通常要求查询包含一个投影,以消除索引中包含的属性以外的所有属性。

5 连接索引指南

以下指南将有助于确定何时使用连接索引,以及如何确定应包含哪些属性以及按何种顺序。

  1. 在集合中为 find() 或 $match 条件一起出现的属性创建连接索引。
  2. 如果属性有时会以 find() 或 $match 的形式出现,请将它们放在索引的开头。
  3. 如果连接的索引还支持不是所有属性都被指定的查询,则连接索引更有用。 例如,createIndex({“Surname” : 1, “Firstname” : 1}) 比 createIndex({“Firstname” : 1, “Surname” : 1}) 更有用,因为只针对 surname 的查询比仅针对 firstname 的查询更有可能发生。
  4. 属性越有选择性,在索引的前端越有用。但是,请注意,WiredTiger 索引压缩可以从根本上缩小索引。当领先的列较少选择时,索引压缩更有效。所以如果属性的顺序不是由前面三个考虑因素决定的,你可能不得不尝试索引顺序。

总结

在 MongoDB 的优化过程中,只有深入理解内部的索引机制,我们才能更好的提升 MongoDB 的性能。

本文转载自公众号 360 云计算(ID:hulktalk)。

原文链接:

https://mp.weixin.qq.com/s/nJJrsiXhTDqn9B4YZeIYSg

评论

发布