incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim McCoy <jim.mc...@gmail.com>
Subject Re: Transactional _bulk_docs
Date Fri, 06 Feb 2009 18:17:02 GMT
On Thu, Feb 5, 2009 at 10:10 PM, Antony Blakey <antony.blakey@gmail.com> wrote:

> On 06/02/2009, at 3:43 PM, Paul Davis wrote:
>> A brief history:
[...]
>> Damien: I don't think we can support transactional commits in the face
>> of multiple nodes. We can do ACID writes to disk so that updates
>> aren't lost, but checking with an unbounded number of servers that a
>> commit doesn't conflict isn't feasible.
>
> Not unbounded. Look at Scalaris.

Returning, as always, to Brewer's CAP conjecture, you can have any two
of consistency, availability, or partition-tolerance.  Scalaris went
with paxos sync and selected consistency and partition-tolerance.
This means that if you lose a majority of your Scalaris nodes it
becomes impossible to log a write to the system. In CouchDB
availability and partition-tolerance were prioritized ("eventual
consistency" being that pleasant term we use to play down the fact
that no consistency assurances can actually be made beyond a
best-effort attempt to fix things after the fact.)

I believe the "unbounded number of servers" that Damien was mentioning
was referring to the idea that with multi-node operations the activity
over which you want an ACID commit could become a very large set if
the number of participating nodes grows significantly.  This would
mean that a large system would require an ever-growing number of
messages to be passed around, which is a scalability bottleneck.

It is simply not possible to offer what you want within CouchDB unless
either availability or partition-tolerance are sacrificed.  If you
want to relax availability then you might as well use Scalaris or
Dynomite, if you want to relax partition-tolerance then go with MySQL
or other off the shelf RDBMS.  A better approach, which seems to have
been suggested somewhat obliquely several times, is to put a layer
between your client and CouchDB which performs a paxos sync across all
of the participating nodes; this would become the "transactional API"
for the system, enabling you to perform a consistent update (via the
middleware layer) when necessary and allowing you to pass straight
through this layer directly to CouchDB when it is not needed.

jim

Mime
View raw message