[development] Database / SQL future thoughts

[Kyle Mathews]

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 at ooh.dk> wrote:

> On Wed, May 6, 2009 at 12:02 AM, Chris Johnson <cxjohnson at 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 ;)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090505/aaf89259/attachment.htm>