Thanks for the congrats! We're excited about seeing these to products
converge. I'll do what I can to answer the questions you asked, but at
this stage, things are quite formative. If you have ideas/input on
what you'd like to see, please let us know.
On Feb 10, 2:11 am, Joshua Partogi <joshua.part...@gmail.com
> Hi Matt,
> That is a great news! Congrats for this merger. I have one question
> about this merger.
> How will the end product of CouchBase will be?
> 1. How will client connect to the database? HTTP API or Memcached
Likely both. We won't stop supporting Memcached's protocol as so much
depends on it, and the "snap in" replacement between Memcached and
Membase is a valuable feature that's a priority to keep in Couchbase.
CouchDB, of course, has it's own REST API for adding documents, and
that will need to be exposed at some level for replication, browser-
based apps, etc. So a mix of the two is most likely.
> 2. How will our data stored? Key-value or document?
The key (heh) difference between Key/Value and Document databases is
that in a Dcoument DB the docs are indexable--whereas the value of
keys in a K/V DB are not (typically). In CouchDB, a document is simply
the value of a key. However, CouchDB adds obvious constraints on the
type of value whereas Membase/Memcached does not. The best approach to
mixing these two is still open to discussion, but having the full
strength of both is important.
In a way CouchDB's attachments system is similar to a key/value store
in that they can be arbitrary files (JSON, images, whatever). It may
be that there are "attachment only" documents that contain the non-
JSON data in Couchbase--if you've upgraded from Membase for example.
All of this is in the initial planning stages, so no promises here,
just thoughts/ideas. :)
> 3. How will we query our data? Map-reduce or simple key lookup?
We'll be providing something beyond simple key look-up, but there's
(again) lots to figure out on how best to approach this problem.
> 4. How will it scale?
Up and out. :) CouchDB's scaling model is primarily horizontal
(replication). Membase provides a mix of both: more RAM and disk to go
"up" and more nodes to go "out." Scalability is an obvious priority
for both projects, and "by our powers combined" you'll have far more
options that before--scaling "down" to phones and "up" to Cloud-based
Hope that answers a few questions. I'm sure others will chime in soon
Thanks again for asking,