當你抱怨mongodb集合查詢效率低的時候,可能你就需要考慮使用索引了,為了方便後續介紹,先科普下mongodb裡的索引機制(同樣適用於其他的資料庫比如mysql)。
mongo-9552:primary> db.person.find()
當你往某各個集合插入多個文件後,每個文件在經過底層的儲存引擎持久化後,會有乙個位置資訊,通過這個位置資訊,就能從儲存引擎裡讀出該文件。比如mmapv1引擎裡,位置資訊是『檔案id + 檔案內offset 』
, 在wiredtiger儲存引擎(乙個kv儲存引擎)裡,位置資訊是wiredtiger在儲存文件時生成的乙個key,通過這個key能訪問到對應的文件;為方便介紹,統一用pos(position的縮寫)
來代表位置資訊。
比如上面的例子裡,person
集合裡包含插入了4個文件,假設其儲存後位置資訊如下(為方便描述,文件省去_id欄位)
位置資訊
文件pos1
pos2
pos3
pos4
pos5
假設現在有個查詢db.person.find( )
, 查詢所有年齡為18歲的人,這時需要遍歷所有的文件(『全表掃瞄』),根據位置資訊讀出文件,對比age欄位是否為18。當然如果只有4個文件,全表掃瞄的開銷並不大,但如果集合文件數量到百萬、甚至千萬上億的時候,對集合進行全表掃瞄開銷是非常大的,乙個查詢耗費數十秒甚至幾分鐘都有可能。
如果想加速db.person.find( )
,就可以考慮對person表的age欄位建立索引。
db.person.createindex( ) // 按age欄位建立公升序索引
建立索引後,mongodb會額外儲存乙份按age欄位公升序排序的索引資料,索引結構類似如下,索引通常採用類似btree的結構持久化儲存,以保證從索引裡快速(o(logn)的時間複雜度
)找出某個age值對應的位置資訊,然後根據位置資訊就能讀取出對應的文件。
age位置資訊
18pos3
18pos5
19pos1
20pos2
21pos4
簡單的說,索引就是將文件
按照某個(或某些)字段順序組織起來,以便能根據該欄位高效的查詢。有了索引,至少能優化如下場景的效率:
眾所周知,mongodb缺省會為插入的文件生成_id欄位(如果應用本身沒有指定該欄位),_id是文件唯一的標識,為了保證能根據文件id快遞查詢文件,mongodb缺省會為集合建立_id欄位的索引。
mongo-9552:primary> db.person.getindexes() // 查詢集合的索引資訊[ ,
"name" : "_id_" // 索引的名稱
}]
mongodb支援多種型別的索引,包括單字段索引、復合索引、多key索引、文字索引等,每種型別的索引有不同的使用場合。
db.person.createindex( )
上述語句針對age建立了單字段索引,其能加速對age欄位的各種查詢請求,是最常見的索引形式,mongodb預設建立的id索引也是這種型別。
代表公升序索引,也可以通過來指定降序索引,對於單字段索引,公升序/降序效果是一樣的。
復合索引是single field index的公升級版本,它針對多個字段聯合建立索引,先按第乙個字段排序,第乙個字段相同的文件按第二個字段排序,依次類推,如下針對age, name這2個字段建立乙個復合索引。
db.person.createindex( )
上述索引對應的資料組織類似下表,與索引不同的時,當age欄位相同時,在根據name欄位進行排序,所以pos5對應的文件排在pos3之前。
age位置資訊
18pos5
18pos3
19pos1
20pos2
21pos4
復合索引能滿足的查詢場景比單字段索引更豐富,不光能滿足多個字段組合起來的查詢,比如db.person.find( )
,也能滿足所以能匹配符合索引字首的查詢,這裡即為的字首,所以類似db.person.find( )
的查詢也能通過該索引來加速;但db.person.find( )
則無法使用該復合索引。如果經常需要根據『name欄位』以及『name和age欄位組合』來查詢,則應該建立如下的復合索引
db.person.createindex( )
除了查詢的需求能夠影響索引的順序,欄位的值分布也是乙個重要的考量因素,即使person集合所有的查詢都是『name和age欄位組合』(指定特定的name和age),欄位的順序也是有影響的。
age欄位的取值很有限,即擁有相同age欄位的文件會有很多;而name欄位的取值則豐富很多,擁有相同name欄位的文件很少;顯然先按name欄位查詢,再在相同name的文件裡查詢age欄位更為高效。
當索引的字段為陣列時,建立出的索引稱為多key索引,多key索引會為陣列的每個元素建立一條索引,比如person表加入乙個habbit欄位(陣列)用於描述興趣愛好,需要查詢有相同興趣愛好的人就可以利用habbit欄位的多key索引。
db.person.createindex( ) // 自動建立多key索引
db.person.find( )
雜湊索引(hashed index)是指按照某個欄位的hash值來建立索引,目前主要用於mongodb sharded cluster的hash分片,hash索引只能滿足字段完全匹配的查詢,不能滿足範圍查詢等。
地理位置索引(geospatial index)能很好的解決o2o的應用場景,比如『查詢附近的美食』、『查詢某個區域內的車站』等。
文字索引(text index)能解決快速文字查詢的需求,比如有乙個部落格文章集合,需要根據部落格的內容來快速查詢,則可以針對部落格內容建立文字索引。
mongodb除了支援多種不同型別的索引,還能對索引定製一些特殊的屬性。
mongodb支援對db的請求進行profiling,目前支援3種級別的profiling。
通常,生產環境建議使用1級別的profiling,並根據自身需求配置合理的閾值,用於監測慢請求的情況,並及時的做索引優化。
如果能在集合建立的時候就能『根據業務查詢需求決定應該建立哪些索引』,當然是最佳的選擇;但由於業務需求多變,要根據實際情況不斷的進行優化。索引並不是越多越好,集合的索引太多,會影響寫入、更新的效能,每次寫入都需要更新所有索引的資料;所以你system.profile裡的慢請求可能是索引建立的不夠導致,也可能是索引過多導致。
索引已經建立了,但查詢還是很慢怎麼破?這時就得深入的分析下索引的使用情況了,可通過檢視下詳細的查詢計畫來決定如何優化。通過執行計畫可以看出如下問題
根據某個/些字段查詢,但沒有建立索引
根據某個/些字段查詢,但建立了多個索引,執行查詢時沒有使用預期的索引。
建立索引前,db.person.find( )
必須執行collscan,即全表掃瞄。
mongo-9552:primary> db.person.find().explain()
},"winningplan" :
},"direction" : "forward"
},"rejectedplans" : [ ]
}, "serverinfo" : ,
"ok" : 1
}
建立索引後,通過查詢計畫可以看出,先進行ixscan(從索引中查詢),然後fetch,讀取出滿足條件的文件。
mongo-9552:primary> db.person.find().explain()
},"winningplan" : ,
"indexname" : "age_1",
"ismultikey" : false,
"isunique" : false,
"issparse" : false,
"ispartial" : false,
"indexversion" : 1,
"direction" : "forward",
"indexbounds" : }},
"rejectedplans" : [ ]
}, "serverinfo" : ,
"ok" : 1
}
MongoDB索引原理
當你抱怨mongodb集合查詢效率低的時候,可能你就需要考慮使用索引了,為了方便後續介紹,先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後,每個文件在經過底層的儲存引擎持久化後...
MongoDB索引原理
當你抱怨mongodb集合查詢效率低的時候,可能你就需要考慮使用索引了,為了方便後續介紹,先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後,每個文件在經過底層的儲存引擎持久化後...
MongoDB索引原理
當你抱怨mongodb集合查詢效率低的時候,可能你就需要考慮使用索引了,為了方便後續介紹,先科普下mongodb裡的索引機制 同樣適用於其他的資料庫比如mysql mongo 9552 primary db.person.find 當你往某各個集合插入多個文件後,每個文件在經過底層的儲存引擎持久化後...