我正在开发一个比简单发送接收消息更先进的消息传递系统;它看起来像Facebook聊天/消息：它有聊天方面，但也有消息，消息，组消息，读/未读消息等。
在redis上，我只是使用列表来存储收到的消息，例如：
myID = [ "amy|how are you?", "frank|long time no see!" ]
amyID = [ "john|I'm good! you?" ]
（为了便于阅读，我已将其简化了很多。
但是通过这种方式，我无法跟踪单个会话，因为一旦收到消息，它们都会被刷新（所以基本上没有“收件箱”功能。
另一方面，如果我使用mongodb，我可以使用这样的东西：How to keep track of a private messaging system using MongoDB?
我虽然有以下好处/缺点：
MongoDB的
的优点：
缺点
Redis的
的优点：
缺点：
有什么想法吗？
提前致谢。
答案 0 :(得分：6)
我无法回答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（或此行中的某些内容），它在运行时基本上阻止了数据库....
您似乎对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进行搜索，但你不必像他们那样做，只是实现同一目标的一种方式。
希望这是有道理的，我没有绕圈子，这是一个很长的答案。
答案 1 :(得分：0)
我认为这里的重点是存储问题。您需要大量的机器或一个良好的系统来刷新一些对话供您使用MongoDB。尽管想要一种“收件箱”系统......我认为redis更有利于一个良好的聊天系统 - 你只需要提出一些非常有创意的解决方法......或者放弃设计目标。
答案 2 :(得分：0)
我们使用混合设计，所以当我们需要在Redis上的消息，队列和缓存中获得快速的性能时，当我们需要搜索二级索引或更新整个文档时，我们使用MongoDB。
您还可以尝试使用Riak，它可以比MongoDB更加线性和平滑地生长。