Documentation on the clustering semantics is definitely on the list, once the code is merged! :)
B. On 27 Mar 2014, at 08:47, Stanley Iriele <[email protected]> wrote: > Snap No mr Robert you did not!.....That most certainly answers my biggest > bigcouch questions! Many thanks gentlemen. I had a pretty hard time finding > bigcouch documentation so this is really, really helpful. I'll give these > docs a good read before I post anymore..here > > > 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 >>>>>> >>>>>> >>>>> >>>> >> >>
