Messaging service: redis or mongodb?
I am working on a messaging system that is a little more advanced than just sending received messages; this is what facebook chat / messaging looks like: it has chat aspects as well as messages like group messages, read / unread messages, and more.
In redis, I just used lists to store received messages, for example:
myID = [ "amy|how are you?", "frank|long time no see!" ]
amyID = [ "john|I'm good! you?" ]
(I've simplified this for ease of reading.
But in this way I would not be able to track single conversations, since they will always be cleared after receiving messages (so in principle there is no "inbox" function.
On the other hand, if I'm using mongodb, I could use something like this: How do I track my personal messaging system using MongoDB?
I mean the following advantages / disadvantages:
MongoDB
advantages:
- can see the kind of incoming message
- can check read / unread messages in every conversation
limitations
- not as fast as redis
- storage size increases significantly
REDIS
advantages:
- easy to pick up new messages
- No storage problem (messages are dropped)
Disadvantages:
- when messages are sent to the client are lost so there are no read / unread features and
- no inbox
Any ideas?
Thanks in advance.
source to share
I can't answer for Redis because I don't use it and never will, so I won't pretend I have it.
However, if for some reason you are not using something like an XMPP client like Facebook: http://www.ibm.com/developerworks/xml/tutorials/x-realtimeXMPPtut/section3.html (aka Jabber) for chat then I will describe about a pure MongoDB solution in this situation.
MongoDB uses LRU OS as a means of caching documents and queries, it is fair enough that it does not provide a direct query cache, but if you are smart you won't need it; instead, you just read all your requests directly from RAM. With that in mind, MongoDB can be as fast as Redis since Redis also uses the RAM of the computers.
The speed between them for the optimized query is negligible, I would think. A true measure of speed comes from your schema, indexes, cluster setup, and the queries you run.
A note about storage size here, taking your comment into account:
the problem with flushing mongodb is bigger than I originally did, though: apparently when you delete something on mongo you only delete its link, so if you delete 4MB of documents it won't free up that much space. the only way to actually free this memory is to run dbRepair (or whatever on that line), which basically blocks the db while it is running.
You seem to have some misconceptions about how MongoDB works.
This link will help you: http://www.10gen.com/presentations/storage-engine-internals will describe some of the reasons why excessive disk space is used, and also explain some misconceptions about how a computer works and how MongoDB reclaims space and reuses it.
MongoDB does not free up space at an all-time high. Instead, it will send that "blank" record (record and document are two different things, as the presentation will show you), insert it into the list of deleted buckets and then reuse that space when a new document (or an updated document that has been moved) enters and fits into this space.
It is true that if you are not careful and understand how MongoDB performs at this level, you will probably be forced to run regularly repairDB
to maintain any performance after fragmentation.
How to handle memory. The OS manages this, as I said. A good explanation of when the OS will free memory is on Wikipedia: http://en.wikipedia.org/wiki/Paging
As long as there is not enough RAM to store all the necessary data, the process of obtaining an empty page frame does not require removing another page from RAM.
This way the OS will handle the page deletion for you and you shouldn't be concerned with that part, instead, you should take care of making sure your working set fits into RAM.
If you are worried about saving messages and you don't really want to, i.e. want them to blush, you can use the TTL function that comes with more recent MongoDB installations: http://docs.mongodb.org/manual/tutorial/expire-data/ which will basically let you set a timeout when the message is to be removed from the collection.
So personally, if a MongoDB setup could do messaging and chat like Facebook does, they would of course use the XMPP protocol and then archive the messages in Cassandra for searching, but you don't have to do it the way they do. is just one way to achieve the same goal.
Hope this makes sense and I haven't been looping around, this is a bit long answer.
source to share
I think the big issue here is storage issues. To use MongoDB, you need a lot of machines or a good system to clean up some conversations. Even though you need some sort of "inbox" system ... I think redis would be more favorable to a well-functioning chat system - you just need to come up with some very creative solution ... or abandon that design goal.
source to share