2014-02-07 36 views
0

我問this問題的報告已增加到另外三個子報表。
他們每個人都計數一些文件。緩慢工作的子報表(mongodb)

主要報告:

{ 
runCommand : { 
aggregate : 'Collection', 
pipeline : [ 
{ $match : { time : { '$gte' : '$P!{sttime}', '$lt' : '$P!{edtime}' }}}, 
{ $match : { owner_id : $P{id} } }, 
{ $match : { status : 0 } }, 
{ $group : { _id : { StatusID : '$status', SID : '$sid', UserID : '$owner_id', GroupID : '$group_id' }, count : { $sum : 1} } } 
     ] 
     } 
}  

用戶必須設置一個時限(時間戳類型日期的),並提供用戶,對於該報告將被填充。 然後選擇時間範圍,在每個子報表中傳輸owner_id和sid作爲參數。

子報表:

{ 
runCommand : { 
aggregate : 'Collection', 
pipeline : [ 
{ $match : { update_time : { '$gte' : '$P!{sttime}', '$lt' : '$P!{edtime}' }}}, 
{ $match : { sid : $P{sid} } }, 
{ $match : { owner_id : $P{id} } }, 
{ $match : { status : 1 } }, 
{ $group : { _id : { StatusID : '$status' }, count : { $sum : 1} } } 
     ] 
       }  
    } 

另一子報表與上述相同,不同之處{ $match : { status : 1 } },其中是這樣的:

{ $match : { status : 2 } } 

{ $match : { status : 3 } } 

分別。
我正在處理一個大集合,在2小時的時間範圍內約400.000個文檔。 報告顯示結果的最大時間幀爲8小時。 超過這段時間超過超時。 填寫「2小時時間表」大約需要10分鐘。 試圖單獨使用{explain:true}給每個請求。速度成績是寫作形式中最快的。

"cursor" : { 
          "cursor" : "BtreeCursor update_time_1_owner_id_1_status_1_group_id_1", 
          "isMultiKey" : false, 
          "n" : 379843, 
          "nscannedObjects" : 379843, 
          "nscanned" : 379843, 
          "nscannedObjectsAllPlans" : 379843, 
          "nscannedAllPlans" : 379843, 
          "scanAndOrder" : false, 
          "indexOnly" : false, 
          "nYields" : 13, 
          "nChunkSkips" : 0, 
          "millis" : 694, 

本示例在2小時的時間範圍內。
有什麼方法可以加快填寫報告?以某種方式統一查詢?或者是其他東西?
目標是增加一個月的可能期限報告(如果可能)

回答

0

MongoDB的2.4和更早的連續通話不合併到$match,所以你的第一個$match將使用索引和隨後的比賽將在內存上進行爲您的聚合管道獲取〜400k文檔。鑑於你有兩三個後續的$match操作,這個處理不會過於高效。

僅供參考,合併連續$match調用的問題MongoDB的2.6(見SERVER-11184)得到了解決,但爲了清楚起見,我覺得你還是會最佳$match報表做一個$explain之前組合。

而且,因爲你是在做update_time範圍查詢,你可能想在您的複合索引,後來移動,以平等的檢查上ownerstatus,並且group_id可以用來過濾範圍比較之前的結果。博客文章Optimizing MongoDB Compound Indexes對此方法有一些相關的解釋。