You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Stanley Iriele <si...@gmail.com> on 2014/03/26 08:43:31 UTC
Bigcouch vs couchdb
I'm trying to find a document comparing the two... Especially from a CAP
theorem / distributed write perspective.
How does bigcouch handle multiple simultaneous writes ? Is it first to
write?.... How is couchbase different?...
There is no clear comparison between documentation the on these aspects
anywhere...let alone docs on bigcouch at this level. I'm just trying to
understand these 2 distributed systems from CAP theorem perspective....
Re: Bigcouch vs couchdb
Posted by Stanley Iriele <si...@gmail.com>.
Apologies for the title.. It should be bigcouch vs couchbase
On Mar 26, 2014 12:43 AM, "Stanley Iriele" <si...@gmail.com> wrote:
> I'm trying to find a document comparing the two... Especially from a CAP
> theorem / distributed write perspective.
>
> How does bigcouch handle multiple simultaneous writes ? Is it first to
> write?.... How is couchbase different?...
>
> There is no clear comparison between documentation the on these aspects
> anywhere...let alone docs on bigcouch at this level. I'm just trying to
> understand these 2 distributed systems from CAP theorem perspective....
>
Re: Bigcouch vs couchbase
Posted by Robert Samuel Newson <rn...@apache.org>.
"The key-value storage part of Couchbase Server is *NOTHING* like CouchDB. At all. Stop thinking of them as being related"
Well said. I think the comparison topic is well covered now, those that want more details of products other than CouchDB can find more details in the documentation and other resources of those projects.
B.
On 27 Mar 2014, at 14:24, Jens Alfke <je...@couchbase.com> wrote:
>
> On Mar 26, 2014, at 8:25 PM, Stanley Iriele <si...@gmail.com> wrote:
>
>> You said couchbase doesn't have MVCC ? All docs say That it
>> uses couchDB MVCC append only under the good on a single node…
>
> I’ve read that second line four times and I can’t figure out what the heck it means. “Under the good”?
> Oh wait, you mean “under the hood”? Yes, the nodes use CouchDB databases for persistence. But the MVCC semantics aren’t exposed. See below.
>
>> Could you elaborate a tad on what you mean by doesn't have MVCC?
>
> MVCC stands for “Multi-Version Concurrency Control”. Wikipedia:
>
> “…each user connected to the database sees a snapshot of the database at a particular instant in time. Any changes made by a writer will not be seen by other users of the database until the changes have been completed (or, in database terms: until the transaction has been committed.)
> When an MVCC database needs to update an item of data, it will not overwrite the old data with new data, but instead mark the old data as obsolete and add the newer version elsewhere.”
>
> Couchbase Server doesn’t store multiple versions of a document*. Nor does it use snapshots of the database state.
>
> The key-value storage part of Couchbase Server is *NOTHING* like CouchDB. At all. Stop thinking of them as being related. It inherits from memcached, which is a distributed in-memory cache engine.
>
> The CouchDB heritage of Couchbase Server is used for two things: (a) _asynchronously_ writing the documents to a CouchDB b-tree for persistence, and (b) indexing that b-tree with map-reduce views that can be queried queried almost exactly like CouchDB.
>
> Each node has an in-memory key->value map that’s read and updated by clients. Note: writes are made directly in RAM. (This is part of the “insane speed” thing.) A parallel task collects all the updated values and writes them to a CouchDB-compatible b-tree file. Another parallel task sends the changes to the neighboring nodes so they can keep backups in case this node goes down.
>
> So when client A does a Put and then client B does a Get, client B gets the value from RAM that client A wrote there a few microseconds earlier. The database file isn’t involved all. No MVCC.
>
> This is getting long, but I want to add that in my experience if you try to use Couchbase Server as though it were CouchDB, you’ll get very frustrated — viewed that way it feels primitive and unreliable. You have to treat it as its own thing and accept that you’re making trade-offs for performance/scalability, and must use different hammers to solve your problems. (And of course, if you want CouchDB-style semantics, you can add the Couchbase Sync Gateway. But you won’t get the same performance as raw Couchbase.)
>
> —Jens
>
> * OK, technically the database file used for persistence contains multiple versions of the document since it’s append-only. But the old versions are never accessed, and there’s no way to get to them through the API, so they may as well not exist.
Re: Bigcouch vs couchbase
Posted by Jens Alfke <je...@couchbase.com>.
On Mar 26, 2014, at 8:25 PM, Stanley Iriele <si...@gmail.com> wrote:
> You said couchbase doesn't have MVCC ? All docs say That it
> uses couchDB MVCC append only under the good on a single node…
I’ve read that second line four times and I can’t figure out what the heck it means. “Under the good”?
Oh wait, you mean “under the hood”? Yes, the nodes use CouchDB databases for persistence. But the MVCC semantics aren’t exposed. See below.
> Could you elaborate a tad on what you mean by doesn't have MVCC?
MVCC stands for “Multi-Version Concurrency Control”. Wikipedia:
“…each user connected to the database sees a snapshot of the database at a particular instant in time. Any changes made by a writer will not be seen by other users of the database until the changes have been completed (or, in database terms: until the transaction has been committed.)
When an MVCC database needs to update an item of data, it will not overwrite the old data with new data, but instead mark the old data as obsolete and add the newer version elsewhere.”
Couchbase Server doesn’t store multiple versions of a document*. Nor does it use snapshots of the database state.
The key-value storage part of Couchbase Server is *NOTHING* like CouchDB. At all. Stop thinking of them as being related. It inherits from memcached, which is a distributed in-memory cache engine.
The CouchDB heritage of Couchbase Server is used for two things: (a) _asynchronously_ writing the documents to a CouchDB b-tree for persistence, and (b) indexing that b-tree with map-reduce views that can be queried queried almost exactly like CouchDB.
Each node has an in-memory key->value map that’s read and updated by clients. Note: writes are made directly in RAM. (This is part of the “insane speed” thing.) A parallel task collects all the updated values and writes them to a CouchDB-compatible b-tree file. Another parallel task sends the changes to the neighboring nodes so they can keep backups in case this node goes down.
So when client A does a Put and then client B does a Get, client B gets the value from RAM that client A wrote there a few microseconds earlier. The database file isn’t involved all. No MVCC.
This is getting long, but I want to add that in my experience if you try to use Couchbase Server as though it were CouchDB, you’ll get very frustrated — viewed that way it feels primitive and unreliable. You have to treat it as its own thing and accept that you’re making trade-offs for performance/scalability, and must use different hammers to solve your problems. (And of course, if you want CouchDB-style semantics, you can add the Couchbase Sync Gateway. But you won’t get the same performance as raw Couchbase.)
—Jens
* OK, technically the database file used for persistence contains multiple versions of the document since it’s append-only. But the old versions are never accessed, and there’s no way to get to them through the API, so they may as well not exist.
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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" <rn...@apache.org> wrote:
>
> There'll definitely be official documentation on the clustering part of
> couchdb.
>
> On 27 Mar 2014, at 16:50, Stanley Iriele <si...@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" <ch...@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
> >> <rn...@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 <si...@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" <bc...@gmail.com>
> >> wrote:
> >>>>
> >>>>> On Thursday, March 27, 2014, Stanley Iriele <si...@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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: Bigcouch vs couchbase
Posted by Robert Samuel Newson <rn...@apache.org>.
There’ll definitely be official documentation on the clustering part of couchdb.
On 27 Mar 2014, at 16:50, Stanley Iriele <si...@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" <ch...@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
>> <rn...@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 <si...@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" <bc...@gmail.com>
>> wrote:
>>>>
>>>>> On Thursday, March 27, 2014, Stanley Iriele <si...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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" <ch...@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
> <rn...@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 <si...@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" <bc...@gmail.com>
> wrote:
> > >
> > >> On Thursday, March 27, 2014, Stanley Iriele <si...@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
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Bigcouch vs couchbase
Posted by Russell Branca <ch...@gmail.com>.
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
<rn...@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 <si...@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" <bc...@gmail.com> wrote:
> >
> >> On Thursday, March 27, 2014, Stanley Iriele <si...@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
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Bigcouch vs couchbase
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <si...@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
> <rn...@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 <si...@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" <bc...@gmail.com> wrote:
>>>
>>>> On Thursday, March 27, 2014, Stanley Iriele <si...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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
<rn...@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 <si...@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" <bc...@gmail.com> wrote:
> >
> >> On Thursday, March 27, 2014, Stanley Iriele <si...@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
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Bigcouch vs couchbase
Posted by Robert Samuel Newson <rn...@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’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 <si...@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" <bc...@gmail.com> wrote:
>
>> On Thursday, March 27, 2014, Stanley Iriele <si...@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
>>>>
>>>>
>>>
>>
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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" <bc...@gmail.com> wrote:
> On Thursday, March 27, 2014, Stanley Iriele <si...@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
> > >
> > >
> >
>
Re: Bigcouch vs couchbase
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thursday, March 27, 2014, Stanley Iriele <si...@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
> >
> >
>
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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..
On Mar 26, 2014 2:58 PM, "Stanley Iriele" <si...@gmail.com> 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" <je...@couchbase.com> wrote:
>
>>
>> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <si...@gmail.com> wrote:
>>
>> > Why would you say that couchbase scales better?...
>>
>> That's getting way off-topic for this list, but http://couchbase.com has
>> 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
>
>
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
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" <je...@couchbase.com> wrote:
>
> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <si...@gmail.com> wrote:
>
> > Why would you say that couchbase scales better?...
>
> That's getting way off-topic for this list, but http://couchbase.com has
> 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
Re: Bigcouch vs couchbase
Posted by Jens Alfke <je...@couchbase.com>.
On Mar 26, 2014, at 9:31 AM, Stanley Iriele <si...@gmail.com> wrote:
> Why would you say that couchbase scales better?…
That’s getting way off-topic for this list, but http://couchbase.com has 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
Re: Bigcouch vs couchbase
Posted by Stanley Iriele <si...@gmail.com>.
Thanks for that explanation... The documentation around this area is sparse
at best. I know that bigcouch uses a quorum for consent reads and writes...
I am not sure if it is possible to get stale data in bigcouch since each
Nide knows the keyspace and the node that owns that key....I am however a
tad biased towards couchDB though... List ,show, and update handler
functions give me a nice abstraction saves me the cost of a get and a put
of a giant blobs..but more importantly... The business logic of an update
is not sprinkled all over code... That said...the sync gateway in couchbase
is written in go.. So...that's an instant +1in my book.. But I digress
Why would you say that couchbase scales better?... And does bigcouch ever
return conflicts to the user? How is the "which write won" problem solved?
On Mar 26, 2014 8:22 AM, "Jens Alfke" <je...@couchbase.com> wrote:
>
> On Mar 26, 2014, at 12:43 AM, Stanley Iriele <si...@gmail.com> wrote:
>
> > How does bigcouch handle multiple simultaneous writes ? Is it first to
> > write?.... How is couchbase different?...
>
> In Couchbase Server the key-space is partitioned among the nodes in the
> cluster, so each key is 'owned' by one node at a time. So for any one key
> there is strict causality, i.e. a total ordering of events. Couchbase
> doesn't have MVCC nor does it store histories of documents. Instead every
> document has a "CAS" value which is basically a 64-bit change counter. You
> can perform optimistic updates by using a set-with-CAS operation that will
> fail if the document's current CAS doesn't match the value you supplied.
> There's also a Lock operation to obtain a temporary lease on a key, and a
> handy Increment operation that operates atomically on integer-valued
> (non-JSON) keys.
>
> AFAIK, BigCouch also partitions the key-space, in which case it doesn't
> have simultaneous writes either.
>
> That said, these are two rather different databases. Couchbase Server is
> faster (it's faster than just about anything else) and probably more
> scaleable, but its durability/consistency guarantees are weaker, and its
> replication between clusters (XDCR) isn't nearly as advanced.
>
> --Jens
Re: Bigcouch vs couchbase
Posted by Jens Alfke <je...@couchbase.com>.
On Mar 26, 2014, at 12:43 AM, Stanley Iriele <si...@gmail.com> wrote:
> How does bigcouch handle multiple simultaneous writes ? Is it first to
> write?.... How is couchbase different?…
In Couchbase Server the key-space is partitioned among the nodes in the cluster, so each key is ‘owned’ by one node at a time. So for any one key there is strict causality, i.e. a total ordering of events. Couchbase doesn’t have MVCC nor does it store histories of documents. Instead every document has a “CAS” value which is basically a 64-bit change counter. You can perform optimistic updates by using a set-with-CAS operation that will fail if the document’s current CAS doesn’t match the value you supplied. There’s also a Lock operation to obtain a temporary lease on a key, and a handy Increment operation that operates atomically on integer-valued (non-JSON) keys.
AFAIK, BigCouch also partitions the key-space, in which case it doesn’t have simultaneous writes either.
That said, these are two rather different databases. Couchbase Server is faster (it’s faster than just about anything else) and probably more scaleable, but its durability/consistency guarantees are weaker, and its replication between clusters (XDCR) isn’t nearly as advanced.
—Jens