The Business Case for NoSQL, NoETL and NoProblems


Last week, I wrote about the business value of NoSQL, an alternative approach to relational databases that's gaining more attention in the trade press. Essentially, what I learned is that NoSQL solutions can store and use large amounts of data, but with less overhead, work and downtime and with faster results than traditional relational databases.

Knowing my research was far from comprehensive and being something of glutton for punishment, I tweeted the link to the full post, with an open invitation to "set me straight."

Mad Greek blogger Mike Kavis, who by day works as a CTO and chief architect, and several others took me up on it, and I'm glad, because their comments really help to flesh out the business case-and caveats-to NoSQL. In fact, I learned so much, I thought it worthwhile to do this followup post.

It seems that NoSQL really shines in situations where you want speed and scalability. Kavis offered this summary of when to use NoSQL and when to use relational databases:

So for static, historical-type data, you just can't beat the speed and efficiency of NoSQL. For dynamic, data-entry-type data, relational databases are better suited. To put it simply, relational databases solved problems when data integrity is the key, NoSQL solves problems when speed and size are the key.

One reader-who signed only as Dwight (possibly Dwight Merriman?) from MongoDB-argued NoSQL can be useful with small-scale data apps, he added, because developers find it improves productivity. Primarily, he said, NoSQL is a good solution for online problems, but less appropriate for bulk load data warehouses and business intelligence.

He's not the only one noticing that NoSQL might be a good option for online data. David Linthicum, who now writes primarily about cloud solutions, says NoSQL was a huge topic at the recent Cloud Connect 2010. He explains why relational databases just aren't cutting it any more:

The issue is that 'traditional' relational databases don't provide the same models and, thus, the same performance. While this was fine in the days of databases with a few gigabytes of data, many cloud computing databases are blowing past a terabyte, and we'll see huge databases supporting cloud-based systems going forward. Relational databases for operations on large data sets are contraindicated because SQL queries tend to consume many CPU cycles and thrash the disk as they process data.

If you didn't follow that, here's the explanation my husband, the programmer, offered after reading about NoSQL, which I happened to love:

Relational databases are hitting their heads on all this data. We're reaching the uppermost limits of what they can do. NoSQL is a technical solution to a very real problem.

Of course, as reader Mark Atwood pointed out, businesses should still proceed with caution:

Just don't commit a live site to a NoSQL solution until you and your arch and ops team have spent the time to understand what you're getting into. This is all very new, so there are going to be a lot of surprises, and also a lot of pressure to use something just because it's 'new and shiney,' instead of old and understood."

Alta Plana Corp. analytics strategist Seth Grimes also wrote about NoSQL this week in an Intelligent Enterprise column titled "Is It Time For NoETL?" He could've called the piece "Everything Old is New Again," because a good part of it involves explaining how SQL beat out superior alternatives and techies have long known about its deficiencies. "I've been bemused by NoSQL," he begins, adding a bit of that IT smugness that I, in turn, find bemusing and business users love to hate.


However, I was intrigued by his suggestion that it's time for a NoETL movement.

What the heck does that mean? Basically, he's questioning whether ETL will remain relevant as we move toward semantic computing. Specifically, he's alking about "dynamic integration," or integration by mashups, semantics and metadata.

What's useful in the post is his page-two discussion of specific vendors that offer these solutions. I shared how NoSQL promises speed and scalability to large sets of data-well the value with these mashup tools is they can bring agility to business intelligence, according to Grimes.

"The thought is that mashups bring agility to BI, the possibility of integrating the data and application elements you need, when needed, without much or most of the overhead typically associated with conventional BI," he writes.


He's not advocating that you always use these approaches, mind you, or toss out your ETL tools, any more than NoSQL advocates are suggesting you throw out all your SQL databases. He suggests:

In considering NoETL, let's recognize the value of traditional ETL and of EII and use them where they fit best. Let's also understand the promise and power of semantics, and of the diversity of NoSQL-ite data representations, in seeking data integration approaches that enable truly agile BI.

I think businesses would second that. Because bottom line - NoSQL, NoETL, NoWhatHaveYou - at the end of the day, what businesses want is NoProblems. Hopefully, some of these new-again solutions will help IT achieve that.