MongoDB/NoSQL性能与设计

Question

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

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

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

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

1. 对于排序和排序，必须对它们进行映射约简只查找未读内容并按日期排序。也可以这样做

2. 在嵌入数组中更新/删除通知记录需要查找该文档的时间更长，而且如果使用索引，可能容易出错通知的内容已更改(即:将新通知推送到文档).

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

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

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

2. 可能有性能问题，如果有很多通知(this Is true or false?)

3. 更容易更新队列，因为存在id。

4. 更容易，可以更可靠地更新和删除通知

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

Answer 1

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

1. 当它嵌入时，你不能选择top n通知。不管过滤器是什么，Mongodb find都会选择整个文档。它会返回包含所有通知的整个文档。

2. 并且在嵌入时无法过滤相关通知。由于上述相同的原因。假设你有2个未读消息，你不能单独选择这两个消息，不管过滤器是什么，它都会返回整个文档和所有通知。假设当您有大约100个通知时，它会对您的系统产生什么影响。

这两个理由足以避免嵌入文档