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" <[email protected]> wrote: > > On Mar 26, 2014, at 12:43 AM, Stanley Iriele <[email protected]> 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
