MongoDB/NoSQL Performance and Design

I have a question that involves a performance question and Mongo Design. Currently a project I am working on will involve notifications similar to Facebook where a user will receive messages on things that happen in the site. The problem is choosing if notifications will be either be its own collection or an array embedded within a user. Requirements of notifications include:

1. Changing the status from read/unread, and ordering by date(other sorting maybe later).
2. Notifications are suppose to be in real time .
3. Notifications are deleted every 2 weeks.

Correct my if I am wrong by my thinking is like this.

If the notifications are embedded in the user document, they will be slower, more costly, and more time developing and harder to maintain\ because:

1. For ordering and sorting, they will have to be map reduced for finding only the unread and ordering by a date. Or this can be done by PHP but is a more lengthily process.

2. Updating/Deleting a notification record in an embedded array takes more time to find that document and can be prone to errors if an index of a notification has changed (IE: A new notification is push into the document).

3. Notifications will be added to a queue in PHP and/or JavaScript for retrieval later. It will more time spent trying to figure out how to modify the queue(append/remove) because they will not have IDs.

If they are stored in their own collection and each notification has its own id.

1. No map reduce is required and it is easier to find and sort.

2. Maybe possibly have performance issues if there are a lot of notifications(Is this true or false?).

3. Easier to update queues because i开发者_StackOverflow社区ds are present.

4. Easier and can more reliably update and remove notifications because IDs do not change.

Can I get some feedback on this? Is my logic correct or incorrect?

---

Both approaches works fine. But I have a similar functionality in my app, guess what, i also chose the second approach (Storing notifications in a seperate collection). Because of the 2 main reasons

1. You cannot pick top n notifications when its embedded. Mongodb find picks the whole document irrespective of the filter. It ll return the whole document with all your notifications.

2. And you cannot filter the relevant notifications when in embedded. Because of the above said same reason. Assume if you have 2 unread messages, you cannot ever pick the two messages alone, Irrespective of the filter it will return the whole document with all notifications. Assume what it ll do to your system when you have some 100 notifications. It ll blow.

these two reasons are more than enough to avoid putting into embedded documents.