最佳架構設計用於在MongoDB中

日誌分析數據庫中，我有以下的數據存儲在MongoDB中uid, gender ,country, city, date_of_visit, url_of_visit最佳架構設計用於在MongoDB中

我想用來存儲UID，性別，國家和城市的一個集合，因爲這些信息不會針對特定改變用戶。

其他集合中

我想用來存儲uid, date_of_visit, url_of_visit

我想知道這是存儲uid, date_of_visit and url_of_visit。還有在我的腦海兩件事最佳實踐..

(a) { uid: 100, date: xxxxxxxxxxxxxxx, url: abc.php } 
     { uid: 100, date: xxxxxx, url: ref.php } 
     { uid: 200, date: xxxxxxxxx, url: ref.php } 

    (b) { uid:100, visit:[{date:xxxxxxx, url:abc.php}, 
          {date:xxxx, url:def.php}, 
          {.........................}]}

我想有下面的索引日期：1，uid：1，url：1 ...方法（a）的問題是在數據庫中插入每一行數據庫端和索引大小將增加，並且當索引大小不適合時會出現一個點進入內存

問題與方法（b）是在某些時候，每個文件將超過16 MB的限制，這種方法將失敗的時間..

請建議我什麼應該是這種情況下最好的模式設計。我也會有查詢，其中包括uid, gender, country, date_of_visit, url_of_visit

來源

2011-08-23 mark gill

我認爲第二種方法比一種更好，因爲它符合將相似數據分組在一起的想法。關於超過16M的文件，你可以達到這個限制，但他應該是一個非常活躍的用戶。 :)

此外，您可以將一些數據提取到另一個集合，並使用ObjectId或DBRef進行引用。查看更多信息http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef

來源

2011-08-23 10:45:15

出於好奇:)一個問題。隨着時間的推移，文檔大小將會增長，那麼對這些文檔（大尺寸文檔）的寫操作會很慢嗎？ –

這很難說，它取決於Mongo數據總量以及它如何適應內存。但我認爲沒關係，因爲在其他情況下，和以前的版本一樣，限制將會是8M。 –

我想隱藏Uid Bin數據並將其分配給_id字段。將uid設爲_id是個好主意嗎？我已閱讀過文檔「使用大致按升序排列的_id值」。並且我的uids值完全是隨機的 –

我知道這個線程有點老，但我想知道你是否決定了一個結構，如果它運作良好。

我的想法是，而不是冒着創建太大的文件的風險，結構它類似於你的第二種方法，但包括在主要集合中的日期。這樣每個文檔就會在一天內成爲用戶的活動。它將按用戶和日期進行索引，易於更新和查詢並保持組織結構。

喜歡的東西：

{ uid:100, date:xxxxxxx, event:[{time:xxxxxxx, url:abc.php}, 
           {time:xxxx, url:def.php}, 
           {.........................}]}

來源

2012-03-30 07:57:34 f10

你的第二個方法將迫使你從嵌入的文件，不能被蒙戈過濾取一個巨大的數據量。換句話說，如果有一百萬個文檔存儲在特定用戶的「事件」字段內，那麼當您使用點符號獲取這些嵌入文檔時，則會返回包含父文檔的整個文檔。您無法過濾結果。

我會推薦第一種方法，使數據更容易檢索和使用。

來源

2014-10-24 06:30:25

最佳架構設計用於在MongoDB中

回答

相關問題