MongoDB數據模型，支持每個事件，每個日期範圍的唯一訪問者

Question

我有多個網站，其中每個網站都有訪問者「觸發」我想跟蹤的多個事件。我從所有網站都記錄了這些事件，每個事件都填充了網站ID，事件名稱和用戶ID（爲了簡單起見，我們就這麼說）。

的要求：

1. 能夠得到，每網站-ID和事件名稱，許多獨特的訪問者是如何得到它。
2. 這也應該支持日期範圍（範圍內的獨特獨特訪客）。

我想用下面的數據模型（爲例）每創建「網站ID」的集合：

collection ev_{websiteId}: 
[ 
    { 
     _id: "error" 
     dailyStats: [ 
      { 
       _id: 20121005 <-- (yyyyMMdd int, should be indexed!) 
       hits: 5 
       users: [ 
         { 
          _id: 1, <-- should be indexed! 
          hits: 1 
         }, 
         { 
          _id: 2 
          hits: 3 
         }, 
         { 
          _id: 3, 
          hits: 1 
         } 
       ] 
      }, 
      { 
       _id: 20121004 
       hits: 8 
       users: [ 
         { 
          _id: 1, 
          hits: 2 
         }, 
         { 
          _id: 2 
          hits: 3 
         }, 
         { 
          _id: 3, 
          hits: 3 
         } 
       ] 
      }, 
     ] 
    }, 
    { 
     _id: "pageViews" 
     dailyStats: [ 
      { 
       _id: 20121005 
       hits: 500 
       users: [ 
         { 
          _id: 1, 
          hits: 100 
         }, 
         { 
          _id: 2 
          hits: 300 
         }, 
         { 
          _id: 3, 
          hits: 100 
         } 
       ] 
      }, 
      { 
       _id: 20121004 
       hits: 800 
       users: [ 
         { 
          _id: 1, 
          hits: 200 
         }, 
         { 
          _id: 2 
          hits: 300 
         }, 
         { 
          _id: 3, 
          hits: 300 
         } 
       ] 
      }, 
     ] 
    }, 
] 

我使用_id頭籌-ID。 我使用dailyStats._id來保存它發生的時間（yyyyMMdd格式的整數）。 我使用dailySattes.users._id來表示用戶的唯一標識哈希值。

爲了獲得唯一的用戶，我應該基本上能夠在給定的日期範圍內運行（mapreduce？）不同數量的項目數量（我將日期範圍轉換爲yyyyMMdd） 。

我的問題：

1. 做這個數據模型是有道理的嗎？我擔心隨着時間的推移這種模式的可擴展性（如果我在某些客戶端擁有大量的每日獨立訪問者，它會導致一個巨大的文檔）。 我正在考慮通過_id <刪除dailyStats文檔[日期爲yyyyMMdd]。通過這種方式，我可以將我的文檔大小保持爲一個理智的數字，但仍然存在限制。
2. 是否有一種簡單的方法來運行「upsert」，如果尚未創建，還會創建dailyStats，添加用戶（如果尚未創建併爲兩者增加「hits」屬性？
3. 那麼map-reduce呢？你將如何處理它（需要針對給定日期範圍內的所有子文檔在users._id上運行不同）？新聚合框架有沒有更簡單的方法？

btw - 解決獨特訪問者的另一個選擇是使用Redis Bitmaps，但我不確定值得擁有多個數據存儲（維護方面）。

Answer 1

對當前上述架構的評論很少。

我有點擔心，因爲你已經指出了可擴展性以及你實際做了多少預集合。

我在做指標時使用過的大多數Mongo實例都與您指出的情況類似，但您確實似乎非常依賴更新單個文檔並插入其中的各個部分減慢速度並可能導致一點鎖定。

我可能會建議一條不同的路徑，Mongo甚至建議在與他們談論做指標時建議。看到你已經有了，你希望做我想創建沿東西線的結構：

{ 
    "_id":"20121005_siteKey_page", 
    "hits":512, 
    "users":[ 
    { 
    "uid":5, 
    "hits":512, 
    } 
} 

這樣就會限制你的文件大小的東西，將是合理的做快插入。從這裏你可以批量做mapreduce作業，以進一步擴展你想要看到的內容。

這也取決於您的最終目標，您是否希望提供實時指標？你試圖得到什麼樣的粒度？ Redis地圖可能是您至少想要看的東西：偉大的文章here。

無論這是一個有趣的問題，要解決:)

希望這有助於！