前言

數(shù)據(jù)庫性能對軟件整體性能有著至關(guān)重要的影響，本文給大家分享了一次MongoDB數(shù)據(jù)庫查詢性能提高40倍的經(jīng)歷，感興趣的朋友們可以參考學(xué)習(xí)。

背景說明

1、數(shù)據(jù)庫：MongoDB

2、數(shù)據(jù)集：

• A：字段數(shù)不定，這里主要用到的兩個UID和Date
• B：三個字段，UID、Date、Actions。其中Actions字段是包含260元素JSON數(shù)組，每個JSON對象有6個字段。共有數(shù)據(jù)800萬條左右。
  

3、業(yè)務(wù)場景：求平均數(shù)

• 通過組合條件從A數(shù)據(jù)表查詢出（UID，Date）列表，最多可能包含數(shù)萬條記錄；
• 然后用第1步的結(jié)果從B中查詢出對應(yīng)的數(shù)據(jù)
• 用第2步結(jié)果去Actions的某個固定位置的元素的進行計算
  

進化過程

在這里使用Python演示

最直接想到的方法

根據(jù)上面的業(yè)務(wù)場景描述，最容易想到的解決方法就是

from pymongo import MongoClient
# 連接數(shù)據(jù)庫
db = MongoClient('mongodb://127.0.0.1:27017')['my_db']

# 簡化的查詢數(shù)據(jù)集A的條件
filter = {...}
# 查詢Collection A
a_cursor = db.a.find(_filter)
a_docs = [x for x in a_cursor]

# 變量的初始定義
count = 0
total = 0
# 加入需要用到的元素為第21個
index = 20
# 查詢Collection B，同時做累加
for a_doc in a _docs:
 b_doc = db.b.find_one({'uid':a_doc['uid'], 'date': a_doc['date']})
 # 只有能查到相應(yīng)的結(jié)果時，才可以
 if b_doc is not None:
 total += b_doc['actions'][20]['number']
 count += 1

 # 求平均數(shù)
 if count > 0 :
 avg = total/count

實現(xiàn)難度當然是最低的，可是整個任務(wù)在第一步只有1萬條左右的返回時，消耗的時間竟然達到了驚人38秒。當然這是已經(jīng)加了索引的結(jié)果，否則可能都無法得到結(jié)果了。

減少查詢次數(shù)

瓶頸顯而易見，在循環(huán)中查詢Collection B，增加了網(wǎng)絡(luò)開銷，自然也就增加時間，如果一次查詢出所有結(jié)果，自然會大大提高效率。也就是說，我要把第一步的結(jié)果作為條件一次性傳遞，做一個$in操作?？墒窃趺床拍茏龅侥?？如果在uid和date上分別做$in操作，那么返回的結(jié)果就會是二者單獨做$操作的合集，很顯然這和要求是不符的。

經(jīng)過上面的分析，似乎進入了死胡同。其實答案也基本顯現(xiàn)了，需要有一個字段可以滿足上面的要求，那么這個字段就是uid和date的合體，就命名為uid_date。uid_date是一個新字段，在B中并不存在，在使用之前需要將數(shù)據(jù)庫現(xiàn)有的數(shù)據(jù)做一下處理。

處理完畢改造程序：

# 下面的只體現(xiàn)和本次修改相關(guān)的內(nèi)容
uid_date_list = []
for a_doc in a_docs:
 uid_date_list.append(a_doc['uid'] + '_' + a_doc['date'])

# 查詢B
b_cursor = db.b.find({'uid_date':{'$in':uid_date_list}})

# 下面就是取出結(jié)果，求平均數(shù)
...

這一番改造頗費時間，主要是前期的數(shù)據(jù)處理。代碼改造完畢，執(zhí)行下看看吧。

可是，可是…… 45秒

我做錯了什么？！

增加返回記錄數(shù)

我還是堅信上面的優(yōu)化思路是對的，現(xiàn)在看看數(shù)據(jù)庫能給一些什么線索吧。

登錄到數(shù)據(jù)庫服務(wù)器，找到MongoDB的日志/data/mongodb/logs/mongod.log。仔細查找，發(fā)現(xiàn)在查詢數(shù)據(jù)集B時有很多getMore命令。這就奇怪了，我是一次性查詢，為什么還有g(shù)etMore。

趕緊查下官方的文檔，然后發(fā)現(xiàn)了下面的內(nèi)容：

batcSize參數(shù)指定了每次返回的個數(shù)，默認的101個。那看來這個應(yīng)該是問題所在。找下pymongo的文檔，也可以設(shè)置這個參數(shù)，那就設(shè)個大的吧10000。

再次改造程序如下：

# 增加batch_size
b_cursor = db.b.find({'uid_date':{'$in': uid_date_list}}, batch_size=10000)

這次總該可以了。

嗯，好了一些，降到了20秒左右?？墒?，這離1秒只能還差距20倍呢。

返回值減負

當日不能放棄，繼續(xù)通過日志查找線索，發(fā)現(xiàn)還是有很多getMore。通過各方查找，發(fā)現(xiàn)mongodb每次最多返回16M的記錄，通過getMore日志的比對，發(fā)現(xiàn)的確如此。由于B中每條記錄的過去龐大，每次只能幾百條記錄，因此要一次多返回，那就必須要減少每次返回的記錄數(shù)。因為在計算時，只用了特定索引位置上的數(shù)據(jù)，所以只返回該條記錄就可以了。

最后的代碼就不再寫了，具體可以參考官方文檔的實例。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流。