Mongo數據庫架構設計

Question

我正在努力為應用找到最佳的數據庫設計。 我有一個SQL背景，並且傾向於創建或多或少的非規范化數據庫設計。

我有以下問題。 我收集了包含大約2000篇文章的“文章”。 每篇文章都有很多信息。 在實施推薦系統時，我想為每個“用戶”與每個“文章”關聯一個“ PredictedRating”。 在SQL中，我將使用三個表對此模型進行建模：“文章”，“用戶”，“ UserToArticle”。 該查詢應如下所示：我想為每個“ Article”關聯當前登錄用戶的“ PredictedRating”。在SQL中，我將通過“ Article”和“ Users”進行聯接，從而預先選擇相應的用戶。 具有正確的索引，這非常快。

我如何以mongo方式實現呢？ 當我以描述的方式實現此功能時，我被迫對每篇文章都進行findOne（）查詢，這效率非常低而且很慢（即使使用索引）。

你有什么想法嗎？ 重要的是，僅發布當前用戶的預測收視率。

Answer 1

經驗法則

MongoDB博客對數據建模有一些好的建議 ：

1. 盡可能使用嵌入的文檔。
2. 如果經常自己閱讀子文檔，最好不要嵌入它。
3. 保持數組較小。 如果嵌入的文檔數組持續增長，請用參考ID數組替換它。 如果引用數組持續增長，請嘗試反轉引用或將引用提取到其自己的集合中。
4. 應用程序級聯接仍然是一種選擇。 正確使用索引和投影時，不應降低性能。
5. 您可以嵌入很少更新但經常讀取的文檔，即使這意味着多余的數據。 如果您需要經常更新冗余數據，則不要嵌入冗余數據，因為它可能會超過讀取優勢。
6. 優化應用程序的數據模型。 需要一起讀取或寫入的內容應移近（放入更少的集合中）。

因此，對文檔數據庫進行建模並不像對關系數據模型進行標准化那樣簡單。 掌握了這些經驗法則后，您應該閱讀MongoDB手冊中的數據模型 。

---

例

我們需要將三個域對象放入MongoDB中： 用戶 ， 文章和預測等級 。 我假設有很多用戶，甚至更多的文章。 很顯然，我們不應該將用戶和文章放入一個集合中（項目符號2、4和5）。 因此，我們只需要決定將預測收視率放在哪里。

將評分嵌入文章

由於您的用例是獲取用戶的所有預測評分，因此將其放入文章中會適得其反（6）。 您將需要搜索所有文章以獲得評分。 除此之外，如果您刪除用戶，則需要更新每篇文章。

將評分嵌入用戶

將評分嵌入用戶中的優勢在於，您只需要一個查詢即可獲取用戶和評分數據。 但是您可能需要為每個用戶的每篇文章添加一個評分，因此數組將增加很多（3）。

將評分放入自己的收藏中

因此，將評級放入自己的收藏夾是可行的。

{
    _id: ObjectId("f01..."),
    userId: ObjectId("123..."),
    articleId: ObjectId("abc..."),
    predictedRating: 5.4
}

如前所述，這取決於您的數量結構。 如果您只有很少的用戶或幾篇文章，則嵌入預測的收視率可能是一個更簡單，更快速的解決方案。