關於nosql優化，資料統計帶來的伺服器壓力解決

專案上會對使用者**資源的記錄進行資料打點，然後會對資料進行統計計算。使用者要查詢他自己的資源檢視記錄，這種操作如果使用者量特別大，那這個資料量就會相當龐大。目前資料已突破e級。當處理這些資料的時候就會遇到很多問題。當然我這裡處理的其實是通過加工後的資料。但是就算處理加工後的資料，查詢也相當的慢。

2：對資料進行分組秒算 20000組左右

3：對每組的資料進行計算加工秒算

4：與最後一次記錄做對比，再計算，再加工注：這期間就會出現問題了，因為這個操作是在迴圈內進行的。20000次查詢，乙個查詢就算用1秒這速度都是及其慢的。（記錄表300萬左右）

這裡其實問題就很明顯了：在迴圈內的單次查詢300萬級的表，我這邊耗時是15秒左右甚至更高。這就導致我們的統計極其的慢，而且極其的耗費mongodb伺服器的資源，甚至tomcat假死。

解決問題的辦法其實很簡單，加索引即可。但是在網上找了很久的資源，都沒有明確的指出合理的加索引的方式，和加索引會不會引發其他問題的資訊？

其實要解決這個問題也很簡單，我們用了最笨的辦法：模擬資料。在本地測試處理相當資料量的資料即可。

建立資料： 100w資料集合測試：無索引：10-15秒帶索引：5-10毫秒 1000w資料集合測試無索引：80-100秒帶索引：0.3-0.8秒 1e資料集合測試無索引：本地卡死帶索引：本地卡死 100w資料集合測試無索引：80-100秒排序列索引：120-200秒查詢列索引：0.3-0.8秒

測試：新增資料和查詢資料時建立索引無壓力，mongodb查詢和插入都正常

這裡其實看出乙個問題，就是如果你查詢時條件比較多，我這裡是四個欄位的查詢帶排序，單加排序索引其實是反效果。

建立索引的命令格式：

db.表名.createindex(,)

其實有朋友會問為什麼不開執行緒來跑那20000次的查詢，這裡說明一下本人這邊nosql沒有做集群，是單服務在跑資料量其實並不是非常大，還能撐住。在上線完成之後測試過，單執行緒跑20000次查詢，其實mongo伺服器的壓力就已經上來了，開多執行緒很可能會導致伺服器負載而引起不必要的麻煩。

上線後，在伺服器上的優化更明顯，之前統計這部分資料會耗時9小時左右，現在優化之後 4分鐘就跑完了，對應的是9小時的mongo負載減少，提公升是相當明顯的。

奉勸大家，在設計表的時候，一定要考慮到資料量的問題。如果這張表資料會超過十萬以上，那一定得先考慮索引的建立。