最適合twitter克隆的MongoDB模式？

我知道類似的問題已經被問到，但是尋找一個基本問題的基本答案。我是MongoDB的新手，並且製作了一個Twitter風格的應用程序（博客，追隨者等），我想知道最好的模式。最適合twitter克隆的MongoDB模式？

現在我有（在一個非常高的水平）：

Member { 
    login: string, 
    pass: string, 
    posts: [ 
    { 
     title: string, 
     blog: string, 
     comments: [ { comment: string } ] 
    } 
    ] 
}

有更多的它，但是，讓你的想法。 現在的問題是我正在尋找添加「追蹤」功能，我不確定最佳路線。

我可以向成員添加一個「以下」嵌入式文檔，但我不確定使用mongoDB最聰明的方法是什麼。我的主要觀點顯然是主要的「feed」頁面，您可以看到您所關注的所有人的帖子。

來源

2011-06-29 MrBojangles

這個問題與在博客文章示例中如何廣泛使用以及如何建模博客文章和評論相同。你只需要在這裏應用相同的概念。您有以下選擇：

嵌入文檔
專門的收集和執行多個查詢

的利弊已經被廣泛討論。嵌入式文檔只能有16MB大小，並且不可能在MongoDB中返回匹配數組的各個部分...做出選擇。

不再進一步，因爲如上所述：在有關「模式設計」的許多問題中討論過同樣的問題。只需谷歌「架構設計MongoDB」或尋找相同的SO。

來源

2011-06-29 04:57:06

我得到的簡單的博客或推文，但與我所要求的沒有任何相同之處。我唯一的問題是添加「跟隨」功能。我正在尋找的是具有更多經驗的人士對設置它的最佳方式提出意見。對於「跟隨」功能，我需要在成員資料中列出他們所關注的所有人，或者我可以將所有跟隨他們的人放入等等。我所見過的twitter克隆只是處理添加「鳴叫」或博客。他們中沒有一個涉及建立「跟隨」這個更加棘手的問題。 – MrBojangles

從數據模型的角度來看，您無法從您的問題中抽象出解決方案。通過專用集合或嵌入式文檔處理MongoDB中每種自然現象的關係。每個文檔都在解釋這一點。請將它應用於您的問題 –

雖然我不同意twitter模式將類似於博客模式，但廣泛討論了一般主題，因此在這裏和這裏有幾個Google應該讓您繼續。 –

向成員文檔中添加一個「跟隨」數組應該可以。它應該包含成員所關注人員的用戶標識。您的代碼將不得不檢索列表並構建一個查詢以檢索這些用戶的推文。由於Mongo不具有關係性，因此無法構建連接成員和Tweet集合的查詢並在單個查詢中執行此操作，但通過在數據庫服務器上執行此操作（使用服務器端代碼執行），您應該能夠減少網絡開銷：http://www.mongodb.org/display/DOCS/Server-side+Code+Execution。

來源

2011-06-29 05:34:15

服務器端代碼執行和潛在的巨大且不斷增長的嵌入式數組應該在負載預期相當可觀的生產環境中謹慎使用。 –

@Remon，你似乎給了我更多的想法。關於不斷增長的數組有點合理，但我不明白服務器端代碼執行會比服務器的兩次往返更糟糕。 –

這並不明顯，但這是由於mongo中的JS引擎是單線程的，因此無法利用所有可用的cpu資源。即使map/reduce目前也遭受這種困難（這很奇怪，因爲它基本上是在考慮並行性的情況下發明的）。如果該服務器端腳本的使用頻率比單個核心可以處理的要多，那麼它將開始減慢整個服務器的速度。所以是的，在不少情況下，兩次往返實際上更快，或者至少更容易擴展;）就像所有事情一樣，測試並看看最好的方法。 –

這不是Twitter克隆的理想模式。主要的問題是，「posts」是一個不斷增長的數組，這意味着mongo將不得不每隔幾個文章移動大量文檔，因爲文檔填充耗盡。此外，文檔的硬件（16MB）大小限制使得這種模式限制最多。

理想的模式取決於您是否期望Twitter的負載。就可維護性和易用性而言，「完美」的mongodb模式與我用於Twitter的吞吐量的模式並不相同。例如，在前一種情況下，我會爲每個帖子的文檔使用帖子集合。在高吞吐量的情況下，我會開始爲少量的帖子製作桶文件（比如說，每個「獲取更多」頁面）。此外，在高吞吐量情況下，您必須在單獨的用戶時間線文檔中將跟隨者的時間線保持最新，而在低吞吐量情況下，您可以簡單地查詢它們。

來源

2011-06-29 13:59:25

好點，@Remon，但OP的問題不是關於「posts」數組。他/她確實提到這是模式的簡化版本，而問題是關於如何實現以下內容。 –

謝謝@Remon這是很棒的信息。該網站永遠不需要擴展到Twitter的水平，但它也不適用於小型網站。它必須能夠擴展，但沒有什麼瘋狂的。就像@Martin Vilcans所提到的，任何關於「跟隨」方面的輸入都會很棒。但您提供的信息已經有所幫助。我想我害怕把它變成關係型，所以我可能會過度補償。 – MrBojangles

對不起，我完全誤讀了原來的問題。以下應該按照建議使用嵌入式數組來實現，因爲使用UUID數組將很難達到16mb的限制。如果您打算在用戶集合中粘貼大量其他數據，則可以將followes數組放入專用的每個用戶文檔中。然後，在用戶異步發佈新帖子（在工作負載隊列/消費者模型中使用消息隊列）以迭代該陣列並更新所有追隨者的時間軸。這允許近乎無盡的縮放，並且接近當前的Twitter架構。 –

最適合twitter克隆的MongoDB模式？

回答

相關問題