php - MongoDB/NoSQL 性能和设计

Question

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

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

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

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

1. 为了排序和排序，必须对它们进行 map 缩减 仅查找未读内容并按日期排序。或者这可以通过以下方式完成 但 PHP 是一个更漫长的过程。

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

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

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

1. 无需进行 map 缩减，更容易查找和排序。

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

3. 由于存在 ID，因此更容易更新队列。

4. 更轻松且更可靠地更新和删除通知 因为 ID 不会改变。

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

Answer 1

两种方法都可以正常工作。但我的应用程序中有类似的功能，你猜怎么着，我还选择了第二种方法(将通知存储在单独的集合中)。主要有2个原因

1. 嵌入后您无法选择前 n 个通知。 Mongodb find 会选择整个文档，而不考虑过滤器。它将返回整个文档以及您的所有通知。

2. 并且您无法在嵌入时过滤相关通知。因为上面说的同样的原因。假设如果您有 2 条未读消息，则您无法单独选择这两条消息，无论使用什么过滤器，它都会返回包含所有通知的整个文档。假设当您收到大约 100 条通知时，它会对您的系统执行什么操作。它会爆炸。

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