Question

我们正在开发一个包含本土文献的网站。整个网站被设计为以作家为中心。每位作家有8000 - 10000篇文章/诗歌/书籍。

客户端要求将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，请告诉我文档的影响。

Answer 1

这取决于您修复了多少数据，以及（通常）更新数据的方式。

如果您经常更新文章数组（如在博客系统中），文档最终会增长，不适合原始磁盘空间，并且将由磁盘上的MongoDB移动。这将导致存储大小大量增加，碎片并将损害性能（IO，必须使用指向文件系统上的文档的指针更新的索引）。此外，这些文档往往超过16 MB。

如果它是书籍目录 - 例如数据很少变化 - 可以考虑嵌入，因为它意味着更方便/更简单的数据模型。

您还有第三种方法可以在文章集合中嵌入/添加编写器数据（名称，电子邮件），如果您关心它，您的应用程序代码会在编写者电子邮件更改后更新所有文档。

所以，如果作家有8000 - 10000篇文章/诗歌/书籍（我希望这些数字不同，你不应指望这个假设），嵌入选项意味着不可预测的平均值。文档大小和增加填充（因子）。在这种情况下，我会反对嵌入。

至于你的第二个问题，这种情况下的规范化意味着稍微简洁的查询模式：例如，您不必切片数组以获取20个最顶层的文章。

Answer 2

我认为您应该仔细研究使用场景。通常（在我看来），如果我正在查看作者信息，我希望看到一个书籍列表，作者生物等。虽然我认为没有必要将评论存储在同一个文档中（并且它如果有很多它们将是一个好主意，让它们分开），因为我不需要它们立刻。所以第一版数据模型对我来说很好，除了评论。我宁愿把它们分开收藏。

关于最大文档大小：16MB是很多数据，这个限制是为了确保文档不占用太多RAM和网络带宽（如果你的mongodb在单独的服务器上）。另外我认为如果您的文档大小超过16MB，那么您的数据模型就会出现问题。

如果您的文档超过16MB，我不知道当前版本的mongodb究竟会发生什么，因为我从未遇到过这种情况，但我认为数据会被修剪。

MongoDB中的数据建模

2 个答案: