Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of siriele2x3@gmail.com
 designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6A28FEB1-09C3-4BB2-8D87-6BBC98688A5D@couchbase.com>
References: 
 <CAPNuaCjxnhtD7mQ3dP0qC--Kb7EKAsDbf1GToCDwMuV5-ikF6Q@mail.gmail.com>
	<6A28FEB1-09C3-4BB2-8D87-6BBC98688A5D@couchbase.com>
Date: Wed, 26 Mar 2014 09:31:05 -0700
Message-ID: 
 <CAPNuaCgw2VTS-J6fSOVhfCfsWJ_AXPkEkT-9Ou0fUWjuhGRymg@mail.gmail.com>
Subject: Re: Bigcouch vs couchbase
From: Stanley Iriele <siriele2x3@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c2c580c7260704f584fe3d

--001a11c2c580c7260704f584fe3d
Content-Type: text/plain; charset=ISO-8859-1

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" <jens@couchbase.com> wrote:

>
> On Mar 26, 2014, at 12:43 AM, Stanley Iriele <siriele2x3@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

--001a11c2c580c7260704f584fe3d--