1

i've two NoSQL DBMS: MongoDB and Redis:

Redis has the famous PubSub, MongoDB has the nearest logic to RDBMS which is the best for the transition from SQL to NOSQL, and since MongoDB is using in python Dictionaries and Lists and if a user adds or removes a product for example, it's the length of the list that changes, so, a code can be written here as a notificator,

So where is the benefic to use Redis here?

Abdelouahab Pp
  • 4,252
  • 11
  • 42
  • 65
  • what do you mean by notificator here? – Rostyslav Dzinko Sep 17 '12 at 21:59
  • mongodb has not Triggers? so pubsub as i understand is something related to pubsub? – Abdelouahab Pp Sep 17 '12 at 22:05
  • 1
    No, MongoDB does not have triggers or similar mechanizm to notify client for changes. – Rostyslav Dzinko Sep 17 '12 at 22:07
  • so why not simply make in python: some_document = len(actual_document) so if the length is -1, then the product has been removed, so notify users (subscribers), else: he has add a new product, get the index, then return this new product. or will this be slow? – Abdelouahab Pp Sep 17 '12 at 22:11
  • 1
    @RostyslavDzinko: MongoDB does support [tailable cursors](http://www.mongodb.org/display/DOCS/Tailable+Cursors) on capped collections such as the replication oplog, which some folks have used for [pub/sub with MongoDB](http://blog.mongodb.org/post/29495793738/pub-sub-with-mongodb) or [custom triggers](http://danielweberonline.wordpress.com/2012/05/14/creating-triggers-for-mongodb/). – Stennie Sep 17 '12 at 22:57
  • 1
    @Stennie, too much limitations to say tailable cursors is a pub/sub replacement, though I agree that it can be applied to a narrow field of tasks. – Rostyslav Dzinko Sep 18 '12 at 08:41

1 Answers1

7

I've used both Redis pub-sub and Mongodb tailable cursors on the ops log (which is a capped collection - see http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html and http://blog.mongodb.org/post/29495793738/pubsub-with-mongodb) to whip up my own. The primary difference is whether you want to build out your own logic for pub-sub using Mongo. On the face of it, pub-sub seems simple enough, but as with anything, its got a lot of edge cases that you have to program to. Redis' pub-sub has already done most of the plumbing work for you so you can worry about the high level coding problems and leave the low level stuff to systems that have already solved the problem.

The big win with Mongo over Redis, is that you can have more control over how you build out your pub-sub, so if you have special needs, it may be a better choice. For example, with Redis (out of the box), if a client disconnects and then reconnects 10 minutes later, it will have lost the messages in those intervening minutes and there is no way to get them back. With Mongo, the client can go back and get those messages (with the caveat that it has to read the entire capped collection from start to finish) - remember that you will have to track the last message delivered to each client, etc. There are work arounds for Redis so that it can achieve this - see Redis Pub/Sub with Reliability as one example.

If you are in need of speed and supporting a very large number of clients and a large number of subscription channels, Redis is the way to go. Of the implementations I mentioned, Redis was by far the fastest with the ability to handle the largest number of clients. Of course, this probably reflects problems with our Pub-Sub implementation and is not a reflection on mongo's general performance. Although, we did experience issues with the global write lock in Mongo that has been mitigated in the latest version (2.2?).

To wrap up, if you need something specialized, Mongo may be the right choice for you. However, if you want straight forward messaging that works out of the box for a large load, I would not try to reinvent the wheel and would go with Redis.

Carl Walsh
  • 6,100
  • 2
  • 46
  • 50
AlexGad
  • 6,612
  • 5
  • 33
  • 45
  • thank you for the reply, so, if i use both of them, how can i access to Redis from MongoDB, or somedata must be replicated? – Abdelouahab Pp Sep 18 '12 at 12:33
  • 1
    That's highly dependent upon your application and how you've designed your schemas and which direction data needs to go. Without having an indepth understanding of your app, its impossible to even give a simple answer that is worth anything. I'd suggest you open another q detailing your exact specs. You can't move data directly between the two. The most obvious methods are a) through your app tier - when you save data in one place you save it in the other, or b) through a qeueing mechanism/message bus such as RabbitMQ/ActiveMQ, etc. – AlexGad Sep 18 '12 at 13:50
  • i need only to inform clients that are registred to a seller that he put a new product to sell. – Abdelouahab Pp Sep 18 '12 at 13:58
  • 1
    If what you want to do is store the primary info in Mongo and then push the pub-sub to Redis, then when you save the product in Mongo, just push your data out to Redis as well. Keeps it as simple as possible. – AlexGad Sep 18 '12 at 14:47
  • so it's something like replication the data on two DBMS?! – Abdelouahab Pp Sep 18 '12 at 14:53
  • 1
    Again, I don't know your data schema so its impossible to provide intelligent answers. But it sounds as though all you want to do is notify users of new product updates. If Mongo is your primary database, then it sounds like all you need to do is push Ids of changed/new products, etc., to Redis and that is all you really need. Then the clients would receive the IDs for updated/changed products, and then go back to your app/mongodb for the full amount of data? – AlexGad Sep 18 '12 at 17:16
  • here is the schema: user:{only user information}, then for the first time he adds a product (by buying or selling) then, a new product_up or product_in will be "pushed" then a list will be created, so i said that because it's only a list stuff, why not adding a line in python code to send the news to other subscribers (clients or sellers) – Abdelouahab Pp Sep 18 '12 at 18:37