It's hard to be a relational database lately. After years of faithful service everywhere you look the world is turning against you:
Recently at the NoSQL conference 150 revolutionaries met with their new anti-RDBMS arms suppliers. And you know what happens when revolutionaries are motivated, educated, funded, and well armed.
The revolution has gone mainstream when Computerworld writes No to SQL? Anti-database movement gains steam. It's not just whispers anymore, it's everywhere.
And perennial revolutionary Michael Stonebraker runs from blog to blog shouting the The End of a DBMS Era (Might be Upon Us). Relational vendors are selling legacy software, are 50x slower than other alternatives, and that can not stand.
The Greek Chorus on Hacker News sings of anger and lies.
Certainly some say stick with the past. It's your fault, you aren't doing it right, give us another chance and all will be as it ever was. Some smirk saying this is nothing but a return to a more ancient time when IBM was King.
But it's in the air. It's in the code. A revolution is coming. To what? That is what is not yet clear.
See also:
NoSQL? by Curt Monash.
CouchDB says BigTable clones are too complex.
Yahoo! Developer Network Blog. Very nice summary of the different talks.
Thursday, July 2, 2009 at 3:28AM
Reader Comments (8)
I wrote a fairly detailed post about the Death of the Swiss-Army RDBMS this on my blog, http://www.roadtofailure.com :)
I think we're basically going to see a segmentation in the market, as people tailor their data storage to their data structure and analysis needs -- which is The Way It Should Be. The age where you can just buy an RDBMS and use it for almost *anything* related to data is over.
I wrote about this in August 2007. I hadn't thought about that article in quite a while. The thing is, I've been TRYING to get developers to give up RDBMS habits for years now with very little success. It's very, very difficult to get people to go against what they already know and perceive to be "easy" and a problem for "later."
The summary of the article I posted way way back said, "you should be paying attention to your code quality, optimization. You should break out of a one-size-fits-all way of thinking when it comes to databases, data storage, and scalable systems. Vertical scaling by throwing hardware at it is no longer sufficient for modern web scale applications. There are built in limitations as dictated by clear and proven underlying mechanisms that prohibit current modern database and application technology from scaling much further. This is not only about money. It’s about finesse and the application of core scalability design theory from the forefront of technology. In summary, if you intend to run modern applications in truly scalable ways you must break out of the mold we’ve been in for 30+ years and think about new ways to design and build your applications."
http://www.productionscale.com/home/2007/8/11/getting-rid-of-the-relational-database.html
So, looking back now, it's even more true than ever. Lately I tend to encourage people to architect their applications in such a way that IF they do want to use a relational data store that it is essentially a back up data-store used in a "write-through" way and to keep hot data much closer in memory grids and distributed DB's of various flavors. Here is an article introducing something for Rails called Cache-Money. It's an add-on of sorts to Active Record. It's an interesting read somewhat related to all this fun stuff.
http://magicscalingsprinkles.wordpress.com/2008/12/11/introducing-cache-money/
`Cache Money` is a plugin for ActiveRecord that transparently provides write-through and read-through caching functionality using Memcached.
Anyway, these are extremely interesting times at the data layer. And, in my opinion, that even includes the file system. But, that's another conversation.
Cheers,
Kent
It must also be crap on correct spelling week. Isn't it database, not dabase?
And c'mon folks, why is everything a religious war.
Carpenters do not argue about whether hammers are better than screwdrivers!
Use a RDBMS when you need to manage relations. Use something else when you need to store objects.
And try to remember, applications meant to serve millions of hits are different than applications meant to serve a few hundred users... not to mention, someday someone will want to do data analysis on the persisted information. As long as that will be, or can be made to be, possible, do whatchalike!
Yah Anonymous I fat fingered the title. It was too late by the time I realized it, so now it's just a testament to my competence.
You should be able to change the post title without changing the URL. :)
That's probably the fault of using sql.
:P
One of the comments linked is the following -- "If the user’s data is naturally something other than tables", well most business data is naturally "tables - columns/rows" hence the use of Excell. So naturally relational RDBMS is the appropriate choice. The database will remain supreme and the market will continue to build tools and technologies on top of RDBMS. There is nothing that tells me this clean, organized, logical methodology/technology is going anywhere.
Well, i agree with Kent's comment!