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 17:00:21 GMT

There’ll definitely be official documentation on the clustering part of couchdb.

On 27 Mar 2014, at 16:50, Stanley Iriele <siriele2x3@gmail.com> 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" <chewbranca@gmail.com> 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
>> <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