php - MongoDB/NoSQL 性能和设计

Question

我有一个问题涉及性能问题和 Mongo设计。目前我正在做的一个项目会涉及到通知类似于 Facebook，用户将收到有关以下内容的消息发生在现场。问题是选择是否通知要么是它自己的集合，要么是嵌入在用户中的数组。通知要求包括:

1. 更改已读/未读状态，并按日期排序(其他可能稍后排序)。
2. 通知应该是实时的。
3. 通知每 2 周删除一次。

我的想法是这样的，如果我错了，请纠正我。

如果通知嵌入在用户文档中，它们将开发速度更慢、成本更高、时间更长且更难维护\因为:

1. 为了排序和分类，它们必须被缩减为仅查找未读内容并按日期排序。或者这可以通过PHP 但这是一个更漫长的过程。

2. 更新/删除嵌入式数组中的通知记录需要有更多的时间来查找该文档，并且如果索引很容易出错通知已更改(IE:新通知被推送到文档)。

3. 通知将添加到 PHP 和/或 JavaScript 中的队列中稍后检索。它将花费更多时间来弄清楚如何修改队列(添加/删除)，因为它们没有 ID。

如果它们存储在自己的集合中并且每个通知都有它自己的 ID。

1. 不需要map reduce，更容易查找和排序。

2. 如果有很多，可能会出现性能问题通知(这是真的还是假的？)。

3. 因为存在 ID，所以更容易更新队列。

4. 更容易、更可靠地更新和删除通知因为 ID 不会改变。

我能得到一些反馈吗？我的逻辑正确还是错误？

Answer 1

这两种方法都很好。但是我的应用程序中有类似的功能，猜猜是什么，我也选择了第二种方法(将通知存储在单独的集合中)。由于2个主要原因

1. 当通知嵌入时，您无法选择前 n 个通知。 Mongodb 查找选择整个文档而不考虑过滤器。它会返回包含所有通知的整个文档。

2. 嵌入时无法过滤相关通知。由于上述相同的原因。假设您有 2 条未读消息，您永远不能单独选择这两条消息，无论过滤器如何，它都会返回包含所有通知的整个文档。假设当您有大约 100 个通知时它会对您的系统做什么。它会吹的。

这两个原因足以避免放入嵌入式文档。