MongoDB 索引

一、MongoDB 索引

Nothing like a little truth to sober you up.

索引支持在MongoDB中高效地执行查询。如果没有索引，MongoDB必须执行全集合扫描，即扫描集合中的每个文档，以选择与查询语句匹配的文档。这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。

如果查询存在适当的索引，MongoDB可以使用该索引限制必须检查的文档数。

索引是特殊的数据结构，它以易于遍历的形式存储集合数据集的一小部分。索引存储特定字段或一组字段的值，按字段值排序。索引项的排序支持有效的相等匹配和基于范围的查询操作。此外，MongoDB还可以使用索引中的排序返回排序结果。

官网文档：

MongoDB索引使用B树数据结构（确切的说是B-Tree，MySQL是B+Tree）

MongoDB的索引可以分为：单字段索引、复合索引以及地理空间索引等。

单字段索引:MongoDB支持在文档的单个字段上创建用户定义的升序/降序索引，称为单字段索引（Single Field Index）。

对于单个字段索引和排序操作，索引键的排序顺序（即升序或降序）并不重要，因为MongoDB可以在任何方向上遍历索引。

复合索引:MongoDB还支持多个字段的用户定义索引，即复合索引（Compound Index）。

复合索引中列出的字段顺序具有重要意义。例如，如果复合索引由{ userid: 1, score:-1}组成，则索引首先按userid正序排序，然后在每个userid的值内，再在按score倒序排序。

地理空间索引（Geospatial Index）:为了支持对地理空间坐标数据的有效查询，MongoDB提供了两种特殊的索引：返回结果时使用平面几何的二维索引和返回结果时使用球面几何的二维球面索引。

文本索引（Text Indexes）:MongoDB提供了一种文本索引类型，支持在集合中搜索字符串内容。这些文本索引不存储特定于语言的停止词（例如“the”、“a”、“or”），而将集合中的词作为词干，只存储根词。

哈希索引（Hashed Indexes）:为了支持基于散列的分片，MongoDB提供了散列索引类型，它对字段值的散列进行索引。这些索引在其范围内的值分布更加随机，但只支持相等匹配，不支持基于范围的查询。

返回一个集合中的所有索引的数组

语法格式： db.collection.getIndexes()

提示：该语法命令运行要求是MongoDB 3.0+

默认_id索引：MongoDB在创建集合的过程中，在 _id字段上创建一个唯一的索引，默认名字为 id，该索引可防止客户端插入两个具有相同值的文档，您不能在_id字段上删除此索引。

注意：该索引是唯一索引，因此值不能重复，即 _id值不能重复的。在分片集群中，通常使用 _id作为片键。

语法格式： db.collection.createIndex(keys, options)

注意:在 3.0.0版本前创建索引方法为 db.collection.ensureIndex()，之后的版本使用了 db.collection.createIndex()方法， ensureIndex()还能用，但只是 createIndex()的别名。

可以移除指定的索引，或移除所有索引

语法格式： db.collection.dropIndex(index)或移除所有索引 db.collection.dropIndexes()

提示： _id的字段的索引是无法删除的，只能删除非 _id字段的索引。

分析查询性能（Analyze Query Performance）通常使用执行计划（解释计划、Explain Plan）来查看查询的情况，如查询耗费的时间、是否基于索引查询等。

那么，通常，我们想知道，建立的索引是否有效，效果如何，都需要通过执行计划查看。

语法格式： db.collection.find(query,options).explain(options)

当查询条件和查询的投影仅包含索引字段时，MongoDB直接从索引返回结果，而不扫描任何文档或将文档带入内存。这些覆盖的查询可以非常有效。

我的理解是类似于mysql的索引覆盖，无须回表查询。

有故事的人，通常不喜欢讲故事。不想在嘴上卖力，是想在心中开发能量。沉默，是一种负重的坚强，是一种韬光养晦的低调。少说多做，才是最有力的践行。

