Hi Randall, With a response time like that, efficiency is your strong point.
First of all, seeing as through there are a number of “solutions”, it's clear that there are positives to come from a fully distributed CouchDB database. So I am not put off by that. Next, you suggest potential like solution as Cassandra and Dynamo. I'd tend to agree, as these are stable distributed systems. On saying that, Cassandra doesn't use Erlang (as a Java implementation), though it adopted the flexible column layout from Google's BigTable. I've also had a look at MongoDB, which is a C++ implementation, but with similar goals as CouchDB (document-oriented database). They are currently working on database partitioning, though it's in its alpha stages, in version 1.5.3. I imagine that MongoDB could be a good design guide for CouchDB in the future should its sharding implementation matures. In a slightly unrelated note, can I point you to a paper published in February, 2010 - “Key/Value Datastores Comparison in AppScale”. Briefly, AppScale is a open source drop-in replacement for Google's App Engine, and provides API's to Cloud based web applications (typicall), and at the backend that have plugged in their app API's to the API's of 7 distributed databases (including Cassandra and MongoDB). What are the chances of attaching CouchDB to the AppScale API's ? My final point is Scalaris. (Google “Reliable Transactional P2P Key/Value Store”). Like CouchDB, it is a P2P datastore, implemented in Erlang. Appears to be similar in design and implementation to CouchDB, to me? It uses Chord# to storing and retreiving key/values in nodes. It seemingly has support for Heterogeneous hardware clusters, and it currently uses an in-memory disctionary for database stores, though using Mnesia has been suggested. Is that enough, to generate discussion, Randall ? Rob Stewart
