

NoSQL Databases: What, Why and When - ahmicro
http://ontwik.com/nosql/nosql-databases-what-why-and-when-lorenzo-alberton/

======
xtacy
The slide that contrasts RDBMS and NoSQL DBs and asks "A step backwards?"
reminds me of the rebuttal of MapReduce and NoSQL stores by Mike Stonebraker
(copy of the article here: [http://craig-
henderson.blogspot.com/2009/11/dewitt-and-stone...](http://craig-
henderson.blogspot.com/2009/11/dewitt-and-stonebrakers-mapreduce-major.html))

~~~
joe_the_user
Interesting article.

The author compares map-reduce to Teradata. Serious question: could a system
on the scale of Google's various "apps" run on a Teradata database?

~~~
Retric
"Google Scale" is not really all that big of a problem as long as competent
people are involved. Google's approach is to basically accept that everything
is O(N) and simply through enough hardware at the problem that it's not an
issue. RDBMS's often let you do things as O(log N) but they risk O(N^2) or
even O(N^N) so your developers need to know what they are doing.

PS: The median developer at any large company is practically incompetent, so
it's probably a vary good trade off once you have data centers of that size.
However, for comparison Slashdot ran on 4 fairly cheap machines for a long
time.

------
crux_
Opinion: traditional databases suck and so do NoSQL ones, for the exact
opposite reasons.

A better solution would be one that gives developers fine-grained control over
"scalable and loose" vs "less-scalable and tight", rather than all-or-nothing
in either direction.

That is to say: I want full ACID on my "financial transactions" collection and
maximum scalability for my "chat messages" one -- but I want them in the same
overall system, accessed via the same API, managed via the same tools, and
with knobs that can be inexpensively modified on the running system.

~~~
nosh
I think finer grained consistency models (as well as some other options) would
be a step forward for RDBMS systems. However, that doesn't get over the fact
that the relational model is not always the best fit for your data. This is
especially true if your data is semi-structured. I work with the MongoDB/10gen
team and we have a lot of users who enjoy working with the document model, and
have seen drastic reductions in both amount of code and time-to-production
from it.

~~~
crux_
Just a vocabulary/definitions nit: Data modelling (relational, document, data-
structure, whatever) is an independent concern from consistency.

I may want ACID properties but over a document-structured store, for example,
and there's nothing contradictory in such a desire...

In fact, as a continuation of my "mix and match" consistency pipe dream; I'd
like to mix-and-match data models within the same system, too! Strongly typed
w/ integrity constraints; bag-o-data; etc...

------
quipo
Apologies for the extremely flat and boring tone of voice and the somewhat
rushed comparison of the actual products. Next time I'll do better, promise :)

Some notes to introduce the slides:
[http://www.alberton.info/nosql_databases_what_when_why_phpuk...](http://www.alberton.info/nosql_databases_what_when_why_phpuk2011.html)

------
fl0bar
I was at this conference and attended this speech, it was one of the better
presentations

------
rch
Very nice set of slides.

~~~
eitally
Even better if you watch the video to get the commentary....

~~~
jjm
+1 on that, commentary is excellent and concise. If you want a brief intro to
concepts in distributed DBs this is it. Grab that coffee and turn up the
speakers.

