
NoSQL Took Away The Relational Model And Gave Nothing Back - ArturSoler
http://highscalability.com/blog/2010/10/28/nosql-took-away-the-relational-model-and-gave-nothing-back.html
======
raganwald
I'll bite as well. Are NoSQL databases faster? Smaller? Simpler? If any of
these statements are true, then they are giving something back, although quite
possibly that trade-off is not of interest to the author.

I am reminded of another Holy War (beware! reminded-of is not a euphemism for
is-just-like): "Ruby took away the power of static typing and gave nothing
back."

~~~
bmelton
Generally, the pros and cons list should be isolated down to a given
implementation. While you can vaguely state that NoSQL data stores are fast,
and that horizontal scaling is generally easier on NoSQL, that isn't always
the case, and doesn't apply to anywhere close to every situation.

MongoDB offers some REALLY cool features that enhance development speed.
Inserting into a table that doesn't exist? It creates the table on the fly.
Querying from a table that doesn't exist just returns an empty result set
(instead of an error, or exception).

If I had to speak in specifics though, I think it's pretty easy to say that
NoSQL stores allow for querying very large datasets faster than you could on a
relational store on similar hardware.

------
antirez
NoSQL does not mean nothing...

Redis does not use the Relational Model not because it promotes a simple key-
value model, but because it proposes a different paradigm and data model based
on fundamental data structures.

MongoDB for instance does not took away the relational model at all, in some
way. So what NoSQL are we talking about? :)

NoSQL was a good marketing idea at start, but now it's starting to be really
misleading.

~~~
silentbicycle
The term "NoSQL" has _always_ been misleading. The various "NoSQL" systems
have very different underlying models, and defining them by their lack of SQL
makes discussions about tend to develop an adversarial, "us vs. them" tone. It
adds way too much noise.

I don't care about "NoSQL" - I like Postgres and SQLite. What makes the
_individual_ "NoSQL" databases interesting, though?

Redis is in a design sweet spot, IMHO. The pure key-value stores seem way too
low-level to me, but the support for atomic operations on lists, sets, etc. in
Redis is very handy. It also works well as a cache for other databases, and
newer commands like BLPOP are very cool.

While I haven't used CouchDB much, its model is also interesting, and I can
see its trade-offs being an excellent fit for certain problems (just not
mine).

~~~
checker
Some say NoSQL = "Not Only SQL", implying that there are alternatives to
purely relational DB's. I think this definition fits better than the implied
purely unrelational DB.

~~~
silentbicycle
Agreed, but that's just damage control, after a whole bunch of "Death to
relational databases!!!" hype. Of _course_ there are alternatives to RDBMSs.
What are filesystems if not hierarchial databases?

"NoSQL" is about as useful as rallying behind "languages without camel-case"
(NoCC!).

------
steveklabnik
Flamebait title is wrong. From the article:

Update: Benjamin Black said he was the source of the quote and also said I was
wrong about what he meant, ill-informed even. His point: The meaning of the
statement was that NoSQL systems (really the various map-reduce systems) are
lacking a standard model for describing and querying and that developing one
should be a high priority task for them.

~~~
toddh
The title was a quote, so it was not wrong, what he disagreed with was the
interpretation.

~~~
steveklabnik
It's most certainly misleading.

------
sofuture
It's (still) stupid arguing that NoSQL systems are crappy at proving the
things RDBMS systems provide. (Because they are, and no one has ever said
differently, it's akin to yelling at a Bugatti Veyron (yeah, I went there) for
being so bad at flying.)

I'm not using CouchDB because I needed relationships and the RDBMS features of
SQL Server but decided at the last minute 'Ehh oh well, let's just try this
fancy NoSQL business, I'll rewrite all the RDBMS features into my code'.

Believe it or not I'm using CouchDB because I want to run map/reduce on a
bunch of JSON! Astounding, right!?

------
mjw
I see it as a high-level vs low-level thing.

The relational model is a high-level language for describing the structure of
data. And a pretty elegant one if you can look past the awkwardness of dealing
with current SQL databases (not a fault of the model itself).

That said if you want to scale and tune things you often need to drop down to
a lower-level view in order to get things done, hence NoSQL. But that's not to
say the relational model isn't still useful, or that it shouldn't inform any
formal reasoning done about data in NoSQL systems.

I have some more thoughts on this here:
[http://matthew.yumptious.com/2009/07/databases/nosql-and-
the...](http://matthew.yumptious.com/2009/07/databases/nosql-and-the-
relational-model-dont-throw-the-baby-out-with-the-bathwater/)

~~~
mjw
To the downvoter - curious what exactly you disagreed with?

~~~
raganwald
Up to you, but I'd say let that kind of thing slide. The ideal is that if
someone disagrees, they'll explain themselves. Downvoting is supposed to be a
mechanism for voting on whether a point adds to the discussion or not.

So either (a) your point did not add to the discussion, in which case further
discussion about your point just adds to the noise without contributing
signal, or (b) the person or persons downvoting disagree with you but are too
lazy to contribute to the discussion by explaining their perspective. In which
case, why worry about them?

Responses--whether positive or negative--are discussion gold. Downvotes aren't
worth the worry.

------
dagheti
The name relational model is quite unfortunate, as it leads to confusion about
what the model is (not much to do with 'relationships').

The key concepts are using sets to store data (making you think about your
data in a way where duplication of tuples and orderings don't mean anything),
and always using values instead of pointers to store your data and references.

I think that these concepts are very useful when it comes to managing data,
but they seem to get lost in the all the talk about "relationships" and "sql"
and "structured tables".

------
wgj
I know Ben Black and I can assure you he is very experienced with NoSQL data
stores. He is calling for more attention to the query interface to these
various data stores. He's specifically not saying they should be relational or
dismissing other merits of NoSQL.

------
8ren
"A relational model of data for large shared data banks"
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.1845&rep=rep1&type=pdf)

