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 18:17:17 GMT
Jens I had not read your update till now..that is the clearest explanation
of how couchbase works I've read to date... Between this and Robert's
comment earlier I now know how I can use either data store...and more
importantly I know how NOT to use them. Many thanks gentlemen
On Mar 27, 2014 10:00 AM, "Robert Samuel Newson" <rnewson@apache.org> wrote:

>
> There'll definitely be official documentation on the clustering part of
> couchdb.
>
> On 27 Mar 2014, at 16:50, Stanley Iriele <siriele2x3@gmail.com> wrote:
>
> > 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