MongoDB學習八--MongoDB的索引操作

Indexes support the efficient execution of queries in MongoDB. Without indexes, MongoDB must perform acollection scan, i.e. scan every document in a collection, to select those documents that match the query statement. If an appropriate index exists for a query, MongoDB can use the index to limit the number of documents it must inspect.

Indexes are special data structures [1] that store a small portion of the collection’s data set in an easy to traverse form. The index stores the value of a specific field or set of fields, ordered by the value of the field. The ordering of the index entries supports efficient equality matches and range-based query operations. In addition, MongoDB can return sorted results by using the ordering in the index.

The following diagram illustrates a query that selects and orders the matching documents using an index:

Diagram of a query that uses an index to select and return sorted results. The index stores ``score`` values in ascending order. MongoDB can traverse the index in either ascending or descending order to return sorted results.

Fundamentally, indexes in MongoDB are similar to indexes in other database systems. MongoDB defines indexes at the collection level and supports indexes on any field or sub-field of the documents in a MongoDB collection.

[1] MongoDB indexes use a B-tree data structure.

Index Types

MongoDB provides a number of different index types to support specific types of data and queries.

Default _id

All MongoDB collections have an index on the _id field that exists by default. If applications do not specify a value for _id the driver or the mongod will create an _id field with an ObjectId value.

The _id index is unique and prevents clients from inserting two documents with the same value for the _idfield.

Single Field

In addition to the MongoDB-defined _id index, MongoDB supports the creation of user-defined ascending/descending indexes on a single field of a document.

Diagram of an index on the ``score`` field (ascending).

For a single-field index and sort operations, the sort order (i.e. ascending or descending) of the index key does not matter because MongoDB can traverse the index in either direction.

See Single Field Indexes and Sort with a Single Field Index for more information on single-field indexes.

Compound Index

MongoDB also supports user-defined indexes on multiple fields, i.e. compound indexes.

The order of fields listed in a compound index has significance. For instance, if a compound index consists of{ userid: 1, score: -1 }, the index sorts first by userid and then, within each userid value, sorts by score.

Diagram of a compound index on the ``userid`` field (ascending) and the ``score`` field (descending). The index sorts first by the ``userid`` field and then by the ``score`` field.

For compound indexes and sort operations, the sort order (i.e. ascending or descending) of the index keys can determine whether the index can support a sort operation. See Sort Order for more information on the impact of index order on results in compound indexes.

See Compound Indexes and Sort on Multiple Fields for more information on compound indexes.

Multikey Index

MongoDB uses multikey indexes to index the content stored in arrays. If you index a field that holds an array value, MongoDB creates separate index entries for every element of the array. These multikey indexes allow queries to select documents that contain arrays by matching on element or elements of the arrays. MongoDB automatically determines whether to create a multikey index if the indexed field contains an array value; you do not need to explicitly specify the multikey type.

Diagram of a multikey index on the ``addr.zip`` field. The ``addr`` field contains an array of address documents. The address documents contain the ``zip`` field.

See Multikey Indexes and Multikey Index Bounds for more information on multikey indexes.

Geospatial Index

To support efficient queries of geospatial coordinate data, MongoDB provides two special indexes: 2d indexes that uses planar geometry when returning results and 2sphere indexes that use spherical geometry to return results.

See 2d Index Internals for a high level introduction to geospatial indexes.

Text Indexes

MongoDB provides a text index type that supports searching for string content in a collection. These text indexes do not store language-specific stop words (e.g. “the”, “a”, “or”) and stem the words in a collection to only store root words.

See Text Indexes for more information on text indexes and search.

Hashed Indexes

To support hash based sharding, MongoDB provides a hashed index type, which indexes the hash of the value of a field. These indexes have a more random distribution of values along their range, but only support equality matches and cannot support range-based queries.

Index Properties

Unique Indexes

The unique property for an index causes MongoDB to reject duplicate values for the indexed field. Other than the unique constraint, unique indexes are functionally interchangeable with other MongoDB indexes.

Sparse Indexes

The sparse property of an index ensures that the index only contain entries for documents that have the indexed field. The index skips documents that do not have the indexed field.

You can combine the sparse index option with the unique index option to reject documents that have duplicate values for a field but ignore documents that do not have the indexed key.

TTL Indexes

TTL indexes are special indexes that MongoDB can use to automatically remove documents from a collection after a certain amount of time. This is ideal for certain types of information like machine generated event data, logs, and session information that only need to persist in a database for a finite amount of time.

See: Expire Data from Collections by Setting TTL for implementation instructions.

Index Use

Indexes can improve the efficiency of read operations. The Analyze Query Performance tutorial provides an example of the execution statistics of a query with and without an index.

