The web is literally built on databases. The majority of your favorite websites are probably driven by one or more relational databases.
But there's a "movement" afoot. Its goal: provide a superior alternative to popular RDBMSs like MySQL and Microsoft SQL Server.
Dubbed "The NoSQL Movement" by Dave Kellogg, the CEO of Mark Logic Corporation, a growing number of developers are turning away from traditional RDBMSs and turning to alternatives with names like Hadoop and Cassandra.
In a post on the subject the other day, Kellogg details what's driving the movement. Big factors: performance, scalability and costs. For super-popular consumer-facing web services like Facebook and Twitter, using RDBMSs is not only costly, it becomes technologically challenging.
The growing prominence and popularity of 'NoSQL' alternatives, which can sometimes provide for greater performance, especially with large volumes of data, is a good thing. RDBMSs certainly have their limits, and it's nice to see innovation delivering new solutions. But as Kellogg notes, there's also a lot of hype around NoSQL. That's not necessarily a good thing.
Inevitably, more and more businesses will see popular services like Facebook and Twitter moving over to NoSQL alternatives and they'll wonder what it's all about. Some will even go so far as to adopt NoSQL solutions without doing a cost-benefit analysis. Case in point: I recently read an RFP for a development project that required the use of Cassandra for some data storage. In my opinion, there was absolutely no need for it, outside of the fact that the client thought Cassandra was cool and assumed that its service would become really, really popular some day.
In my opinion, businesses should be careful when considering NoSQL solutions. Not only will the vast majority of web-based applications never reach the scale at which these become attractive, the relative immaturity of most NoSQL solutions means that there's a much smaller pool of competent developers who have expertise with them. Obviously, if you're running a service like Facebook or Twitter, that's not an issue, and the cost savings from moving to these solutions makes them worthwhile. But for smaller companies and entrepreneurs, the maturity of RDBMSs like MySQL means that it's far easier (and less costly) to find experienced developers to build and maintain applications that run on them.
Will there come a day when RDBMSs share the spotlight with alternative solutions? It's quite likely. But the RDBMS (and SQL) aren't going anywhere anytime soon.
Photo credit: pvera via Flickr.
Reader comments (7)
7:11PM on 26th February 2010
You make a good argument, but you're overlooking another fairly significant feature that many of the 'NoSQL' solutions provide, and that is schema-less storage.
Long before they have issues with scale, many websites will reach a level of complexity where they're trying to bend SQL into support increasingly generic data structures. The problem with this is that this process also requires the addition of new tables with increasing use of computationally-expensive joins.
There are two particular scenarios where I feel a 'document database' is more suitable than SQL, 'product' catalogues and logging. The reason is that these two functions generally reach the point of adding expensive tables or ugly columns fairly quickly as a site grows. With logging especially, you often want to store data before you have really thought out how you plan to use it, so you don't want to invest time in working out the best relational database structure for the task. And product catalogues? You will often be filtering, faceting and sorting on such a range of fields that it's just easier to use a structured document database rather than worry how to do it with a relational database.
6:50AM on 28th February 2010
I think the performance issue can't be understated. when you reach the volume that facebook, twitter and others have you just can't effectively do that with MySQL. Social networking sites are perfect candidates for NoSQL solutions because of the asynchrnous replication and, as andrew has pointed out, the document structure just fits better.
8:08AM on 28th February 2010
www.dentistsurgery.com
Looking up for the information for a paper on teeth diseases I came across dentistsurgery.com site. The information presented there is indispensable: 5 main teeth diseases described in each detail with pictures and advice how to prevent them! My paper was the best one in my group!
Activation Director at MEC Global
10:15PM on 1st March 2010
Interesting.
Creative Director at Foliovision
11:37PM on 1st March 2010
Thanks for bringing this issue up Patricio. MySQL is great as long as you are still on a single dedicated server or even a small cluster. Unless your site goes beyond that, there's no need to reinvent the wheel. But boys with toys...
Tech Reporter at Econsultancy
5:18AM on 2nd March 2010
Andrew,
You make a good point about schema-less storage, but I also think we shouldn't forget that a lot of the issues that come up with relational databases are the result of poor planning and design.
In my personal experience, there are a lot of developers who know how to build database-driven apps, but they're not experts on database design and that creates a lot of problems that could otherwise be avoided.
Alec,
Couldn't agree more.
2:43PM on 2nd March 2010
We use both. NoSQL is great for looking through a lot of reasonably static information very, very quickly (which is why all search engines have been doing this for donkeys years) and anything with scale needs to do this. They're not so hot for transactional databases where data flows both ways (customer databases etc etc) and is frequently updated. Horses for courses.
Log in to post a comment