NoSQL to Die in Train Wreck
March 30, 2010
“I Can’t Wait for NoSQL to Die” adds fuel to the SQL suck and NoSQL is stupid fire fight. I want to make clear that the addled goose paddles in his pond filled with mine run off fluids and takes no strong position on either side in the battle. When the bullets fly, the goose submerges his head and hopes no stray slug makes him oven ready.
The idea is that SQL is pretty darned good and:
The idea is that object relational databases like MySQL and PostgreSQL have lapsed their useful lifetimes, and that document-based or schemaless databases are the wave of the future. Never mind of course that MySQL was the perfect solution to everything a few years ago when Ruby on Rails was flashing in the pan. Never mind that real businesses track all of their data in SQL databases that scale just fine. (For Silicon Valley readers, Wal-Mart is a real business, Twitter is not.)
The write up points out some notable flaws in the NoSQL solutions. Here’s an example and a good one in the goose’s opinion:
So you’ve magically changed your backend from MySQL to Cassandra. Stuff will just work now, right? Well, no. Did you know that Cassandra requires a restart when you change the column family definition? Yeah, the MySQL developers actually had to think out how ALTER TABLE works, but according to Cassandra, that’s a hard problem that has very little business value. Right.
Source: http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html
Other SQL advocates to whom I have spoken have pointed out that even Google uses MySQL in its advertising system. Yes, even Google.
My view of this is that I want to start gathering these pro and con arguments. When emotions run high over a technical issue, I think there may be some interesting examples and possibly some financial information beneath the bluster.
Dr. Codd made a wonderful contribution to data management. My hunch is that with an efflorescence of non-Codd methods, perhaps some useful learnings will emerge. It takes years for an innovation to survive the tests imposed by the real world. When the shooting stops, SQL will remain a useful tool and we may have other useful tools to use to solve certain types of problems.
But the arguments and the verbal sharpshooting is a great deal of fun as long as no goose is killed. I don’t want to be dinner or paté just yet.
Stephen E Arnold, March 30, 2010
Nope. No one paid me to write about my interest in self preservation.
Comments
5 Responses to “NoSQL to Die in Train Wreck”
-
- Subscribe to Beyond Search
Feature archive
News archive
-
This is beginning to feel like one of these ‘religious’ debates that seem to occur once in a while in tech. There is a happy middle ground and then there the wingnuts. I think both technologies have their uses and their tradeoffs, once you understand those you can usually choose the right technology for the problem you are trying to deal with. There is, of course, no bright line at the intersection of these two, only a grey area.
[…] Some Slides Design Patterns for Distributed Non-Relational DatabasesView more presentations from guestdfd1ec. Scalable Databases – From Relational Databases To Polyglot PersistenceView more presentations from sbtourist. NoSQL databasesView more presentations from Harri Kauhanen. Related articles by ZemantaDigg Says Yes To NoSQL Cassandra DB, Bye To MySQL (developers.slashdot.org)Saying Yes to NoSQL; Going Steady with Cassandra (about.digg.com)Thinking About Cassandra (windley.com)How Twitter Is Moving To the Cassandra Database (developers.slashdot.org)Sponsor post: Sponsor post: NoSQL Live in Action (gigaom.com)NoSQL For The Rest Of Us (codebetter.com)NoSQL to Die in Train Wreck (arnoldit.com) […]
[…] NoSQL to Die in Train Wreck (arnoldit.com) […]
NoSQL to Die in Train Wreck…
I Can’t Wait for NoSQL to Die” adds fuel to the SQL suck and NoSQL is stupid fire fight. I want to make clear that the addled goose paddles in his pond filled with mine run off fluids and takes no strong position on either side in the battle. When the …
NoSQL is getting stronger and stronger, that’s because not after so many years the SQL servers couldn’t fix their speed issues