I'm definitely a database noob so I'm looking for correction -- but isn't the main advantage of CouchDB / Tokyo Cabinet etc. that it's much simpler to spread them horizontally across multiple machines in a similar fashion to memcache? From what I understand, the main problem with MySQL / other traditional databases is that the complexity of your architecture increases dramatically as you go scale beyond one server as you have to deal with all sorts of problems with data replication whereas with CouchDB, it's much more straightforward to spread the data around. Is that correct?

Kyle

Research Assistant
Entrepreneurship and Technology Center @ BYU
kyle.mathews2000.com/blog


On Tue, May 5, 2009 at 4:29 PM, Mikkel Høgh <m@ooh.dk> wrote:
On Wed, May 6, 2009 at 12:02 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
> CouchDB is a RESTful web service package, which has a storage engine
> that uses MVCC (Postgres, Oracle, InnoDB), and b-tree indexes (used by
> most RDBMSs), with sequence ids (supported by most RDBMSs).  So,
> really comparing CouchDB to MySQL or Postgres is to compare apples and
> baked tarts made with apples.

I'd say that's an awesome analogy. If you're not looking for baked
goods, but perhaps apple sauce, raw apples might be preferable…

On the other hand, if you intent to consume it with whipped cream
anyhow, why not just grab the finished tart while you're at it…

> And Tokyo Cabinets -- hmmm.  Serialized data versus structured data
> and database wide unique keys.  DBM primitives?  Again, it remains to
> be seen whether it's faster than an SQL engine when combined with
> something like Tokyo Tyrant to provide the needed concurrency
> capabilities.

Yeah, unless someone is going to actually try to come up with some
real numbers for what it would mean for our use case, this is debate
probably going to be a precious waste of bytes ;)