

NoSQL: Why it's So Damn Sticky - gsteph22
http://www.roadtofailure.com/2010/04/08/nosql-why-its-so-damn-sticky/

======
astine
_Then you’d say, “Hells yeahs, Tapirs are cuddly”._

You´d be wrong...

This essay is long and disorganized. To spare those who would other wise have
to suffer through it the trouble: It's basically a defense of the the term
'NoSQL' as a description of the collective of hash-key stores, documents dbs,
etc that have been gaining popularity of late. His claim: 'NoSQL' represents
some kind of escape from the oppressiveness of SQL and is a radical break with
accepted DB technologies.

It's posts like this that bother me most about about the NoSQL crowd. Hash-key
stores, document DBs, and other equally innovative things have been in
existence and in use for decades. Periodically, people try to promote these
technologies as replacements for RDBMs and each time, we learn that while they
have their place, so do RDBMs. NoSQL is not revolutionary; it's a practical
extension of pre-existent technologies that solves a set of problems that
current RDBMs don't address, while RDBMs still solve the set of problems that
they were meant to address.

All this revolution nonsense is just that, and that's why people are so worked
up on both sides.

~~~
jackfoxy
Thanks for the synapsis. I read too many paragraphs of this waste of time
before giving up. How does this get upvoted?

~~~
nollidge
"Synopsis" is the word you're looking for.

------
jrockway
NoSQL is sticky because people have been misusing SQL databases for things
that they are bad at for years. Now people are doing things right, and it
feels better.

All the people that show up to NoSQL articles and say, "you should always use
SQL" are the ones that happened to use relational databases for the right
tasks.

I wish there was a delay between when screws were invented and when
screwdrivers were invented so that we could have seen the NoHammer movement.
Of course you shouldn't screw in screws with a hammer. But hammers handle
nails pretty well.

~~~
gaius
Well, there is also the widespread belief that "if MySQL doesn't do it, it's
impossible for any RDBMS to". When people say "scalability" or "sharding" for
instance, this is what they're complaining about.

~~~
jbooth
Every single database sharding project I've seen has been a gigantic pile of
workarounds and insanity, even if/when people got it to function properly.

How about "if MySQL doesn't do it, then much more expensive databases might do
it poorly after a whole bunch of effort"

~~~
gaius
How about "buying native support for partitioning and hash joins is cheaper
than hacking it up in MySQL"?

I regularly work on DBs of 10s of teras with NO sharding or any of that
nonsense.

~~~
jbooth
How much does that cost? How does it compare to 40k for 10 commodity servers
at 4k each and no license fees?

------
MicahWedemeyer
I saw a NoSQL presentation where the presenter said it stood for "Not Only
SQL". Once I started reading it that way, all the emotional Us vs Them
bullshit was gone.

------
jbyers
"Error establishing a database connection"

Perfect.

~~~
Retric
Nahh perfect would have been if they hat stopped at: _Technically, any
database could support SQL as a language_

Or even added: _, but what we are really talking about is half finished
databases with limited capabilities that happen to suite a specific need. The
reality is SQL is in no way a limitation on a database design, however by
lowering the bar you can build a useful prototype which at some point might
become a database._ And then gone on to describe an actual problem with an
interesting solution.

~~~
ntoshev
They are not half finished databases (ok, _some_ of them are), they are just
databases that operate under a different set of constraints and optimize
accordingly.

------
gsteph22
I think it's interesting that this article is as much about language and
psychology than NoSQL -- but I've gotten no comments on that part :P

------
devdazed
I personally think that NoSQL isn't always the right tool for the job. Yes, it
scales. Yes, you don't need to structure your data. Yes, it is fast and
distributed and can be redundant. To that I say, it is too new, it has a steep
learning curve, there aren't any tools to abstract away the database portion.

Now SQL has ease of use, a myriad of tools such as ActiveRecord, or Hibernate,
an ANSI specification. All of which allow developers to quickly pump out a
site that will handle the needs of 98% of the businesses out there.

There is no need for a small time web store to be using a Hadoop Cluster, just
like we wouldn't expect Google to be running on a MySQL backend.

As someone who has worked in both sides of the industry, I can definitely say
that trying to integrate a NoSQL solution with a standard 3 Tier type website
would increase the cost of development 10 fold. Sure, you can get it with no
license fee, but you end up paying for it elsewhere.

Basically it boils down to NoSQL != NoPricetag

P.S> I recently wasted a week of my life trying to get HBase up and working on
a small cluster with the data from our Vertica solution. I ended up using
InfoBright and got it up and data loaded in a few hours. I am still open to
the NoSQL idea for our specific business, but why can't it be just as easy?

------
docgnome
I couldn't focus on anything else after this. "Tapirs are responsible for 78%
of the world’s economic output." Thanks a lot. I'm now going to be thinking
about tapirs all day.

~~~
gsteph22
You oughta be -- they're pulling the strings.

------
mattmcknight
It's a lot easier to get behind a no than a yes. As long as NoSQL is expressed
as a negative, it's a very big tent. Even DBAs and relational model types have
some complaints about SQL.

As soon as it turns into "we're using Project Voldemort, can you figure out
how to hook a reporting tool up to it tomorrow?", you find a lot less
consensus.

~~~
strlen
Part of "NoSQL" is right tool for the job. You use a data warehouse for
reporting which can be Hadoop+Hive/Pig or it can be a traditional OLAP
solution e.g., Oracle DWH, you use Voldemort for low-latency serving. The two
are differently problems. Even with an RDBMS, you shouldn't be using the same
instance for reporting as you do for OLTP: that's what ETL and data
warehousing are about.

I should add that HBase and Cassandra support integration with Hadoop and
Hive/Pig, but all the usual warnings about the load of reporting jobs against
a serving database apply-- one solution (with Cassandra) that I've heard is to
place a the "reporting" machines on a different network e.g., on a different
vlan in your own datacenter or in a different EC2 availability zone.

------
faceplant
I like the fact that it's thought provoking without being a blatant hit-
whoring attempt. I mean, hardly anything in there is really "controversial"...
it's more like just an interesting analysis of the branding of NoSQL and why
it affects people so much.

------
cturner
AltDB and NoSQL are stupid labels. These names put people into the perspective
of relational databases and then show them something totally different. The
consumer then has difficulty understanding the topic.

These labels bundle CouchDB into the same category as heavier-than-relational
OO databases.

A much better grouping label would be 'map cloud'.

~~~
daleharvey
I find "data stores" much easier to understand and isnt a loaded term.

~~~
cturner
That includes filesystems and RAM. And relational databases, which is
something that the phrase needs to distinguish from.

~~~
RyanMcGreal
How about _non-relational data stores_?

~~~
cturner
I thoughtfully offered response to your question here in my original comment
above, before you'd posted your comment.

------
xefyr
Tapirs accounting for 78% of the world economic output? Pikachus in a blender?
I think he's finally lost it.

~~~
jbooth
Kept you reading for the whole thing though, didn't he?

~~~
astine
Not me.

Just to clarify: I don't mean to say that I didn't read the article. I mean to
say that the tapir analogy was distracting and detracted from the article.

~~~
moron4hire
I quit too.

~~~
bittermang
Reading is hard and I hate it.

~~~
pquerna
lets go shopping!

------
wendroid
Nah, PostgreSQL is sticky, it has a Write Ahead Log !!