二、MongoDB自动分片介绍

数据划分（partitioning）关键问题是怎么样将一个集合中的数据均衡的分布在集群中的节点上。 MongoDB数据划分的是在集合的层面上进行的，它根据片键来划分集合中的数据。

（1）使用片键的取值范围指定数据块

设置分片的时候，需要从集合里选出一个字段，用该字段的值作为数据拆分的依据，这个字段称为片键（shard key)，文档中的数据按照这个字段排序切分成块，分布到各个片上。比如说有个表示人员的集合，如果选择名字(“name”)字段作为片键，第一片可能会存放名字以A F开头的文档，第二个存放的是以G P开头的文档，第三个存的Q～Z的名字。随着添加（删除）片，MonogDB会重新平衡数据，使每片的流量都比较均衡，数据量也在合理范围内。

按照片键取值范围来作为数据块划分的区间依据，优点是按范围查询的时候它的效率很高，当给定一个查询范围，根据mongos中的映射表可以很快的定位到分片上的数据块。除此之外当两个分片的键取值比较靠近的时候，会被放到相近的块中，由于数据的局部性原理，这样的话可以加快查询效率，同时也可以减少内存换页次数。

缺点是可能会导致数据分布不均衡，如果选择的片键具有线性的性质，例如时间，将其作为片键的话，在某个时间段的写请求（读请求）都会被映射到同一个分片的同一个数据块上，这样的话不仅会降低系统的读写性能，而且也会因写操作过于集中导致片间的不平衡。

（2）按照片键哈希值来作为数据块的划分区间依据

优点是可以确保一个比较均衡的数据分布，因为即使当两个文档的片键取值很接近的时候，例如上面例子中一个x=25，一个x=26，它们的哈希结果也会有很大的差别，这样的话数据会随机的分布到集群中，有利于数据的均衡的分布，减少数据块的移动次数，同时由于数据分散会减少单个数据块的写操作的压力，提高写入速度。

缺点是随机划分导致数据过于分散，当要查询某个范围内的数据时比如年龄大于20小于25的所有男生信息，如果直接使用范围划分的话，由于其具有良好的数据局部性特点，可能只要访问几个相邻的数据块就行了，但是如果要使用哈希划分的方法很可能要访问所有的数据块。

这是一种粗力度的片键，比如上边说的用户ID。如果按照用户ID分片，你可以预料到插入会分布在各个分片上，因为无法预知哪个用户何时会插入数据。这样一来，粗粒度分片键也能拥有随机性，还能发挥分片集群的优势。而且粗粒度的片键还能使用局部性带来的效率提升。当某个用户上传100个文件，基于用户ID字段的分片建能确保这些插入都落到同一个分片上，并几乎能写入索引的同一部分，这样效率很高。粗粒度分片键在分布性和局部性上都表现很好，但是它也有一个很难解决的问题：块有可能无限制的增长。想想基于用户ID的片键，假如有几个特殊用户，他们上传了上百万个文件，那么一个块里就可能只有一个用户ID，这个块能拆分么？不能，因为用户ID是最小的粒度，拆分了查询就没法路由到数据。这就造成分片之间数据量不均衡。更典型的就是type，status这类的字段，因为它们的选择性实在是太低，导致无法拆分。片键基比较小时，所有的键值相同导致MongoDB不能分裂Chunk，迁移这些不可分裂的Chunk将更加耗时，即使迁移后也难以保证数据在各个分片上的平衡。Chunk数量被基约束住后，我们就不能利用MongoD分片集群特性将集合部署到更多的机器。

在Sharding结构中，分片策略，片键选择是影响性能的关键因素，片键不仅影响数据分布，而且影响业务逻辑，所以片键的选择不单单是均匀的将数据分布到各个片上，而且要考虑查询的性能。坏的片键有时候会导致数据分布很差，有时候会导致无法使用局部性原理，还有一些会影响数据块的拆分。

