我正在开发一个比简单地发送接收消息更高级的消息传递系统；它看起来像 facebook 聊天/消息：它有聊天方面，但也有消息方面，如群组消息、已读/未读消息等。
在 redis 上，我会简单地使用列表来存储收到的消息，例如：
myID = [ "amy|how are you?", "frank|long time no see!" ]
amyID = [ "john|I'm good! you?" ]
（为了便于阅读，我已经简化了很多。
但是通过这种方式，我将无法跟踪单个对话，因为一旦收到消息，它们都会被刷新（所以基本上没有“收件箱”功能。
另一方面，如果我使用 mongodb，我可以使用这样的东西：如何使用 MongoDB 跟踪私有消息传递系统？
我认为以下优点/缺点：
蒙古数据库
优点：
缺点
雷迪斯
优点：
缺点：
有任何想法吗？
提前致谢。
我无法回答 Redis，因为我不使用它，也从未使用过，所以我不会假装我有。
但是，如果由于某种原因，您没有使用像 Facebook 这样的 XMPP 客户端：http: //www.ibm.com/developerworks/xml/tutorials/x-realtimeXMPPtut/section3.html（又名 Jabber）进行聊天在这种情况下，我将描述一个纯 MongoDB 解决方案。
MongoDB 使用操作系统的 LRU 作为缓存文档和查询的一种方式，公平地说，它不提供直接查询缓存，但是如果您很聪明，您将不需要它；相反，您只需直接从 RAM 中读取所有查询。考虑到这一点，MongoDB可以和 Redis 一样快，因为 Redis 也使用计算机 RAM。
我认为优化查询上两者之间的速度可以忽略不计。速度的真正衡量标准来自您的架构、索引、集群设置和您执行的查询。
此处关于存储大小的说明，考虑到您的评论：
刷新 mongodb 的问题比我最初的问题要大：显然，当您在 mongo 上删除某些内容时，您只会删除它的引用，因此如果您删除 4mb 的文档，它不会释放那么多空间。真正释放内存的唯一方法是运行一个 dbRepair （或这一行中的某个东西），它在运行时基本上会阻塞 db....
您似乎对 MongoDB 的工作原理有一些误解。
此链接将对您有所帮助：http ://www.10gen.com/presentations/storage-engine-internals它将描述使用过多磁盘空间的一些原因，还将解释您对的一些误解计算机如何工作以及 MongoDB 如何释放空间并重用它。
MongoDB 不会释放记录级别的空间。相反，它会发送“空”记录（记录和文档是两个不同的东西，正如演示文稿会告诉你的那样），将其推入已删除的存储桶列表，然后在新文档（或已移动的更新文档）时重用该空间) 出现并适合该空间。
确实，如果您不仔细并了解 MongoDB 在此级别上的工作方式，您可能会被迫repairDB相当定期地运行以在碎片后保持任何类型的性能。
至于内存处理。正如我所说，操作系统会处理这个问题。关于操作系统何时释放内存的一个很好的解释是在维基百科上：http ://en.wikipedia.org/wiki/Paging
在没有足够的 RAM 来存储所需的所有数据之前，获取空页框的过程并不涉及从 RAM 中删除另一页。
因此，操作系统将为您处理删除页面，您不应该关心这部分，而是应该关心使您的工作集适合 RAM。
如果您担心存储消息并且真的不想这样做，即您希望它们被“刷新”，您实际上可以使用后期 MongoDB 安装附带的 TTL 功能：http: //docs.mongodb.org/manual /tutorial/expire-data/基本上允许您设置一个超时时间，以便从集合中删除一条消息。
因此，就个人而言，如果设置正确，MongoDB 可以像 Facebook 那样进行消息传递和聊天，当然他们使用 XMPP 协议，然后将消息存档到 Cassandra 中进行搜索，但您不必像他们那样做，这只是一个达到相同目标的方法。
希望这是有道理的，我没有绕圈子，这是一个有点长的答案。
我认为这里的重点是存储问题。你需要很多机器或一个好的系统来刷新一些对话才能使用 MongoDB。尽管想要一种“收件箱”系统……我认为 redis 会更有利于一个运行良好的聊天系统——你只需要想出一些非常有创意的解决方法……或者放弃那个设计目标。
我们使用混合设计，因此当我们需要在消息、队列和缓存方面的快速性能时，它在 Redis 上，当我们需要搜索二级索引或更新整个文档时，我们使用 MongoDB。
你也可以试试 Riak，它比 MongoDB 可以更线性、更平滑地增长。