前言
數據庫性能對軟件整體性能有著至關重要的影響，本文給大家分享了一次MongoDB數據庫查詢性能提高40倍的經歷，感興趣的朋友們可以參考學習。
背景說明
1、數據庫：MongoDB
2、數據集：
3、業務場景：求平均數
進化過程
在這里使用Python演示
最直接想到的方法
根據上面的業務場景描述，最容易想到的解決方法就是
from pymongo import MongoClient# 連接數據庫db = MongoClient('mongodb://127.0.0.1:27017')['my_db']# 簡化的查詢數據集A的條件filter = {...}# 查詢Collection Aa_cursor = db.a.find(_filter)a_docs = [x for x in a_cursor]# 變量的初始定義count = 0total = 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']}) # 只有能查到相應的結果時，才可以 if b_doc is not None: total += b_doc['actions'][20]['number'] count += 1 # 求平均數 if count > 0 : avg = total/count實現難度當然是最低的，可是整個任務在第一步只有1萬條左右的返回時，消耗的時間竟然達到了驚人38秒。當然這是已經加了索引的結果，否則可能都無法得到結果了。
減少查詢次數
瓶頸顯而易見，在循環中查詢Collection B，增加了網絡開銷，自然也就增加時間，如果一次查詢出所有結果，自然會大大提高效率。也就是說，我要把第一步的結果作為條件一次性傳遞，做一個$in操作?？墒窃趺床拍茏龅侥?？如果在uid和date上分別做$in操作，那么返回的結果就會是二者單獨做$操作的合集，很顯然這和要求是不符的。
經過上面的分析，似乎進入了死胡同。其實答案也基本顯現了，需要有一個字段可以滿足上面的要求，那么這個字段就是uid和date的合體，就命名為uid_date。uid_date是一個新字段，在B中并不存在，在使用之前需要將數據庫現有的數據做一下處理。
處理完畢改造程序：
# 下面的只體現和本次修改相關的內容uid_date_list = []for a_doc in a_docs: uid_date_list.append(a_doc['uid'] + '_' + a_doc['date'])# 查詢Bb_cursor = db.b.find({'uid_date':{'$in':uid_date_list}})# 下面就是取出結果，求平均數...這一番改造頗費時間，主要是前期的數據處理。代碼改造完畢，執行下看看吧。
可是，可是…… 45秒
我做錯了什么？！
增加返回記錄數
我還是堅信上面的優化思路是對的，現在看看數據庫能給一些什么線索吧。
登錄到數據庫服務器，找到MongoDB的日志/data/mongodb/logs/mongod.log。仔細查找，發現在查詢數據集B時有很多getMore命令。這就奇怪了，我是一次性查詢，為什么還有getMore。
趕緊查下官方的文檔，然后發現了下面的內容：
batcSize參數指定了每次返回的個數，默認的101個。那看來這個應該是問題所在。找下pymongo的文檔，也可以設置這個參數，那就設個大的吧10000。
再次改造程序如下：
# 增加batch_sizeb_cursor = db.b.find({'uid_date':{'$in': uid_date_list}}, batch_size=10000)這次總該可以了。
嗯，好了一些，降到了20秒左右?？墒?，這離1秒只能還差距20倍呢。
返回值減負
當日不能放棄，繼續通過日志查找線索，發現還是有很多getMore。通過各方查找，發現mongodb每次最多返回16M的記錄，通過getMore日志的比對，發現的確如此。由于B中每條記錄的過去龐大，每次只能幾百條記錄，因此要一次多返回，那就必須要減少每次返回的記錄數。因為在計算時，只用了特定索引位置上的數據，所以只返回該條記錄就可以了。
最后的代碼就不再寫了，具體可以參考官方文檔的實例。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流。
新聞熱點
疑難解答
