couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: CouchDB for geographically distributed CRM
Date Mon, 13 Apr 2009 10:25:38 GMT

On 13 Apr 2009, at 06:36, sftf wrote:

> I search the database for a small (but geographically distributed on  
> 2-3 nodes)
> CRM and would like to know the answers to several questions about  
> the couchdb.
> 1. What is the (read) performance of couchdb compared to the  
> relational database like PostgreSQL?
>  Is it usually faster?

Speed is not the issue.

CouchDB is not meant to be faster than any fine-tuned, mature  
solution. It is designed to handle high levels of concurrency while  
operating fault tolerant. At the expense of just being "fast  
enough" (but not "faster"), you can serve more users all the time (not  
saying this can't be done with Postgres or any other system).

CouchDB is also a lot simpler than an RDBMS. Less moving parts means  
less bugs, fewer ways to screw up, fewer ways to screw up performance.

I'd wager a non-query-cached multi-table JOIN might end up being  
slower than a document- or view-result read, but there are just too  
many factors including the apples-and-oranges one, that this exercise  
is futile.

In my experience, CouchDB is plenty fast. Certainly fast enough so  
users won't notice a bunch of serial queries that build up a web page,  

> 2. What is on disk layout of couchdb (one big file or the many  
> little or something else) and
>  can we manage where to store various parts of the database in  
> filesystem?

CouchDB can host many databases. Each database lives in a single file  
on the database. Views for a database live in a file each. There are  
two .ini directives that let you specify locations for database- and  
view-files. With symlinks, you are truly flexible.

> 3. Is the current version  tolerant to power failures?


> 4. Can replication be unidirectional?

This is the default case.

>  Can the replication carry out only a certain subset of the  
> documents, not whole database?

Yes and no. At the moment, you can't say "replicate only documents  
where field A has value 'foo'". What you can do though, is write  
validation functions on the target servers that reject writes where  
documents have a field A that doesn't have the value 'foo'. This  
doesn't save you sending all docs to all nodes, but nodes would only  
ever accept the ones you want to be there. The other case will likely  
show up in future versions of CouchDB.

> 5. What are the advantages/key differense of the couchdb compared  
> with the existing projects like MongoDB?

Ease of use, speed, simplicity: Pick two.

See Benoit's link for a more detailed answer :)


View raw message