incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: Bigcouch vs couchbase
Date Thu, 27 Mar 2014 16:50:32 GMT
Thanks Jens... I knew that the key value storage from memcache and
apologies for my typos... Long day :-).

+1 for Russell s comment. I was thinking the same thing! Probably in a FAQ
of some sort because the only tragedy here is that otherwise... The only
people who will know this are the developers and others on this mailing list
On Mar 27, 2014 9:20 AM, "Russell Branca" <chewbranca@gmail.com> wrote:

> 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