CouchBase mixed with Memcached, loss of most CouchDB philosophies and functionality?

Question

As of now, the only way i have worked with newer versions of CouchBase, is through a memcached Client. I use Erlang as the programming language and so i had grabbed myself an Erlang Memcached Client. I noticed that this client serialises and de-serialises erlang terms (both Key and Value) by converting them from and to binary using erlang:term_to_binary/1 and erlang:binary_to_term/1 when sending and receiving data from memcached.

While setting up CouchBase, we are asked to choose either memcached buckets or CouchBase buckets (vbuckets). Now, i chose CouchBase (because i needed persistence). I started interacting with the setup using the erlang memcached client and it is okay, i save erlang terms and get back erlang terms from the database. However, the problems begin here:

1. Because of data serialization, objects are received as attachments.Even if sent as JSON From Erlang, they are sent as binary data which makes no meaning to CouchBase (or Memcached ?)

{ 
    "_id": "mykey",
    "_rev": "1-000010fb1a2b02ef0000000d59960000",
    "$flags": 38489, 
    "$expiration": 0,
    "$att_reason": "invalid_json",
    "_attachments": {
    "value": {
                "content_type": "application/content-stream",
                "revpos": 2,
                "digest": "md5-n3mJhf2kKVQtkIunIbCJZQ==",
                "length": 13,
                "stub": true
            }
        }
    }

2. As a result of this, this data cannot be searched, manipulated through CouchDB views. The only way to get the data is by "Key", however nested an object may be. With original Couch DB, we could write Advanced Views, Map reduce to search and manipulate JSON data in the database e.t.c

3. Hence, we cannot clearly use things like: Couch Apps and Design Documents with Couch Base as we used to do with Couch DB, because, these features are meant for JSON data processing within Couch.

Questions
1. I understand that CouchBase is looking at a different approach from CouchDB, however, as a developer i feel like a lot has been taken away from us. No more Couch Apps, Design Docs, Views, e.t.c ?
2. Probably, i am getting something wrong here, can some one please show me how i can still do all this with Couch Base as i did with original Couch DB ?
3. Is there any other way to insert, read or update data in Couch Base 1.8 and above, (using erlang) other than an Erlang memcached client ? This is because, there is data serialization which makes this data useless to other technologies within the same project as they may not be able to decode Erlang data Structures
4. In a multi-language project where we have PHP Developers, C++, Erlang, Ruby e.t.c. working with the same Couch Base instance (Database), with the data serialization, how are we supposed to access and understand data across all technologies ?

Someone assist point out the changes from CouchDB to Couch Base, explain why the new Couch Base is so tied up to Memcached to a point where by we have to use memcached clients to speak with CouchBase. Also, if there is another Erlang-to-CouchBase SDK which can help me speak JSON (and NOT serialized data) from and to Couch Base, i wish to lay my hands on it.

** EDIT **
Assume the following: CouchBase x86_64 1.8.0 and Erlang OTP R15B. I need to work with JSON data in Couch Base so that in a large multi-language project, our applications operate the same data set without having serialization challenges. Thank you

Answer 1

The relationship between Couchbase and CouchDB is covered in detail here: http://www.couchbase.com/couchdb

In short, Couchbase is aimed at the main NoSQL use-case: big data that must be available for end-user interaction. Things like session storage for ad-targeting, game data storage for fast growing social games. Or anywhere user demands can grow unexpectedly.

Couchbase is horizontally scalable, CouchDB is not. To get the scalability and speed Couchbase offers, we've hat to cut back some of the features people like in CouchDB. It's a different set of tradeoffs, but the common denominator is the JSON and the map reduce index model.

Answer 2

There's a big difference between CouchDB and Couchbase, if I'm right Couchbase use CouchDB to store the data but do not offer/present the views and others nice functionality of CouchDB.

I went through the different API (ruby, php) from the Couchbase website and the Couchbase server documentation and I didn't find anything about view or map-reduce. see doc: http://www.couchbase.com/docs/couchbase-manual-1.8.pdf

Couchbase looks more like a memcache server with a persistence layer powered by CouchDB, and maybe it does not fit your needs. The data that you can store within can be anything from int to something serialize such as JSON, but in this case you have to unserialize it on all ends.

Why are you using Couchbase instead of CouchDB? I do not have experience of the older Couchbase versions but I know that these name, even if they are quite similar refer to different applications and maybe it do worth looking further if it's really the one you are thinking about.

Edit Interesting link: http://damienkatz.net/2012/01/the_future_of_couchdb.html read the comments as well, lot of interesting stuff within.

From the comment I understand that Damien Katz is now working on this new project called Couchbase but it's not CouchDB's last version but just another NoSQL database.

So if you were used to CouchDB you could just use the last version of CouchDB. Or if you want to consider switching to Couchbase, look at the features, roadmap for 2.0, etc. and investigate if it does really fit your needs.

Answer 3

With respect to Cyprien, your question does have a real answer besides "don't use Couchbase."

Memcache allows many more data types than CouchDB. Specifically, you can Memcache an empty string, the string "{", the string "0", or the string "{}". Only the last one is a valid JSON object that you can use as a CouchDB document. AFAIK the way that Couchbase works is that if a string that you SET or ADD is the JSON representation of a valid CouchDB document, it stores it as a CouchDB document, otherwise it stores it as an attachment. [zIt's a design decision that I don't agree with (they could have just inserted a $value key into the CouchDB document) but it kind of makes sense given that you could be passing very large objects, actual attachments, over the protocol interface.] Regardless, the "$att_reason": "invalid_json" is your hint that this is happening.

The upcoming version of Couchbase, 2.0, now in developer preview, exposes almost all of the CouchDB functionality, except for Couch Apps (which are irrelevant if you're using Erlang anyways). So if you want to use that, you'll want to pass JSON of objects over the Memcache interface, but note that then you lose Memcache's atomic shortcuts (you'd need to do a compare-and-swap, which requires an extra network hop).