couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 20:28:07 GMT
Just for reference, most SQL databases ship with the fsync to their log on a
1s or longer cycle, it's pretty standard.

delayed-commits on doesn't reduce durability because the writes to log are
still append-only and can survive invalid writes and crashes and all that.
Also, they don't reduce runtime consistency because the response isn't
returned until the document is available. All they do is give the client a
*different* consistency guarantee (available rather than persisted to disc).

Personally, i think it's better to default the guarantee to persisted but I
can see why it's advantageous for some configurations to opt for the other.
The real question here is what guarantee we want to ship with by default,
one that optimizes single writer performance or one that offers a better
guarantee and is still performant under concurrent load.


On Tue, Jul 6, 2010 at 1:07 PM, Klaus Trainer <> wrote:

> Just to put my two cents in...
> It's a matter of to be or not to be (ACID (by default)).
> With delayed_commits=true, data operations aren't durable anymore.
> Consequently, if it's the default setting, some people might say that
> CouchDB does not meet ACID requirements. People mostly tend to simplify.
> We will hardly be able to eliminate (sometimes vicious) superficiality,
> but we rather should face the fact that such partially true assertions
> may be harmful.
> Take MySQL as an example: there are (still) people stating that MySQL is
> not ACID compliant and doesn't support transactions. They are partially
> right with that: it's true for the default storage engine (MyISAM), but
> definitely not for InnoDB.
> With choosing stronger guarantees by default--as long as it goes in line
> with basic design decisions--we just eliminate any room for such
> confusion (or maybe even FUD that is spread by competitors). Basically,
> when comparing with other databases, that's way more important than a
> higher rank in an inadequate performance benchmark (pissing contest).
> - Klaus
> On Tue, 2010-07-06 at 16:43 +0200, Benoit Chesneau wrote:
> > I would prefer to put delayed_commits=false too, to keep the promise
> > we give to our users. We can't say on one side we are better than
> > mongo for this while a simple power failure may result in lost of data
> > by default (even if we are better since dbs won't be corrupted).
> >
> > The default should be the strongest imo. Like every os should be
> > secure by default, we should  let the user know, we do the best *by
> > default* to make sure data are safe on the disk. While they still have
> > the possibility to bypass this "security" . But in this case, this is
> > a choice.
> >
> > For those who worry about the marketing, this is also a good point of
> > differentiation compared to others dbs. (/me remove his marketing hat)
> > .
> >
> > - benoit

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message