MongoDB性能：新聞源體系結構，訂閱者，評論

我使用MongoDB + PHP爲不同種類的提要（帖子，照片，投票等）和評論添加「facebookish」新聞源。MongoDB性能：新聞源體系結構，訂閱者，評論

每個進料屬於一些「信道」 - 目前它可能是用戶或組（在將來，可以有更多的容器）。

任何用戶都可以訂閱任何頻道或從其取消訂閱。

現在我們假設有很多渠道和噸飼料。渠道/飼料/評論的最佳結構是什麼？

我正在考慮兩種方法：

1）飼料收集每個飼料中用戶的列表：

feeds: 
[ 
    {date_added: ..., 
    last_update: ..., 
    title: ..., 
    text: ..., 
    channel: ..., 
    channel_subscribers: [...], 
    comments_subscribers: [...], 
    comments: [...] 

    }, 
    {...}, 
    {...}, 
    {...} 
]

如果我想獲得最後提要：

db.feeds.find({date_added: "this week", channel_subscribers: "my_login"});

如果我想得到新的評論的飼料：

db.feeds.find({last_update: "this week", comments_subscribers: "my_login"});

優點：

簡單，快速閱讀？

缺點：

當我想訂閱/ unsibscribe用於/從一個頻道我要運行低谷所有飼料和推/從 channel_subscribers列表拉我的名字;它可能是緩慢的，如果我有噸飼料

2）獨立的「渠道」收集： 同樣的事情，但保持用戶的列表渠道收集：

channels: 
[ 
    {channel_id:..., last_update: ..., subscribers: [...]}, 
    {channel_id:..., last_update: ..., subscribers: [...]} 
]

首先，我要查詢最後更新道：

subscribes = db.channels.find({last_update: "today", subscribers: "my_login"})

現在找到我的供稿：

db.feeds.find({channel: {$in: subscribes}], date_added: "today"})

優點：

簡單，快速和更安全訂閱/ unsubsribing;

缺點：

我覺得我應該避免$在，因爲它的速度慢，尤其是當我有很多的訂閱把該運營商內部的（？）。

3）請用戶集合（因此每個用戶都有自己訂閱的陣列）

users: 
[ 
    {_id: ..., login: ..., email: ..., subscribes: [...]} 
]

缺點用戶訂閱： - 在這種情況下，我們將有更大數組放在$ in之內比以前的（＃2）方法。

4）您的建議？

來源

2012-01-28 oyatek

MongoDB建議他們使用的數據結構適合最常見的用例。儘管理解你當前的結構仍然有點困難。你能詳細說明你的結構嗎？ – JohnP 2012-01-29 07:04:00

好吧，讓我簡化我的問題。什麼會更快：保留我的訂閱列表，然後把這個大數組放在「$ in」運算符中，並通過它獲取我的提要;或者 - 通過我的登錄名獲取提要 - 每個提要中都有一個大（〜2000）的用戶數組？（在這樣的大陣列上創建多鍵索引是否是一個好習慣？） – oyatek 2012-01-30 08:00:21

我認爲將訂閱者保留在訂閱源中是一個壞主意。可能會更好地鏈接它們。這看起來有點SQLey，但它也易於搜索和刪除。 – JohnP 2012-01-30 08:46:15

好的，我會自己回答。我試圖在筆記本電腦的Windows 7 32位/ 2GB RAM上進行測試。我創建了一個「進」的收集和使用500裝滿它供稿：

feeds: 
[ 
{_id: ..., subscribers: [...]}, 
{_id: ..., subscribers: [...]}, 
]

每一個「用戶」陣列有2000短隨機字符串名稱的列表。

首先我不得不提一下，我的數據庫的大小從60Mb增加到1.5Gb。

然後，當我運行一個shell命令db.feeds.ensureIndex({subscribers: 1})它掛起〜3分鐘，然後停止，錯誤："can't map file memory - mongo requires 64 bit build for larger datasets"。

因此，在mongo文檔中創建如此大的多鍵字段肯定不是一個好主意。

來源

2012-01-30 10:52:44 oyatek

請注意，32位mongo版本的數據限制爲2GB（http://blog.mongodb.org/post/137788967/32-bit-limitations）。無論如何，將它分開以便參考更快，更容易，這絕對有意義。既然你想鏈接到用戶對象而不是字符串。 – JohnP 2012-01-30 14:55:21

MongoDB性能：新聞源體系結構，訂閱者，評論

回答

相關問題