私は2つありNoSQL DBMSます：MongoDBとRedis：
Redisは有名PubSubで、からへの移行に最適なMongoDB最も近いロジックを持っています。でを使用しているので、たとえばユーザーが製品を追加または削除した場合、変更されるのはその長さなので、コードは次のようになります。ここに、、RDBMSSQLNOSQLMongoDBpython DictionariesListslistnotificator
では、ここで使用するメリットはどこにありRedisますか？
opsログでRedispub-subとMongodbの両方の調整可能なカーソルを使用しました（これは上限付きのコレクションです-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を参照してください。
スピードが必要で、非常に多くのクライアントと多数のサブスクリプションチャネルをサポートする必要がある場合は、Redisが最適です。私が言及した実装の中で、Redisは群を抜いて最速であり、最大数のクライアントを処理することができました。もちろん、これはおそらくPub-Sub実装の問題を反映しており、mongoの一般的なパフォーマンスを反映したものではありません。ただし、最新バージョン（2.2？）で軽減されたMongoのグローバル書き込みロックで問題が発生しました。
まとめると、何か専門的なものが必要な場合は、Mongoが正しい選択かもしれません。ただし、大きな負荷に対して箱から出してすぐに機能する簡単なメッセージが必要な場合は、車輪の再発明を試みず、Redisを使用します。