Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Any reason why I shouldn't use couchdb for message passing or realtime activity streams?

While using ampq or xmpp (rabbitmq or ejabbered that could have couchdb as backends) seems like a good fit to deliver real time updates about friend state in a social gaming platform where updates are small but frequent, I can't help but think why wouldn't couchdb be a good platform to deliver such updates?

The main advantage I could think of is its ability to filter updates based on friends and availability of changes api, which makes developing such an application and managing it (including replication) quite easy compared to ampq or xmpp where you have to think about how to manage the pubsub nodes and who is subscribed to them at any point in time.

However, I can't help but think this is too good to be true, I can't find information on what couchdb's shortcomings are. Somehow, it feels like using MySQL for message passing which is why I am hesitant to using it.

Anyone have any experience in using couchdb for such applications? would you recommend another platform to use?

like image 251
Up. Avatar asked May 26 '10 10:05

Up.


People also ask

Why should you use CouchDB?

Views in CouchDB can be used for filtering documents, retrieving data in a specific order, and creating efficient indexes so you can find documents using values within them. Once you have indexes, they can represent relationships between the documents. These view results are stored in a B-tree index structure.

Which is better MongoDB or CouchDB?

MongoDB is faster than CouchDB. MongoDB provides faster read speeds. It follows the Map/Reduce query method. It follows Map/Reduce creating a collection and object-based query language.

Is CouchDB slow?

But fundamentally, CouchDB chooses a "slower" protocol because it is so universal and so standard. Your documents are on the larger size for CouchDB. Most documents are single or double-digit KB, not triple. CouchDB is encoding/decoding that JSON in one big gulp (i.e. it is not streaming from the disk.)

Is CouchDB scalable?

Scalability. The architectural design of CouchDB makes it extremely adaptable when partitioning databases and scaling data onto multiple nodes. CouchDB supports both horizontal partitioning and replication to create an easily managed solution for balancing both read and write loads during a database deployment.


3 Answers

Here's some problems you'll run in to with "small but frequent" updates and CouchDB.

CouchDB has an excellent MVCC system for document updates. Every update changes the revision and you can't update a document without passing the revision you'd like to update. This also means that if you have multiple clients updating the same document incredibly frequently this feature will get in the way since even with the changes feed there is a small network delay after updates.

Another problem you might have using filtered changes is that the filter function gets the request object, which means it's a separate call to the view server for every document multiplied by the number of connections. You may instead want to use a node.js or erlang server to implement a "channels" approach to change filtering and have it sit on a single unfiltered changes feed.

To summarize, what you want to do will work well if you don't have multiple clients attempting to update the same documents at high frequency and if you don't use a changes filter on a very large number of concurrent clients with a high database update frequency. Other than that, it'll work great. @jchris has done a ton of real-time application just using the bare changes feed and they work great.

like image 130
mikeal Avatar answered Oct 16 '22 06:10

mikeal


However, I can't help but think this is too good to be true, I can't find information on what couchdb's shortcomings are. Somehow, it feels like using MySQL for message passing which is why I am hesitant to using it.

Try to look at why Databases suck for Messaging presentation. Although it's mainly targeted against databases such as MySQL, it can give you a bigger picturer on this topic.

like image 33
yojimbo87 Avatar answered Oct 16 '22 07:10

yojimbo87


I can think of one very simple reason...because databases were not designed to do this!

A message queue is exactly what this sort of work flow needs. Have you looked at some of the AMQP based products or services? These include RabbitMQ (installed locally) and StormMQ (cloud based service). More here: http://www.amqp.org

like image 1
spoutingshite Avatar answered Oct 16 '22 08:10

spoutingshite