1

我们正在开发一个包含本土文学作品的网站。整个网站设计为以作家为中心。每个作家有 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，请告诉我文件的影响。

4

2 回答 2

1

这取决于你的数据有多少是固定的，以及它是如何（经常）更新的。

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

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

您还可以选择在 Articles 集合中嵌入/添加作者数据（姓名、电子邮件），如果您关心的话，一旦作者电子邮件更改，您的应用程序代码就会更新所有文档。

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

至于您的第二个问题，在这种情况下，规范化意味着更简洁的查询模式：例如，您不必为了获取 20 条最顶层的文章而对数组进行切片。

于 2013-11-14T16:16:09.977 回答
0

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

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

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

于 2013-11-14T16:17:12.047 回答