Hi, My understanding (from a few tweets) is that couchbase v2 isn't a fork of couchdb or membase but a whole new product (a spork/foon) that is more a direct competitor of MongoDB than CouchDB (for the reasons you point out). I couldn't comment on your questions about performance or planned feature set, but I think if you want something that looks like CouchDB you need to use CouchDB or a derivative (BigCouch/Refuge).
Hope that helps (and isn't inaccurate) Cheers Simon On Monday, 6 February 2012 at 23:45, Matt Halstead wrote: > Hi, > > I recently asked a question on couchbase google group about moving > from couchbase single server to couchbase 2.0. I sent it Feb 2nd and > haven't had any response from that list. I was hoping this list was > more active and someone here knew the answers. Ultimately we are > working through whether to follow CouchBase or CouchDB (most likely > BigCouch). The following are my questions. > > ----------snip------------- > Some immediate thoughts and questions after moving from CouchBase > Single Server to CouchBase 2.0 > > Inevitably I felt like you had thrown some of my toys away. Namely, > MVCC, couchDB CRUD APIs, couchapp, the possibility that I could lose > data in memory and not have had it persisted, and any sense that this > was still a database and not just a uber-cache. > > I looked through this mailing list and found some information on the > re-interpretation of versioning - CAS. Can I have a code example (any > API would do) that demonstrates what happens now if we want optimistic > type locking? I realize this might be trivial for memcached users, but > I'm just pointing out the transition for CouchDB people. > > The SYNC instruction was also discussed in the mailing list for > offering synchronous/blocking writes that guarantee either persistence > to disk or replication to another node. But in the 2.0 manual you have > a release note saying that SYNC protocol had been removed. So is this > still possible? I understand the performance implication of this, but > this is a pretty important distinction between a cache and a database > that offers data integrity. > > With CouchBase there is a lot of emphasis put on working sets and RAM. > My first impression was 'oh, I have hundreds of terabytes of data that > is seldom accessed but when I want to access it, I want to access it > fast'. But then I got thinking, If you build your map/reduce/re-reduce > jobs well, the search data set you want often for locating resources > will be in the working set and you can generally 'prime' it into > memory. Which leaves the inevitable question. I then want to access > the full objects that the map/reduce sets reference. These are likely > to not be in memory, but I would like them fast. A database usually > makes this acceptably fast - rotating spindles included - is it the > case the CouchBase will try to ensure this is acceptably fast too? > > CouchApp. While I wasn't really that heavily into the wild corners of > couchapp, I did appreciate being able to build map/reduce jobs on the > filesystem and sync them to the design documents. Is there likely to > be support for something similar in CouchBase? > > ----------------snip----------------- > > > cheers > Matt > >