For information on how MongoDB chooses an index to use, see query optimizer.

Covered Queries

When the query criteria and the projection of a query include only the indexed fields, MongoDB will return results directly from the index without scanning any documents or bringing documents into memory. These covered queries can be very efficient.

Diagram of a query that uses only the index to match the query criteria and return the results. MongoDB does not need to inspect data outside of the index to fulfill the query.

For more information on covered queries, see Covered Query.

Index Intersection

New in version 2.6.

MongoDB can use the intersection of indexes to fulfill queries. For queries that specify compound query conditions, if one index can fulfill a part of a query condition, and another index can fulfill another part of the query condition, then MongoDB can use the intersection of the two indexes to fulfill the query. Whether the use of a compound index or the use of an index intersection is more efficient depends on the particular query and the system.

具體操作:

1,插入15W條數據

for(var i=0;i<150000;i++){ var rand=parseInt(i*Math.random()); db.person.insert({"name":"Lily"+i,"age":i,"rand":rand}) }

insert 15W data

插入好像消耗時間3分鐘

2,性能分析函數(explain)

利用mongodb中給我們提供了一個關鍵字叫做“explain"做性能分析看圖,注意,這裏的name字段沒有建立任何索引,這裏我就查詢一個“name10000”的姓名。3.0.5的要在explain()中加關鍵字纔有統計數據返回, db.person.find({"name":"Lily"+11000}).explain("executionStats")

explain

"executionTimeMillis" : 64,這個就是我們最最最....關心的東西,總共耗時85毫秒。

"totalDocsExamined" : 150000,  數據總量

"nReturned" : 1, 這裏是1,也就是最終返回了1個文檔。

3,建立索引(ensureIndex)

在15w條這麼簡單的集合中查找一個文檔要85毫秒,是不太快,那麼我們該如何優化呢?mongodb中給我們帶來了索引查找,看看能不能讓我們的查詢一飛沖天.....db.person.createIndex({"name":1})

createindex

search by index

看看結果,Oh,My,God ~不能直視了,紅框處~——~

這裏我們使用了createIndex在name上建立了索引。”1“:表示按照name進行升序,”-1“:表示按照name進行降序。

我的神啊,再來看看這些敏感信息。擦,數據庫只瀏覽了一個文檔;看看這個時間真的不敢相信,秒秒殺。

4,唯一索引

和sqlserver一樣都可以建立唯一索引,重複的鍵值自然就不能插入,在mongodb中的使用方法是:

db.person.createIndex({"name":1},{"unique":true})

index error

報錯了,要先刪除已存在的在此字段上的索引 db.person.dropIndex("name_1")

unique index

建索引成功

unique index

5,組合索引

有時候我們的查詢不是單條件的,可能是多條件,比如按年齡查找同學,那麼我們可以建立“姓名”和"年齡的聯合索引來加速查詢。查詢創建的索引db.person.getIndexes()

getIndexes

創建兩個組合索引db.person.createIndex({"name":1,"age":1})   db.person.createIndex({"age":1,"name":1})

indexes

此時我們肯定很好奇,到底查詢優化器會使用哪個查詢作爲操作,呵呵,還是看看效果圖:

db.person.find({"age":149938,"name":"Lily149938"}).explain("executionStats"); 可以看到用的還是name_1的索引

90

看來還得再測試,再建兩個組合索引db.person.createIndex({"rand":1,"age":1}) db.person.createIndex({"age":1,"rand":1})

執行統計分析,好像都是用的一個索引db.person.find({"age":149957,"rand":104550}).explain("executionStats");db.person.find({"rand":89541,"age":149938}).explain("executionStats");

df

看完上圖我們要相信查詢優化器,它給我們做出的選擇往往是最優的,因爲我們做查詢時,查詢優化器會使用我們建立的這些索引來創建查詢方案,如果某一個先執行完則其他查詢方案被close掉,這種方案會被mongodb保存起來,當然如果非要用自己指定的查詢方案,這也是可以的,在mongodb中給我們提供了hint方法讓我們可以暴力執行。db.person.find({"age":149957,"rand":104550}).hint({"age":1,"rand":1}).explain("executionStats");

dfg

6,刪除索引

可能隨着業務需求的變化,原先建立的索引可能沒有存在的必要了,可能有的人想說沒必要就沒必要唄,但是請記住,索引會降低CUD這三
種操作的性能,因爲這玩意需要實時維護,所以啥問題都要綜合考慮一下,這裏就把剛纔建立的索引清空掉db.person.dropIndex("name_1_age_1")


發佈了32 篇原創文章 · 獲贊 14 · 訪問量 17萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章