2

数据结构可能如下所示：

{
 post_title : String,
 post_date  : Date,
 user_id    : ObjectID,
 post_content : String,
 comments   : [
                {
                  comment_date : Date,
                  comment_content : String,
                  user_id : ObjectID
                 }
                ]
}

我正在研究的系统具有与上述类似的结构。post_* 对象中包含的内容可能永远不会改变，但评论部分的内容会经常更新和编辑。

由于上述结构是单个文档，因此更新或添加单个注释需要阅读整个文档，对其进行编辑并保存。这也使缓存变得困难，因为尽管 post_* 内容可以缓存很长时间，但评论却不能。

这里最好的策略是什么？给评论提供他们自己的收藏会更好吗？

就查询时间而言，我仍然需要访问数据库来提取评论，但是在更新或添加评论时，文档的大小会小得多。

4

3 回答 3

2

在 Mongo 中，您可以附加到数组而不读取它。请参阅$push命令。在缓存方面对您没有帮助，但它消除了在更新文档之前阅读文档的需要。

于 2012-04-20T16:40:16.830 回答
1

在嵌套集合中存储评论是什么意思？我建议您使用另一个集合来获取带有 DBRef 甚至手动引用的注释。

文件大小不是唯一的问题。（我认为这根本不是问题） 常见任务之一 - 向用户显示最后 N 条评论。你的结构很难做到。

我在我的应用程序中使用了你的结构，后来我不得不用独立集合重写它

于 2012-04-20T18:22:38.857 回答
1

要考虑的另一件事是，您是否提前知道您希望“评论”数组变得多大？

每个 mongo 文档的大小限制为 16mb。这很少成为问题，但需要牢记这一点，并且是避免将子文档“无限期地”添加到嵌入式数组的原因。

此外，Mongo 为文档的增长预先分配了空间。（有关更多信息，请参阅有关“填充因子”的文档：http ://www.mongodb.org/display/DOCS/Padding+Factor ）如果将足够多的嵌入文档推送到数组以导致文档增长超出其预分配插槽，然后整个文档将不得不移动到磁盘上的不同位置。您可能会发现这会导致不需要的 diskIO。

如果您预计每个文档将具有最大数量的嵌入文档，则通常的做法是在添加新文档时预先填充新文档数组。例如，如果您预计每个帖子将有 100 条评论，那么最佳做法是使用“评论”数组创建新的帖子文档，该数组包含 100 个带有“垃圾”数据的嵌入文档。新文档创建后，磁盘空间将被预先分配，垃圾数据可能会被删除，为文档的大小留出空间。

希望这会给您在设计文档结构时提供一些额外的思考。

于 2012-04-20T19:44:12.720 回答