記錄一次項目最佳化過程

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

  最近在用使用Parse來做資料收集的工作，後台是mongodb。有個需求要求對資料庫中已經收集的1000多萬使用者所在城市資料來分析出在規定時間段內，使用者城市變化的次數，從而確定該使用者是否為差旅使用者來做精準推送。邏輯分析這塊沒什麼好說的，重點在於插入資料庫階段。

第一個版本

  最開始的版本沒有想太多，按照常規思路來做的，就是資料分析完成後，根據使用者id發送請求向Parse查詢該使用者是否存在，如果不存在則插入，存在則比較使用者標籤是否有改動，沒有改動則跳過。代碼很快寫完，根據日誌顯示總資料在1100萬左右，最後統計出來的獨立使用者在600萬。看輸出請求挺慢的，於是下班後就讓指令碼在後台運行了。結果第二天早上過來看時發現才插入了300萬左右的資料。這個速度肯定是不行的，領導的意思是這個指令碼以後一星期跑一次，我們月活在1000萬左右，後期資料量大起來後，豈不是要跑幾天！於是我開始尋思最佳化的空間

第二個版本

  考慮到第一階段的資料統計階段耗費時間在數分鐘，時間主要耗費在parse請求上。於是在mongodb裡面對使用者id建了索引，同時在出入資料之前從統一從mongodb中到處資料緩衝起來。在記憶體中比較結果，有需要再插入，減少請求的次數。這次結果不錯，速度明顯快了很多，一天左右應該能跑完。但是這個結果我還是不能接受，所以又開始琢磨有沒有最佳化空間

第三個版本

  查看日誌探索資料處理還是很快的，時間主要耗費在了請求以及等待請求返回的時間。於是自然想到了多線程，利用多線程來從隊列中取資料發送請求。一開始開了2000個線程，結果一起來就掛沒辦法最後起了900個線程來跑。因為之前沒怎麼用python寫過代碼，用C++和golang比較多，尤其是golang裡面方便的協程和channel導致我都快忘記傳統的多線程應該怎麼寫了。被鎖搞得各種奔潰，不過結果不錯，清空所有資料重新匯入應該可以在1個小時內匯入完成。

第四個版本

  其實前面那個版本我已經比較滿意了，但是查看日誌的時候發現，資料處理隊列經常滿了，導致插入資料的線程經常掛起來回加解鎖。於是又去翻了Parse的介面文檔，看看有沒有大量匯入的介面結果還真讓我發現了。於是果然每次提交最大30個資料匯入。這個時候就發現900個線程已經出現有線程等待的情況，於是將批量導資料的數量從之前的1萬個增加到3萬個，這下差不多達到一個平衡了。時間也縮短到了30分鐘左右。

第五個版本

    第五個版本完全是意外來的，就是我在導資料時候順便開啟top看了下效能，結果發現32G的記憶體被這個指令碼吃掉了50%左右，而mongodb常駐也本身比較吃記憶體也佔了46%的空間，考慮到以後資料還有可能漲，這種將mongodb中的資料匯入到記憶體的方法似乎挺不妥的。思量過後，最後決定用迴圈迭代方式迭代資料，將取出來的資料和統計後的結果做比較，比較完成後再將該記錄從統計結果中刪除。最後統一處理統計結果中剩下的內容，這個基本上只需要批量插入就行了，不用考慮更新的事情。 這個版本算是比較完美的版本了，匯入時間在40分鐘左右，記憶體佔用在10%左右比之前大幅降低，時間也沒有增加很多。

總結

  生產者消費者模型雖然很常見但是在工程中還是一種很實用的方法的。面對這種大資料的處理工作其實一開始就應該想到利用多線程來發送請求，但是畢竟對Python不熟，多線程更是從來都沒用過就偷懶了。緩衝是個好東西但是真的太耗記憶體，同一個關鍵字應該考慮值緩衝一份，另一份採用即時提取的方式來做。