Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Bigcouch vs couchbase
From: Robert Samuel Newson <rnewson@apache.org>
In-Reply-To: 
 <CAPNuaCj6QZfxQ8u6FwH0hGopVka+KJH4d3g7Ok-PS=daKc6p5Q@mail.gmail.com>
Date: Thu, 27 Mar 2014 07:34:43 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A1DDB62-4F79-442A-88A2-4751CEEA6928@apache.org>
References: 
 <CAPNuaCjxnhtD7mQ3dP0qC--Kb7EKAsDbf1GToCDwMuV5-ikF6Q@mail.gmail.com>
 <6A28FEB1-09C3-4BB2-8D87-6BBC98688A5D@couchbase.com>
 <CAPNuaCgw2VTS-J6fSOVhfCfsWJ_AXPkEkT-9Ou0fUWjuhGRymg@mail.gmail.com>
 <0E91F9E7-2FA5-41A2-BC9B-CF5AC6603921@couchbase.com>
 <CAPNuaCih-OH3rj5GT6--EGnTHBZL8_ruuh6ZwhUxsfcmwXFYMg@mail.gmail.com>
 <CAPNuaCjpv=O+RhXKaMmJsfeLE4ZwZ2u0wmetqnCXFjzQyMtAng@mail.gmail.com>
 <CAJNb-9oUDqWByfRHSmFNU1V7s6=mXHhXnLc+QUB1jWhgJKXJYQ@mail.gmail.com>
 <CAPNuaCj6QZfxQ8u6FwH0hGopVka+KJH4d3g7Ok-PS=daKc6p5Q@mail.gmail.com>
To: user@couchdb.apache.org

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=92s is a 201, obviously). In =
the even that they don=92t match, BigCouch waits for the third response.

With N=3D3,R=3DW=3D2, BigCouch does not, by default, return "stale data" =
if you mean "I won=92t see my write if I=92m 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=92s.=
 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?
>=20
> 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:
>=20
>> On Thursday, March 27, 2014, Stanley Iriele <siriele2x3@gmail.com> =
wrote:
>>=20
>>> 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..
>>=20
>>=20
>>=20
>> couchabase has no revision tree / docs.  the mvcc has been removed  =
to not
>> impact the performances.
>>=20
>> - benoit
>>=20
>>> On Mar 26, 2014 2:58 PM, "Stanley Iriele" <siriele2x3@gmail.com
>> <javascript:;>>
>>> wrote:
>>>=20
>>>> Thanks again Jens for the reply... Couchbase has documentation on
>>>> this...and gobs of marketing... But bigcouch does not...
>>>>=20
>>>> 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=3D2 for consent read... What does bigcouch =
do?
>>>>=20
>>>> Potentially return stale data?.. Throw an error?....
>>>>=20
>>>> 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:
>>>>=20
>>>>>=20
>>>>> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <siriele2x3@gmail.com
>> <javascript:;>>
>>> wrote:
>>>>>=20
>>>>>> Why would you say that couchbase scales better?...
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>> And does bigcouch ever return conflicts to the user? How is the
>> "which
>>>>> write won" problem solved?
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> --Jens
>>>>=20
>>>>=20
>>>=20
>>=20