NoSQL: Why it's So Damn Sticky | Hacker News Reader

NoSQL: Why it's So Damn Sticky

roadtofailure.com

50 pointsgsteph2238 comments

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.

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

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

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.

Thanks, exactly :)

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.

I read that complaint as being about cost-effectiveness rather than strictly possibility.

Yeah, it's too bad there aren't any free RDBMSs besides MySQL.

That support replication? Just for starters.

Yeah, there are, but hey, I'll make comparisons to MySQL 3 and 4 now.

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"

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.

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

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.

"Error establishing a database connection"

Perfect.

I got HackerNewsDotted. Amazing.

“Well, shit. It’s not SQL. What do I do now?”

Fantastic.

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.

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.

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

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?

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.

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

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.

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.

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.

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'.

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

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

How about non-relational data stores?

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

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

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

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.

I quit too.

Reading is hard and I hate it.

lets go shopping!

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

Reply on news.ycombinator.com