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 ;)