incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Bigcouch vs couchbase
Date Thu, 27 Mar 2014 09:17:33 GMT
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 <siriele2x3@gmail.com> 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
> <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
View raw message