背景說(shuō)明

進(jìn)化過(guò)程

在這里使用python演示

最直接想到的方法

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

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

減少查詢(xún)次數(shù)

瓶頸顯而易見(jiàn)，在循環(huán)中查詢(xún)Collection B，增加了網(wǎng)絡(luò)開(kāi)銷(xiāo)，自然也就增加時(shí)間，如果一次查詢(xún)出所有結(jié)果，自然會(huì)大大提高效率。也就是說(shuō)，我要把第一步的結(jié)果作為條件一次性傳遞，做一個(gè)$in操作。可是怎么才能做到呢？如果在uid和date上分別做$in操作，那么返回的結(jié)果就會(huì)是二者單獨(dú)做$操作的合集，很顯然這和要求是不符的。 經(jīng)過(guò)上面的分析，似乎進(jìn)入了死胡同。其實(shí)答案也基本顯現(xiàn)了，需要有一個(gè)字段可以滿(mǎn)足上面的要求，那么這個(gè)字段就是uid和date的合體，就命名為uid_date。uid_date是一個(gè)新字段，在B中并不存在，在使用之前需要將數(shù)據(jù)庫(kù)現(xiàn)有的數(shù)據(jù)做一下處理。處理完畢改造程序：

這一番改造頗費(fèi)時(shí)間，主要是前期的數(shù)據(jù)處理。代碼改造完畢，執(zhí)行下看看吧。 可是，可是…… 45秒 我做錯(cuò)了什么？！

增加返回記錄數(shù)

我還是堅(jiān)信上面的優(yōu)化思路是對(duì)的，現(xiàn)在看看數(shù)據(jù)庫(kù)能給一些什么線(xiàn)索吧。 登錄到數(shù)據(jù)庫(kù)服務(wù)器，找到MongoDB的日志/data/mongodb/logs/mongod.log。仔細(xì)查找，發(fā)現(xiàn)在查詢(xún)數(shù)據(jù)集B時(shí)有很多getMore命令。這就奇怪了，我是一次性查詢(xún)，為什么還有g(shù)etMore。趕緊查下官方的文檔，然后發(fā)現(xiàn)了下面的內(nèi)容： batcSize參數(shù)指定了每次返回的個(gè)數(shù)，默認(rèn)的101個(gè)。那看來(lái)這個(gè)應(yīng)該是問(wèn)題所在。找下pymongo的文檔，也可以設(shè)置這個(gè)參數(shù)，那就設(shè)個(gè)大的吧10000。再次改造程序如下：

這次總該可以了。

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

返回值減負(fù)

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

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