| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
Hill_open
9年前发布

MongoDB索引原理

   <h2>为什么需要索引?</h2>    <p>当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql)。</p>    <pre>  mongo-9552:PRIMARY> db.person.find()  { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" : 19 }  { "_id" : ObjectId("571b5dae1b0d530a03b3ce83"), "name" : "rose", "age" : 20 }  { "_id" : ObjectId("571b5db81b0d530a03b3ce84"), "name" : "jack", "age" : 18 }  { "_id" : ObjectId("571b5dc21b0d530a03b3ce85"), "name" : "tony", "age" : 21 }  { "_id" : ObjectId("571b5dc21b0d530a03b3ce86"), "name" : "adam", "age" : 18 }  </pre>    <p>当你往某各个集合插入多个文档后,每个文档在经过底层的存储引擎持久化后,会有一个位置信息,通过这个位置信息,就能从存储引擎里读出该文档。比如 <a href="/misc/goto?guid=4959671517722100992" rel="nofollow,noindex">mmapv1引擎</a> 里,位置信息是 『文件id + 文件内offset 』 , 在 <a href="/misc/goto?guid=4959671517806997891" rel="nofollow,noindex">wiredtiger存储引擎</a> (一个KV存储引擎)里,位置信息是wiredtiger在存储文档时生成的一个key,通过这个key能访问到对应的文档;为方便介绍,统一用 pos(position的缩写) 来代表位置信息。</p>    <p>比如上面的例子里, person 集合里包含插入了4个文档,假设其存储后位置信息如下(为方便描述,文档省去_id字段)</p>    <table>     <thead>      <tr>       <th>位置信息</th>       <th>文档</th>      </tr>     </thead>     <tbody>      <tr>       <td>pos1</td>       <td>{"name" : "jack", "age" : 19 }</td>      </tr>      <tr>       <td>pos2</td>       <td>{"name" : "rose", "age" : 20 }</td>      </tr>      <tr>       <td>pos3</td>       <td>{"name" : "jack", "age" : 18 }</td>      </tr>      <tr>       <td>pos4</td>       <td>{"name" : "tony", "age" : 21}</td>      </tr>      <tr>       <td>pos5</td>       <td>{"name" : "adam", "age" : 18}</td>      </tr>     </tbody>    </table>    <p>假设现在有个查询 db.person.find( {age: 18} ) , 查询所有年龄为18岁的人,这时需要遍历所有的文档(『全表扫描』),根据位置信息读出文档,对比age字段是否为18。当然如果只有4个文档,全表扫描的开销并不大,但如果集合文档数量到百万、甚至千万上亿的时候,对集合进行全表扫描开销是非常大的,一个查询耗费数十秒甚至几分钟都有可能。</p>    <p>如果想加速 db.person.find( {age: 18} ) ,就可以考虑对person表的age字段 <a href="/misc/goto?guid=4959671517889872511" rel="nofollow,noindex">建立索引</a> 。</p>    <pre>  db.person.createIndex( {age: 1} )  // 按age字段创建升序索引  </pre>    <p>建立索引后,MongoDB会额外存储一份按age字段升序排序的索引数据,索引结构类似如下,索引通常采用类似btree的结构持久化存储,以保证从索引里快速( O(logN)的时间复杂度 )找出某个age值对应的位置信息,然后根据位置信息就能读取出对应的文档。</p>    <table>     <thead>      <tr>       <th>age</th>       <th>位置信息</th>      </tr>     </thead>     <tbody>      <tr>       <td>18</td>       <td>pos3</td>      </tr>      <tr>       <td>18</td>       <td>pos5</td>      </tr>      <tr>       <td>19</td>       <td>pos1</td>      </tr>      <tr>       <td>20</td>       <td>pos2</td>      </tr>      <tr>       <td>21</td>       <td>pos4</td>      </tr>     </tbody>    </table>    <p>简单的说,索引就是将 文档 按照某个(或某些)字段顺序组织起来,以便能根据该字段高效的查询。有了索引,至少能优化如下场景的效率:</p>    <ul>     <li>查询,比如查询年龄为18的所有人</li>     <li>更新/删除,将年龄为18的所有人的信息更新或删除,因为更新或删除时,需要根据条件先查询出所有符合条件的文档,所以本质上还是在优化查询</li>     <li>排序,将所有人的信息按年龄排序,如果没有索引,需要全表扫描文档,然后再对扫描的结果进行排序</li>    </ul>    <p>众所周知,MongoDB默认会为插入的文档生成_id字段(如果应用本身没有指定该字段),_id是文档唯一的标识,为了保证能根据文档id快递查询文档,MongoDB默认会为集合创建_id字段的索引。</p>    <pre>  mongo-9552:PRIMARY> db.person.getIndexes() // 查询集合的索引信息  [      {          "ns" : "test.person",  // 集合名          "v" : 1,               // 索引版本          "key" : {              // 索引的字段及排序方向              "_id" : 1           // 根据_id字段升序索引          },          "name" : "_id_"        // 索引的名称      }  ]  </pre>    <h2>MongoDB索引类型</h2>    <p>MongoDB支持多种类型的索引,包括单字段索引、复合索引、多key索引、文本索引等,每种类型的索引有不同的使用场合。</p>    <h3>单字段索引 (Single Field Index)</h3>    <pre>      db.person.createIndex( {age: 1} )   </pre>    <p>上述语句针对age创建了单字段索引,其能加速对age字段的各种查询请求,是最常见的索引形式,MongoDB默认创建的id索引也是这种类型。</p>    <p>{age: 1} 代表升序索引,也可以通过{age: -1}来指定降序索引,对于单字段索引,升序/降序效果是一样的。</p>    <h3>复合索引 (Compound Index)</h3>    <p>复合索引是Single Field Index的升级版本,它针对多个字段联合创建索引,先按第一个字段排序,第一个字段相同的文档按第二个字段排序,依次类推,如下针对age, name这2个字段创建一个复合索引。</p>    <pre>      db.person.createIndex( {age: 1, name: 1} )   </pre>    <p>上述索引对应的数据组织类似下表,与{age: 1}索引不同的时,当age字段相同时,在根据name字段进行排序,所以pos5对应的文档排在pos3之前。</p>    <table>     <thead>      <tr>       <th>age</th>       <th>位置信息</th>      </tr>     </thead>     <tbody>      <tr>       <td>18</td>       <td>pos5</td>      </tr>      <tr>       <td>18</td>       <td>pos3</td>      </tr>      <tr>       <td>19</td>       <td>pos1</td>      </tr>      <tr>       <td>20</td>       <td>pos2</td>      </tr>      <tr>       <td>21</td>       <td>pos4</td>      </tr>     </tbody>    </table>    <p>复合索引能满足的查询场景比单字段索引更丰富,不光能满足多个字段组合起来的查询,比如 db.person.find( {age: 18, name: "jack"} ) ,也能满足所以能匹配符合索引前缀的查询,这里{age: 1}即为{age: 1, name: 1}的前缀,所以类似 db.person.find( {age: 18} ) 的查询也能通过该索引来加速;但 db.person.find( {name: "jack"} ) 则无法使用该复合索引。如果经常需要根据『name字段』以及『name和age字段组合』来查询,则应该创建如下的复合索引</p>    <pre>  db.person.createIndex( {name: 1, age: 1} )   </pre>    <p>除了查询的需求能够影响索引的顺序,字段的值分布也是一个重要的考量因素,即使person集合所有的查询都是『name和age字段组合』(指定特定的name和age),字段的顺序也是有影响的。</p>    <p>age字段的取值很有限,即拥有相同age字段的文档会有很多;而name字段的取值则丰富很多,拥有相同name字段的文档很少;显然先按name字段查找,再在相同name的文档里查找age字段更为高效。</p>    <h3>多key索引 (Multikey Index)</h3>    <p>当索引的字段为数组时,创建出的索引称为多key索引,多key索引会为数组的每个元素建立一条索引,比如person表加入一个habbit字段(数组)用于描述兴趣爱好,需要查询有相同兴趣爱好的人就可以利用habbit字段的多key索引。</p>    <pre>  {"name" : "jack", "age" : 19, habbit: ["football, runnning"]}  db.person.createIndex( {habbit: 1} )  // 自动创建多key索引  db.person.find( {habbit: "football"} )  </pre>    <h3>其他类型索引</h3>    <p><a href="/misc/goto?guid=4959671517966096734" rel="nofollow,noindex">哈希索引(Hashed Index)</a> 是指按照某个字段的hash值来建立索引,目前主要用于 <a href="/misc/goto?guid=4959671518048163831" rel="nofollow,noindex">MongoDB Sharded Cluster</a> 的Hash分片,hash索引只能满足字段完全匹配的查询,不能满足范围查询等。</p>    <p><a href="/misc/goto?guid=4959671518131344637" rel="nofollow,noindex">地理位置索引(Geospatial Index)</a> 能很好的解决O2O的应用场景,比如『查找附近的美食』、『查找某个区域内的车站』等。</p>    <p><a href="/misc/goto?guid=4959671518206808455" rel="nofollow,noindex">文本索引(Text Index)</a> 能解决快速文本查找的需求,比如有一个博客文章集合,需要根据博客的内容来快速查找,则可以针对博客内容建立文本索引。</p>    <h3>索引额外属性</h3>    <p>MongoDB除了支持多种不同类型的索引,还能对索引定制一些特殊的属性。</p>    <ul>     <li><a href="/misc/goto?guid=4959671518277660144" rel="nofollow,noindex">唯一索引 (unique index)</a> :保证索引对应的字段不会出现相同的值,比如_id索引就是唯一索引</li>     <li><a href="/misc/goto?guid=4959671518364215741" rel="nofollow,noindex">TTL索引</a> :可以针对某个时间字段,指定文档的过期时间(经过指定时间后过期 或 在某个时间点过期)</li>     <li><a href="/misc/goto?guid=4959671518436549193" rel="nofollow,noindex">部分索引 (partial index)</a> : 只针对符合某个特定条件的文档建立索引,3.2版本才支持该特性</li>     <li><a href="/misc/goto?guid=4959671518521132022" rel="nofollow,noindex">稀疏索引(sparse index)</a> : 只针对存在索引字段的文档建立索引,可看做是部分索引的一种特殊情况</li>    </ul>    <h2>索引优化</h2>    <h3>db profiling</h3>    <p>MongoDB支持对DB的请求进行 <a href="/misc/goto?guid=4959671518595882222" rel="nofollow,noindex">profiling</a> ,目前支持3种级别的profiling。</p>    <ul>     <li>0: 不开启profiling</li>     <li>1: 将处理时间超过某个阈值(默认100ms)的请求都记录到DB下的system.profile集合 (类似于mysql、redis的slowlog)</li>     <li>2: 将所有的请求都记录到DB下的system.profile集合(生产环境慎用)</li>    </ul>    <p>通常,生产环境建议使用1级别的profiling,并根据自身需求配置合理的阈值,用于监测慢请求的情况,并及时的做索引优化。</p>    <p>如果能在集合创建的时候就能『根据业务查询需求决定应该创建哪些索引』,当然是最佳的选择;但由于业务需求多变,要根据实际情况不断的进行优化。索引并不是越多越好,集合的索引太多,会影响写入、更新的性能,每次写入都需要更新所有索引的数据;所以你system.profile里的慢请求可能是索引建立的不够导致,也可能是索引过多导致。</p>    <h3>查询计划</h3>    <p>索引已经建立了,但查询还是很慢怎么破?这时就得深入的分析下索引的使用情况了,可通过查看下详细的 <a href="/misc/goto?guid=4959671518683071717" rel="nofollow,noindex">查询计划</a> 来决定如何优化。通过执行计划可以看出如下问题</p>    <ol>     <li>根据某个/些字段查询,但没有建立索引</li>     <li>根据某个/些字段查询,但建立了多个索引,执行查询时没有使用预期的索引。</li>    </ol>    <p>建立索引前, db.person.find( {age: 18} ) 必须执行 <a href="/misc/goto?guid=4959671518763173979" rel="nofollow,noindex">COLLSCAN</a> ,即全表扫描。</p>    <pre>  mongo-9552:PRIMARY> db.person.find({age: 18}).explain()  {      "queryPlanner" : {          "plannerVersion" : 1,          "namespace" : "test.person",          "indexFilterSet" : false,          "parsedQuery" : {              "age" : {                  "$eq" : 18              }          },          "winningPlan" : {              "stage" : "COLLSCAN",              "filter" : {                  "age" : {                      "$eq" : 18                  }              },              "direction" : "forward"          },          "rejectedPlans" : [ ]      },      "serverInfo" : {          "host" : "localhost",          "port" : 9552,          "version" : "3.2.3",          "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"      },      "ok" : 1  }  </pre>    <p>建立索引后,通过查询计划可以看出,先进行[IXSCAN]((https://docs.mongodb.org/manual/reference/explain-results/#queryplanner)(从索引中查找),然后 <a href="/misc/goto?guid=4959671518763173979" rel="nofollow,noindex">FETCH</a> ,读取出满足条件的文档。</p>    <pre>  mongo-9552:PRIMARY> db.person.find({age: 18}).explain()  {      "queryPlanner" : {          "plannerVersion" : 1,          "namespace" : "test.person",          "indexFilterSet" : false,          "parsedQuery" : {              "age" : {                  "$eq" : 18              }          },          "winningPlan" : {              "stage" : "FETCH",              "inputStage" : {                  "stage" : "IXSCAN",                  "keyPattern" : {                      "age" : 1                  },                  "indexName" : "age_1",                  "isMultiKey" : false,                  "isUnique" : false,                  "isSparse" : false,                  "isPartial" : false,                  "indexVersion" : 1,                  "direction" : "forward",                  "indexBounds" : {                      "age" : [                          "[18.0, 18.0]"                      ]                  }              }          },          "rejectedPlans" : [ ]      },      "serverInfo" : {          "host" : "localhost",          "port" : 9552,          "version" : "3.2.3",          "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"      },      "ok" : 1  }  </pre>    <h2>参考资料</h2>    <ul>     <li><a href="/misc/goto?guid=4959671518851309170" rel="nofollow,noindex">MongoDB索引介绍</a></li>     <li><a href="/misc/goto?guid=4959671517889872511" rel="nofollow,noindex">createIndex命令</a></li>     <li><a href="/misc/goto?guid=4959671518048163831" rel="nofollow,noindex">MongoDB Sharded Cluster</a></li>     <li><a href="/misc/goto?guid=4959671518277660144" rel="nofollow,noindex">唯一索引 (unique index)</a></li>     <li><a href="/misc/goto?guid=4959671518364215741" rel="nofollow,noindex">TTL索引</a></li>     <li><a href="/misc/goto?guid=4959671518436549193" rel="nofollow,noindex">部分索引 (partial index)</a></li>     <li><a href="/misc/goto?guid=4959671518521132022" rel="nofollow,noindex">稀疏索引(sparse index)</a></li>     <li><a href="/misc/goto?guid=4959671518595882222" rel="nofollow,noindex">database profiling</a></li>    </ul>    <p>来自: <a href="/misc/goto?guid=4959671518999616652" rel="nofollow">http://blog.yunnotes.net/index.php/mongodb-index-howto/</a> </p>    
 本文由用户 Hill_open 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1461568319242.html
MongoDB