3 ms·
One thing I wonder about CouchDB is whether writing scales. Assuming you have a cluster of couchdb nodes. They all replicate, so you can spread reads and write
by lzw 16y ago
One thing I wonder about CouchDB is whether writing scales.
Assuming you have a cluster of couchdb nodes. They all replicate, so you can spread reads and writes over the cluster. As you add nodes, read performance goes up. Initial write performance should as well.
But when you write to node N, then that data needs to be written to nodes 0-(N-1) as well. So every write goes to every node (thru replication). Since writes on CouchDB are syncronous (Eg: only one write at a time) then there is a fixed total write bandwidth on each node. Since a write on any node needs to be replicated, then, assuming the cluster is using identical machines, the total write speed of the cluster would be the same as the write speed of a single node, right?
This is probably not a problem for most cases as reads outnumber writes for web businesses. But it seems this is an area where couchDB isn't scalable.
My assessment is based on the perception that writing data coming via replication is exactly as expensive as writing data coming from the web. Replicated data goes thru the filters, and replicated data has its views recalculated as well.
- carterschonwald 16y agothe thing you're missing is that these single writes can be a "bulk" write of a large number of documents. More over, the single threaded (semantically) writing is an artifact of having append only writing to the db. there are 2 majors wins when you have this approach to a db. 1) append only memory allocation is FAST. If we were talking about writing to ram, its as simple as allocating the interval from i to i + (amount of memory needed), where i is the heap pointer 2) you don't have to deal with locks! Locks are not bad per se, but in many cases lock based data structures can lead to pain later on (just look at home much work has been done on python and linux over time in this matter). Also, I believe that in the case that here aren't conflicting versions of the same doc in two couchdb nodes, replication is essentially bandwidth rate limited. take the time to read up on couchdb. it may not be perfect or appropriate for everything, but it is a very very nice piece of software. And whats really awesome is that as a consequence of the append only semantics, the data loss bug they recently had was totally recoverable for those who hadn't compacted their db's! (how many db's can say that for their data loss bugs?)
- jchrisa 16y agoScaling writes requires partitioning, which can be done in CouchDB with either: http://tilgovi.github.com/couchdb-lounge/ http://tilgovi.github.com/couchdb-lounge/ or in a hosted Erlang version: http://blog.cloudant.com/dynamo-and-couchdb-clusters http://blog.cloudant.com/dynamo-and-couchdb-clusters