incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@gmail.com>
Subject Re: Bigcouch vs couchbase
Date Thu, 27 Mar 2014 16:19:39 GMT
On a side not to this thread, this is a great introduction to quorum
semantics in BigCouch, thanks Newson! We should throw this into the new
wiki as at least a starting point for documenting clustered CouchDB.


-Russell


On Thu, Mar 27, 2014 at 12:34 AM, Robert Samuel Newson
<rnewson@apache.org>wrote:

> Hi,
>
> A read or write to a BigCouch cluster (this will be true for CouchDB soon
> too) happens to all 3 replicas of a shard in parallel. By default, BigCouch
> waits for the first 2 results, so long as they match, before returning the
> result to the user (two 201's is a 201, obviously). In the even that they
> don't match, BigCouch waits for the third response.
>
> With N=3,R=W=2, BigCouch does not, by default, return "stale data" if you
> mean "I won't see my write if I'm too quick". But do note that BigCouch is
> explicitly AP not CP, so there are conditions where this will happen. If
> the network is split (strictly, if the nodes think the network is split)
> all nodes will still honor read and write requests. When the network heals,
> CouchDB replication runs between all the pairs of replicas (aka Eventual
> Consistency).
>
> BigCouch does use consistent hashing, so we can always calculate which
> nodes should hold a copy of a particular document if it exists. Concurrent
> updates to the same document have similar semantics to CouchDB but it is
> possible for both writes to succeed (at different replicas) without
> succeeding at all replicas. The status codes of the requests will reflect
> that. For a write, a 409 is returned if all replicas returned 409, a 201 if
> all replicas returned 201, and a 202 if at least one replica returned 201
> but the other replicas returned 409's. The replicas themselves run CouchDB
> replication (though an optimized, non-http version) whenever they are
> updated, and this ensures all branches of all documents reach every replica.
>
> Did I miss a question?
>
> Some useful links;
>
> https://cloudant.com/blog/dynamo-and-couchdb-clusters/
>
> https://cloudant.com/blog/bigcouch-0-3/
>
> https://cloudant.com/blog/bigcouch-zero-point-four/
>
>
> On 27 Mar 2014, at 06:00, Stanley Iriele <siriele2x3@gmail.com> wrote:
>
> > This is again extremely helpful...thanks... MVCC says... Hey...while
> you're
> > writing... "Every one is still pointing to the old one for reads"... But
> > the moment its done... Look at this new one" if it doesn't do that it has
> > to do something about simultaneous read write right?
> >
> > Also.. Does bigcouch return stale data... Ever?... Like the example I
> > described above?... This mail thread really needs to be in a doc
> somewhere
> > BTW.. Again many thanks
> > On Mar 26, 2014 10:45 PM, "Benoit Chesneau" <bchesneau@gmail.com> wrote:
> >
> >> On Thursday, March 27, 2014, Stanley Iriele <siriele2x3@gmail.com>
> wrote:
> >>
> >>> Also... Jens... You said couchbase doesn't have MVCC ? All docs say
> That
> >> it
> >>> uses couchDB MVCC append only under the good on a single node... Could
> >> you
> >>> elaborate a tad on what you mean by doesn't have MVCC?... Also for the
> >>> couchDB advocates...I think discussions about this are incredibly
> helpful
> >>> for all parties involved..
> >>
> >>
> >>
> >> couchabase has no revision tree / docs.  the mvcc has been removed  to
> not
> >> impact the performances.
> >>
> >> - benoit
> >>
> >>> On Mar 26, 2014 2:58 PM, "Stanley Iriele" <siriele2x3@gmail.com
> >> <javascript:;>>
> >>> wrote:
> >>>
> >>>> Thanks again Jens for the reply... Couchbase has documentation on
> >>>> this...and gobs of marketing... But bigcouch does not...
> >>>>
> >>>> In bigcouch...all nodes can handle every request... But let's say a
> >> node
> >>>> cannot reach the nodes that have a key..like node A knows it needs to
> >>> read
> >>>> from nodes B and C but cannot reach them.... But has a copy of the
> data
> >>>> locally but was given r=2 for consent read... What does bigcouch do?
> >>>>
> >>>> Potentially return stale data?.. Throw an error?....
> >>>>
> >>>> I know that bigcouch is based on the dynamo white paper... But so is
> >>>> Cassandra...and riak and you cab at least find out the answers to
> these
> >>>> questions with a little googling. Again I'm eternally grateful for the
> >>>> responses I'm getting I just wish there more docs....like the couchDB
> >>> docs
> >>>> page that even has a CAP theorem chart..(which is freaking awesome)..
> >>>> On Mar 26, 2014 12:24 PM, "Jens Alfke" <jens@couchbase.com
> >> <javascript:;>>
> >>> wrote:
> >>>>
> >>>>>
> >>>>> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <siriele2x3@gmail.com
> >> <javascript:;>>
> >>> wrote:
> >>>>>
> >>>>>> Why would you say that couchbase scales better?...
> >>>>>
> >>>>> That's getting way off-topic for this list, but
> >> http://couchbase.comhas
> >>>>> a bunch of marketing materials and white papers and such, and we
have
> >>> sales
> >>>>> engineers you can talk to if you really want to dive into it. But
as
> I
> >>>>> said, Couchbase Server and BigCouch are very different.
> >>>>>
> >>>>>> And does bigcouch ever return conflicts to the user? How is
the
> >> "which
> >>>>> write won" problem solved?
> >>>>>
> >>>>> AFAIK BigCouch's document/revision/conflict model is identical to
> >>>>> CouchDBs. MVCC, revision IDs, revision trees, conflicts represented
> as
> >>>>> branched trees, conflict resolution by deleting unwanted branches,
> >> etc.
> >>>>>
> >>>>> --Jens
> >>>>
> >>>>
> >>>
> >>
>
>

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