适用于线程消息的MongoDB/Mongoose模式（高效）

Question

对于noSQL数据库我有点新鲜（虽然我对关系数据库相当不错），但我想知道通过线程处理收件箱系统的最有效方法消息将是。

每个'消息'将有一个发件人和收件人。用户之间接收/发送的消息数量差别很大。该系统应该可以很好地扩展到超过1k以上的用户。

我读过关于写/读的粉丝，但我不确定这对于线程消息的工作效果如何。

由于我是一般的新手MongoDB/NoSQL，我并不习惯以这种方式有效地构造数据。

我猜将会有嵌套的对象以任何有效的方式处理这个......但我无法解决这样的设计，这对于2个用户之间的线程对话似乎既有效又方便。

我想到了将数据与2个用户的数组一起存储，并结合了一系列'消息'对象。但接下来是2位用户用户名的顺序问题。 （例如[用户A，用户B]和[用户B，用户A]都是可能的并且会有问题，所以这似乎是一个坏主意）。

我想整个粉丝都在读/写的东西上，但这对于线程消息来说似乎并不高效（因为如果通过收件人抓取邮件很方便，发件人不会收取邮件，反之亦然） 。

我倾向于倾向于按收件人抓取邮件（因为收件箱加载多个邮件，并且发送只涉及一个[尽管查询时间较长]）。但我真的想要一口气抓住一个线索对话，以及一个用户与之进行线索对话的用户列表（对于线程列表）。

如果有人可以给我一个有效的线程对话架构，我会非常感激。我一直在研究这个问题，并试图在一个设计上花费数小时，而我已经筋疲力尽了。我一直在我的设计中发现缺陷，并将它们报废，我真的很喜欢NoSQL数据库/ MongoDB更有经验的人的一些输入，所以我可以避免造成一个巨大的设计缺陷和/或编写逻辑，可能已经被处理更好的数据库设计

在此先感谢您的帮助。

Answer 1

在这个特别的话题，你很幸运，有一个伟大的职位讨论各种方法来这里的架构（这是你在找什么，轻轻扭转，但没有太大的不同）：

http://blog.mongodb.org/post/65612078649/schema-design-for-social-inboxes-in-mongodb

然后，这个话题也是在MongoDB的世界2014达伦·伍德和阿霞甘维珍中详细说明了三个部分：

Part 1 Outline和Video

Part 2 Outline和Video

Part 3 Outline和Video

在MongoDB的世界

此外，在Dropbox的家伙谈到建设自己的邮箱时，他们的经验教训：

http://www.mongodb.com/presentations/mongodb-mailbox

然后，以圆其关闭，前面提到的Darren Wood在Github上有一个代号为Socialite的完整参考架构：

https://github.com/10gen-labs/socialite