麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 數據庫 > MongoDB > 正文

MongoDB數據庫查詢性能提高40倍的經歷分享

2020-10-29 18:47:35
字體:
來源:轉載
供稿:網友

前言

數據庫性能對軟件整體性能有著至關重要的影響,本文給大家分享了一次MongoDB數據庫查詢性能提高40倍的經歷,感興趣的朋友們可以參考學習。

背景說明

1、數據庫:MongoDB

2、數據集:

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

3、業務場景:求平均數

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

進化過程

在這里使用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中每條記錄的過去龐大,每次只能幾百條記錄,因此要一次多返回,那就必須要減少每次返回的記錄數。因為在計算時,只用了特定索引位置上的數據,所以只返回該條記錄就可以了。

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

總結

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

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 欧美精品一区二区久久 | 女人久久久www免费人成看片 | 最污网站 | 国产在线一区二区三区 | 最近免费观看高清韩国日本大全 | 久久色播| 91短视频在线播放 | 久久久午夜电影 | av电影直播 | av电影在线观看免费 | 日韩精品久久久久久 | 久久人| 午夜视频在线免费播放 | 成人在线视频网 | 九九精品在线观看 | 古装三级在线观看 | 99精品视频99 | 91精品国产综合久久久动漫日韩 | 特级黄aaaaaaaaa毛片 | 欧美一级小视频 | 欧美精品第1页 | 久久99综合 | 91精品国产乱码久久桃 | 亚洲国产超高清a毛毛片 | 久久成人动漫 | 日韩做爰视频免费 | 黄色久| 亚洲一区二区三区高清视频 | 国产精品久久久久久久娇妻 | 色天使中文字幕 | 精精国产xxxx视频在线播放7 | 国产精品自拍啪啪 | 亚洲成人福利电影 | 国产小视频一区 | 免费在线观看成年人视频 | 亚洲精品无码不卡在线播放he | 国产亚洲精品久久久久久久久久 | 91精品国产777在线观看 | 美女性感毛片 | 久久最新免费视频 | 一级黄色片在线看 |