He gives criticism of the then existing databases (hierarchical and network),
then proposes the relational model and the concept of a query language (though
not an actual languages - this predates SQL).

Interestingly, one of the hierarchical databases (IMS) is still going strong:
[http://en.wikipedia.org/wiki/Information_Management_System#H...](http://en.wikipedia.org/wiki/Information_Management_System#History)

------
xpaulbettsx
I would disagree - I'd say that NoSQL is an exploration into disassembling the
component parts of a RDBMS in order to get performance gains in exchange for
losing features that aren't needed for your _particular_ engineering problem.

------
random42
I dont get the big hoopla about NoSQL.

Its a different way of doing things than traditional RDBMS (which very
successfully served us well for over 20 years). Why cant we just choose the
best tool for the job, after looking at pros and cons?

------
j_baker
"The meaning of the statement was that NoSQL systems (really the various map-
reduce systems) are lacking a standard model for describing and querying and
that developing one should be a high priority task for them."

I don't see why the relational model (or some subset thereof) won't work for
most NoSQL databases.

Key-Value store? It's essentially just a relational database where tables can
have one primary key and one other column.

Document store? Essentially just a dynamically typed relational database.

Graph database? You probably would have to add to the relational model a bit,
but Codd did write a bit about recursive queries.

------
knodi
I can't talk about all NoSQL but I can talk about CouchDB as I have worked
with it some. It gives multiple write nodes, easy replications and syncing, it
gave map reduce. I love it

------
nailer
'With NoSQL all relationships have been pushed back onto the poor programmer
to implement in code rather than the database managing it. '

OK I'll bite.

Yes. I, the poor programmer, want to implement relationships in my code,
rather than adding a secondary language to my application to manage
relationships (the database itself never 'managed this' for me, I had to do it
manually).

~~~
gaius
Welcome to MySQL in 1995. You'll be wanting to "manage" transactions next...

~~~
jbooth
Yeah, I do actually, because I want a storage system to be a storage system
and an application layer to be an application layer.

I've seen corporate code bases consisting of entirely PL/SQL before, it's a
nightmare. No thanks, from both a maintenance perspective and a performance
perspective. YMMV.

~~~
gaius
Yep, nothing says performance and reliability like doing everything in the
app.

Here's a neat trick - for every query SELECT * FROM TABLE, then filter and
sort it in the application too.

~~~
jbooth
Here's a better trick - treat a database as an indexed storage layer that's
doing the minimum of CPU work or complicated transactional conditions that
create lots of blocking and bottleneck conditions for threads on your
monolithic back end.

And then implement the app logic in some slow-ass web language that doesn't
hold a candle to your database's optimized C. What happens when your web
server can't keep up? Buy another web server. That's an easily solvable
problem. A saturated DB, on the other hand, is very hard to fix, especially if
all of your application logic is running in it and would require a rewrite to
scale.

~~~
gaius
There's an awful lot more to computing than websites.

FWIW I work on a "non-scalable" RDBMS that comfortably handles thousands of
commits/sec, tens of thousands of selects/sec and tens of terabytes of data.
All done with stored procs, one database, no need for "sharding" either. Will
it scale indefinitely? No, but neither will anything else. The limits of the
RDBMS are orders of magnitude greater than the NoSQL crowd think they are.

~~~
jbooth
SSDs?

A HDD is limited to well under a thousand reads per second, and there's
multiple reads per SQL select, so I'll assume either yes or you're leaving
something out. If the tens of thousands of reads are over a 4MB table that
stays in memory and the rest of your 10TB are infrequently accessed, congrats,
you have a single-node problem. If you actually need to deliver, say, 1,000
queries per second over a 10TB dataset? It's not happening in an RDBMS unless
you get a whole bunch of SSDs.

Also, RE: websites, of course, substitute your environment's front end if
you'd like.

~~~
ora600
Its year 2010, we've invented RAID a while back. Stripe and mirror everything
and you get decent performance without SSD.

~~~
jbooth
Ok, you're up to 3k random reads per second at the absolute peak.
Realistically more like 2k for 6x10k disks at RAID 0, and it's awfully hard to
even fit 10TB on a RAID1+0 setup. What's that, 10x2TB? Good luck with the
latencies on those 2TB disks.

Still doesn't add up to 10k select statements per second over a 10TB dataset
on a singlenode. Even without writes, that's not happening. I call BS on
grandparent post.

~~~
CrLf
That shows a lack of understanding of what kind of hardware is being used in
the real world to handle this.

With a half-decent SAN with 15k drives and 4Gbit fibrechannel connections, you
can get 1000+ IOPS without the storage system even breaking a sweat. Under
load it can easily give 10 times that.

This is something that's everywhere in the business world.

Pair this with a bunch of cores and a few GB of memory, and you can have an
RDBMS that chews through impressive amounts of data. Unless, of course, you
optimize nothing and swamp it with lame queries that do nothing that table
scans. Funny enough, the same people that are fine with doing everything in
code are the ones that can't be bothered to think more than one second about
what kind of queries they are throwing at the database.

~~~
fleitz
No kidding, it's like a battery backed write cache doesn't even exist in the
NoSQL world. I was able to easily drive 200MB/sec of random IO on 25 15K
drives.

~~~
fleitz
Btw, this was 200MB/sec of random writes. I didn't even bother with random
writes. I could have gotten the writes to be basically sequential if I had
bothered to write a COMB style UUID generator. I happen to be a fan of UUIDs
for the surrogate keys as it makes database merging so much easier.

------
philjackson
Taking away the relational model was what they gave us.