上边我们讨论了低效片键的问题和原因，理想的片键应该结合粗粒度分片键与细粒度片键两者的优势。

1、保证CRUD能利用局限性＝＝》升序片键的优点

2、将插入数据均匀分布到各个分片上＝＝》随机片键的优点

3、有足够的粒度进行块拆分＝＝》粗粒度片键的优点

满足这些要求的的片键通常由两个字段组成，第一个是粗粒度，第二个是粒度较细。那么我们需要使用复合片键。例如对上面的例子，选取{userid：1，_id:1}作为片键，当用户同时插入数据时，我们可以预见大多数情况下，这些数据会被均匀的分布到所有的片上，而且分片里的唯一字段_id能保证对任意一个文档的查询和更新始终都能指向单个分片。如果对用户ID执行更复杂的查询，那么路由也只会将查询路由包含此用户ID存在的片上，而不会发到所有分片。由于_id（升序）的存在，保证了块始终是能继续拆分的，哪怕用户创建了大量文档，情况也是如此。

所以在选择片键时尽量能保持良好的数据局部性而又不会导致过度热点的出现，很多时候，组合片键是一种比较常用的做法。

除此之外，也可以选择我们经常查询的字段作为片键，这类分片键可以使得查询时mongos仅仅将查询发送给特定的mongod实例，不需要等待多个实例返回数据后再进行合并。

三、mongodb Aggregation聚合操作之$sort

在深入了解 MongoDB Aggregation聚合操作中的$sort操作之前，让我们先回顾一下上一篇关于$match操作的内容。上文详细介绍了$match的使用方法以及相关参数细节。本篇将开启对 Aggregation聚合操作中的$sort操作的探索。

$sort操作的主要作用是对所有输入文档进行排序，并按照排序后的顺序返回到管道。其语法如下：

{$sort:{ field1: value1, field2: value2,...}}

$sort接收一个文档，该文档指定了要排序的字段及其相应的排序顺序。这些值可取以下之一：

3.使用$meta表达式：如{$meta:"textScore"}，按照计算得出的 textScore元数据进行降序排序。

如果对多个字段进行排序，则按照从左到右的顺序计算排序。例如，在示例中，文档首先按 age字段降序排序，然后在具有相同 age值的文档之间按 posts字段的值进行升序排序。

对于要排序的字段，设置排序顺序为 1或-1，分别表示升序或降序。以对 users集合中文档进行排序为例，根据 age字段降序排列，然后根据 posts字段中的值升序排列。

db.users.aggregate([{$sort:{ age:-1, posts: 1}} ])

指定计算得出的元数据的新字段名，并将$meta表达式作为其值。例如，使用文本匹配操作符对文档进行筛选，然后首先按 textScore元数据排序，再根据 posts字段的值进行降序排序。

db.users.aggregate([{$match:{$text:{$search:"operating"}}},{$sort:{ score:{$meta:"textScore"}, posts:-1}} ])

在$sort与$limit操作结合使用时，优化器可以将$limit并入$sort中，从而仅在内存中存储指定数量（n）的结果，避免了大量数据的处理。如果允许磁盘使用（allowDiskUse设置为 true）且 n大于聚合内存限制，此优化仍然有效。然而，这种优化在不同版本中可能会有所变化。

$sort阶段的内存限制为 100兆字节。默认情况下，超过此限制会导致错误。为了处理大量数据集，可以将 allowDiskUse选项设置为 true，允许$sort操作写入临时文件。请参阅 db.collection.aggregate()方法中的 allowDiskUse选项和 aggregate命令以获取详细信息。

在 MongoDB版本 2.6中，$sort的内存限制从 RAM的 10%更改为 100兆字节。

将$sort操作符放置在管道的开头或$project、$unwind和$group操作符之前时，可以利用索引。如果$project、$unwind或$group在$sort之前执行，则$sort无法利用任何索引。