MongoDB中的數據建模

我們正在研究一個包含原生文獻的網站。整個網站被設計爲以作家爲中心。每位作家有8000 - 10000篇文章/詩歌/書籍。MongoDB中的數據建模

客戶端要求將mongoDB用作此應用程序的後端。作爲一個新手，我在mongo的數據建模中感到困惑。

我的問題是，什麼是最好的方法？嵌入式數據模型或規範化的數據模型用於我的用例。

Writer:{ 
     _id: ObjectID 
    WriterName: String 
    Email: String 
    Article :[ 
     _id: ObjectID 
     ArticleName: String 
     CreatedDate: Date 
     comments: [ 
      body: String 
     ] 
    ]

或者

Writer: { 
    _id: ObjectID 
    WriterName: String 
    Email: String 
} 

Articles: { 
    _id: ObjectID 
    Writer_id: ObjectID 
    ArticleName: String 
    CreatedDate: Date 
    comments: [ 
     body: String 
    ] 
}

我們有我們需要從所有作家的文章檢索排名前20位的文章另一種使用情況。記住這個最好的解決方案是什麼？如果文件大小超過16MB，請讓我知道文檔的影響。

來源

2013-11-14 ppusapati

盡你所能嵌入！ – tymeJV

如果文檔超過16MB會有什麼影響？ – ppusapati

閱讀小MongoDB書（免費，40頁以下PDF，谷歌發現）。 – hyde

這取決於您的數據有多少是固定的，以及（經常）更新的方式。

如果你不斷更新你的文章陣列（如博客系統），文件將最終成長，不適合原來的磁盤空間，並且將MongoDB的磁盤上移動。這會導致存儲容量大量增加，碎片化並會損害性能（IO，索引必須通過指向文件系統上的文檔來更新）。再加上這些文件往往會增長超過16 MB。

如果是書目錄 - 例如數據很少變化 - 可以考慮嵌入，因爲它意味着更方便/簡單的數據模型。

你也有嵌入的第三個選項/添加文章裏面收集數據的作家（姓名，電子郵件），讓你的應用程序代碼更新一次作家電子郵件變化的所有文件，如果你在乎它。

所以，如果作家有8000 - 10000篇/詩歌/書籍（我希望這些數字變化，你不應該在這個假設計數），嵌入選項意味着不可預知的魅力。文件大小和增加的填充（因子）。在這種情況下，我會反對嵌入。

關於你的第二個問題，歸在這種情況下意味着一個稍微更簡潔的查詢模式：例如，你不必爲了獲取最頂層的20篇切片陣列。

來源

2013-11-14 16:16:09

我認爲你應該仔細觀察使用場景。通常（就我看來），如果我正在查看作者信息，我希望看到書籍列表，作者生物等等。雖然我認爲沒有必要在同一個文檔中存儲註釋（並且它將會是一個很好的主意，如果它們中會有很多的話，將它們分開），因爲我不需要它們立即。所以對於我來說第一版數據模型看起來很好，除了評論。我寧願將它們分開收集。

關於最大文件尺寸：16MB大量的數據，這種限制，以確保該文件並不需要太多的內存和網絡帶寬（如果您的MongoDB是單獨的服務器上）。另外我認爲，如果您的文檔大小超過16MB，那麼您的數據模型會出現問題。

我不知道究竟會在MongoDB中的當前版本中發生，如果您的文檔超過16MB，因爲我從來沒有遇到過這種情況，但我認爲這些數據會被剪掉。

來源

2013-11-14 16:17:12 zetdotpi

MongoDB中的數據建模

回答

相關問題