

The thrill of a new technology: CouchDB - intinig
http://tempe.st/2009/03/the-thrill-of-a-new-technology-couchdb/

======
jrockway
No, graph databases will rule the world. Couch only supports trees, which is
annoying if you want to have relationships between "documents".

Also, Couch's implementation of map/reduce arbitrarily limits the kinds of
queries you can run.

If you actually want to ditch your relational database, take a look at things
like KiokuDB, Elephant, AllegroCache, and so on. They may not have exciting
web 2.0 screencasts, but the technology is much better. (I am biased towards
KiokuDB, since I helped write it, but it has been very easy to use KiokuDB
instead of a relational database; there has been significantly less code in
our apps, tests have been much easier to write, and I don't think we've lost
any runtime speed either. I really need to write a long blog post about this,
but I haven't had time.)

It is good that the world is gradually working their way up to object/graph
databases, though. Last week it was "OMG KEY VALUE STORES SOLVE EVERY
PROBLEM", this week it is "DOCUMENT DATABASES WILL RULE THE WORLD", so
hopefully the blogosphere is only a few weeks away from enlightenment ;)

~~~
moe
Well, just to state the obvious, no particular database will "rule the world".

They are different tools for different tasks.

RDMBS will not go away in data warehousing for a while. Key/Value stores are
useful for many webapps where they match the access pattern. Graph DBs have
yet their own area of application.

There is not "one tool to rule them all". Albeit it would be an interesting
project to wrap up all those engines under a common API (SQL?) and have the
server choose the optimal one either on user demand or even by magically
analyzing the workload.

I'm saying that because the real uglyness that many of us are facing is that
we need not one but several of the aforementioned tools for our particular
app. For parts of the data we like the guarantees and integrity of RDMBS, for
other parts we need the scalability of a key/value store.

~~~
jrockway
_Well, just to state the obvious, no particular database will "rule the
world"._

I don't think this either, I was just parodying the overly-editorialized
title.

------
mattlanger
With high expectations I clicked a heading entitled "Document based DBs will
rule the world" but found someone lifecasting "hello world" on CouchDB.

~~~
dasil003
Total clickbait title. To be fair, the article doesn't make this claim
anywhere. Flagged with extreme prejudice.

------
mattmcknight
I have run into serious issues with the document based approach. Imagine a
domain where you have several different types of documents. You still end up
doing joins. In the example the author gives, doing a query to get you all of
the unique tags can be slow. Or, if they are dates, trying to get a max(date)
can be tricky. The biggest problem though, is document size. For a complex
domain, there are big tradeoffs between keeping the entire graph in the
document, which is slow to read, or creating a variety of document types,
which brings you back to joining.

A hybrid approach can give you a little of both. For most of the kind of
applications I build, I use relational databases, but I dump a denormalized
view of the data into Lucene for searching and such and use a caching layer
for most reads. This way I get some document type performance on many
operations, but still have the normalization and simple transactions of a
relational model.

------
noss
A document based DB is not like a flat file. They do index for fast retrieval.

It is just that the indexes are added based on what queries are made. You can
be explicit about what indexes you want maintaned, but it is often good-enough
to just perform a query and have the db figure out how to index to make that
query faster.

It's pretty much dynamic-typing vs static-typing for databases (plus the
document-entries instead of row-column-entries).

------
Tichy
Hm, flat files will rule the world? No more messy SQL, just iterate over the
file's entries with a for loop - even Java programmers can understand that.

Sorry, but I am not convinced yet.

~~~
intinig
Tichy, give it a spin. The ease of execution (and the sheer speed, even over
giant amounts of data) is impressive.

~~~
dagheti
What do you mean by impressive "ease of execution"?

How terse the code is? How easy the code is to read? How likely the code is to
be correct? How flexible the data model is to new requirements? How simply you
can reason about what the code does?

~~~
intinig
The code is easy to read, and the data model is as flexible as you want it to
be, since it's schemaless.

Reasoning about what the code does is simple once you shift your paradigm to
document from relational.

~~~
old-gregg
Do your research. "document-based" DBs already "ruled the world" right until
relational databases were invented, which quickly obsoleted them.

The only advantage of disk-backed hash table is ease of scalability, this is
why they're useful for hm.... top 0.005% of web sites, who handle thousands of
updates per second.

~~~
jshen
They are also useful for rapid app development or prototyping. I've used
couchdb this way a few times and it works great.

------
leej
We need basic guides for the graph/document database engines like this code in
sql is translated as that code.

------
mapteo
I work only with relational db...but this is a great tech!

