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" <[email protected]> wrote:
> > 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >
