我有两个NoSQL DBMS：MongoDB和Redis：
Redis有着名的PubSub，MongoDB与RDBMS具有最接近的逻辑，这是从SQL到{{1}的最佳转换自NOSQL MongoDB和python中使用Dictionaries后，如果用户添加或删除了某个产品，那么它就是Lists的长度因此，代码可以在此处写为list，
那么在这里使用notificator的好处是什么？
答案 0 :(得分：6)
我在操作日志上使用了Redis pub-sub和Mongodb tailable游标（这是一个上限集合 - 请参阅http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog。html和http://blog.mongodb.org/post/29495793738/pubsub-with-mongodb）来启动我自己的游标。主要区别在于您是否要使用Mongo为pub-sub构建自己的逻辑。从表面上看，pub-sub似乎很简单，但与任何事情一样，它有很多边缘情况你必须编程。 Redis'pub-sub已经完成了大部分的管道工作，因此您可以担心高级编码问题，并将低级别的东西留给已经解决问题的系统。
Mongo胜过Redis的最大胜利是，你可以更好地控制你如何构建你的pub-sub，所以如果你有特殊需求，它可能是一个更好的选择。例如，使用Redis（开箱即用），如果客户端断开连接，然后在10分钟后重新连接，它将在那些间隔时间内丢失消息，并且无法将其恢复。使用Mongo，客户端可以返回并获取这些消息（需要注意它必须从头到尾读取整个上限集合） - 请记住，您必须跟踪传递给每个客户端的最后一条消息，等等。解决Redis的问题，以便它可以实现这一目标 - 请参阅Redis Pub/Sub with Reliability作为一个例子。
如果您需要速度并支持大量客户端和大量订阅频道，Redis是您的最佳选择。在我提到的实现中，Redis是迄今为止能够处理最多客户端的最快的。当然，这可能反映了我们的Pub-Sub实现的问题，并不反映mongo的一般性能。尽管如此，我们确实遇到了Mongo中全局写锁的问题，这个问题已在最新版本（2.2？）中得到缓解。
总结一下，如果您需要专门的东西，Mongo可能是您的正确选择。但是，如果你想要一个开箱即用的直接消息传递以获得大负载，我不会尝试重新发明轮子并且会使用Redis。