There’ll definitely be official documentation on the clustering part of couchdb.
On 27 Mar 2014, at 16:50, Stanley Iriele <[email protected]> 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" <[email protected]> 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 >> <[email protected]>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 <[email protected]> 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" <[email protected]> >> wrote: >>>> >>>>> On Thursday, March 27, 2014, Stanley Iriele <[email protected]> >>> 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" <[email protected] >>>>> <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" <[email protected] >>>>> <javascript:;>> >>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <[email protected] >>>>> <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 >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>
