mongodb - 針對大量數據點的推薦樹結構

我正在開發一個項目，該項目記錄跨多個地區的物品的價格歷史記錄，並且計劃將這些數據存儲在一個mongodb集合中。mongodb - 針對大量數據點的推薦樹結構

因爲我對mongodb比較陌生，所以我對很多數據的推薦文檔結構感興趣。情況如下：

我在200個左右的地區記錄約90,000項物品的價格歷史記錄。我期望每小時記錄每件商品的價格，並給出任何特定商品的2周曆史記錄。大約出現（90000 * 200 * 24 * 14）= 60億個數據點，或者大約67200個數據點。清理查詢將每天運行一次，以刪除超過14天的記錄（更具體地說，將其歸檔爲壓縮的json /文本文件）。

就我所知道的數據而言，我主要關注兩件事情：1）特定地區特定商品的價格歷史記錄; 2）特定商品的價格歷史記錄遍及所有地區。

在我真正開始導入這些數據並運行基準測試之前，我希望有人能夠給出一些建議，說明如何構建這個數據庫以允許通過查詢快速訪問數據。

我正在考慮以下結構：

{ 
    _id: 1234, 
    data: [ 
     { 
      territory: "A", 
      price: 5678, 
      time: 123456789 
     }, 
     { 
      territory: "B", 
      price: 9876 
      time: 123456789 
     } 
    ] 
}

每個項目都是自己的文件，其中每個區域/價格點在特定領土該項目。我遇到的問題是檢索特定商品的價格歷史記錄。我相信我可以用下面的查詢實現這一點：

db.collection.aggregate(
    {$unwind: "$data"}, 
    {$match: {_id: 1234, "data.territory": "B"}} 

)

我正在考慮只是把每一個數據點自己的文檔中，然後將一個指數的項目和境內的其他選擇。

// Document 1 
{ 
    item: 1234, 
    territory: "A", 
    price: 5679, 
    time: 123456789 
} 
// Document 2 
{ 
    item: 1234, 
    territory: "B", 
    price: 9676, 
    time: 123456789 
}

我只是不確定是否具有6個十億文件用三個指標或與67200對象數組90000個文檔每使用聚合會獲得更好的性能。

或者也許有其他一些樹結構或處理這個問題，你罰款人和MongoDB嚮導可以推薦？

來源

2014-10-21 user2421024

這是一個有點主觀，真的應該回答，但問自己「你通過保持物品在數組中獲得什麼好處？」。在MongoDB中使用數組的一般想法是將相關數據以這種方式存儲在一起。這意味着如果您使用單個文檔並將所有或多個數組點一起讀取/寫入，然後使用數組。如果不是那麼陣列不是最好的選擇。銷售訂單和項目是一個很好的選擇，但其他的事情可能不會。 – 2014-10-22 01:43:19

我會將文檔的結構設置爲「每個固定時間間隔內給定區域內產品的價格」。整個模式的時間間隔是固定的，但不同的模式是由不同的選擇產生的，對於您的應用程序來說最好的模式可能需要通過測試來決定。選擇時間間隔爲1小時可以得出第二個模式構思，總共約60億個文檔。你可以選擇時間間隔爲2周（不）。在我看來，最好的時間間隔的選擇是1天，這樣的文件看起來像這樣

{ 
    "_id" : ObjectId(...), // could also use a combination of prod_id, terr_id, and time so you get a free unique index to look up by those 3 values 
    "prod_id" : "DEADBEEF", 
    "terr_id" : "FEEDBEAD", 
    "time" : ISODate("2014-10-22T00:00:00.000Z"), // start of the day this document contains the data for 
    "data" : [ 
     { 
      "price" : 1234321, 
      "time" : ISODate("2014-10-22T15:00:00.000Z") // start of the hour this data point is for 
     }, 
     ... 
    ] 
}

我喜歡1天的時間間隔，因爲它擊中的文檔數量之間一個很好的平衡（主要是因爲相關的索引大小），文檔大小（16MB限制，必須通過網絡傳輸）以及便捷的退休舊文檔（15天保存，每天從某一時刻的第15天開始清除）。如果你把索引放在{ "prod_id" : 1, "terr_id" :}上，那應該讓你有效地完成你的兩個主要查詢。通過爲每一天預先分配文檔，您可以獲得額外的獎勵性能提升，以便更新到位。

根據建立MMS監控系統的經驗，有關於管理像這樣的時間序列數據的great blog post。我基本上從那裏解除了我的想法。

來源

2014-10-22 15:33:55 wdberkeley

mongodb - 針對大量數據點的推薦樹結構

回答

相關問題