{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

NoSQL has been one of the biggest technology trends of the past couple of years.

The rise of 'big data' and the growing number of solutions that promise to eliminate some of the long-standing headaches relational databases often create have given many companies, particularly start-ups, good reason to NoSQL databases.

But at least some of them are finding out that NoSQL isn't the database market's version of penicillin.

Take for example online advertising start-up Kiip. A year ago, it went into production with one of the most popular NoSQL solutions, MongoDB.

"We were initially attracted to MongoDB due to the features highlighted on the website as well as word of mouth from those who had used it successfully. MongoDB delivered on some of its promises, and our early experiences were positive," the company writes on its engineering blog.

But the honeymoon didn't last. "Underlying architectural issues" that reared their ugly heads as Kiip grew began to "limit the practical usage (it was) able to achieve with MongoDB."

By the time the company needed to scale its data horizontally, something it felt it was being forced to do prematurely because of MongoDB's poor performance, its confidence in the NoSQL database was so hurt that it opted to scale by ditching the product.

For key-value data, Kiip opted to move to Riak, another NoSQL solution. For data that needs to be queried in more sophisticated ways and that fits within a relational data model, it then turned to a relational database, PostgreSQL.

PostgreSQL, of course, is an old man as far as databases go - and it's not nearly as sexy as today's breed of NoSQL solutions. But PostgreSQL is if one thing a proven solution for storing relational data. That, of course, is what matters.

While there's still reason to believe that NoSQL databases like MongoDB have a place in this world and will continue to grow in usage, there can also be little doubt that many organisations will learn the same lesson Kiip did: new and promising but not-battle-tested doesn't always beat established, boring and battle-tested when it comes to database technologies.

Yes, relational databases have their limits, but those limits are generally known and understood; NoSQL databases, on the other hand, are home to many unknown unknows.

One important observation that often gets lost in the NoSQL hype is that there's arguably just as much innovation in the relational database world as there is in the NoSQL world.

PostgreSQL, which was once considered an industrial grade but generally 'slower' alternative to MySQL, has made significant performance strides in the past several years. And thanks to companies like Percona, MySQL's performance and clustering capabilities are rapidly improving as well.

Given these things, if there's one thing that organisations should keep in mind when comparing relational databases to their NoSQL cousins, it's this: don't assume that relational databases aren't evolving and becoming more capable just because they've already been around the block. That assumption is wrong and it can easily lead companies to adopt technologies that will limit what they can do going forward.

If Kiip's experience is any indication, expect to see more and more companies realize this, blunting some of the insane growth NoSQL has seen in the past several years.

Patricio Robles

Published 16 April, 2012 by Patricio Robles

Patricio Robles is a tech reporter at Econsultancy. Follow him on Twitter.

2402 more posts from this author

Comments (6)

Comment
No-profile-pic
Save or Cancel
Avatar-blank-50x50

mark heseltine

I don't understand the title of this story vs its content.

"For key-value data, Kiip opted to move to Riak, another NoSQL solution."

so they have stuck with a NoSQL approach for key-value data.

over 4 years ago

Avatar-blank-50x50

Rowland Gosling

The conclusion is just about what I have imagined would happen if you took any good sized OLTP database and put it into NoSQL. Since NoSQL doesn't pretend to be an OLTP solution why would someone do this?

over 4 years ago

Avatar-blank-50x50

Jed Marang

I don't really understand the goal of this article. The story reads more of a fundamental lack of understanding with regards to the companies data usage model.

Migrating from document storage to RDB and from key,value to RDB as well, dependant on usage strategies provides no comparable metrics whatsoever

Surely the resounding sentiment of this story is to understand your data consumption and manipulation requirements and develop agnostically to any external technological dependancies, as has been best practice for the last 15+ years

over 4 years ago

Avatar-blank-50x50

Pete Cheyne

Yeah i think (or at least i hope) this article has been written in such a way to spark debate.

As the previous commenters have mentioned, you need to be using the right tool for the job. When Klip were starting out, im sure their engineers thought a fast, schemaless document store was the holy grail for a start up who weren't sure about what their own data would look like in a few years. Anyone that's attempted relational DB schema changes on read/write heavy tables in a production environment knows how difficult and how painful this is.

Jed hits the nail on the head, why not develop agnostically so that you have the flexibility to change in the future - in a few years they may bring out a new DB technology so fast, that we see Klip moving away from Postgres, then we'll see articles about the death of SQL!

over 4 years ago

Patricio Robles

Patricio Robles, Tech Reporter at Econsultancy

Jed,

"The story reads more of a fundamental lack of understanding with regards to the companies data usage model."

You could certainly look at it this way, and I think that's part of the point: many companies don't give enough thought to the structure of their data. As a result, they make bad assumptions that lead them to select NoSQL solutions that really aren't a good fit.

"...develop agnostically to any external technological dependancies..."

This is far easier said than done, and I haven't encountered a single organization that can pull it off.

Take RDBMSes: database abstraction layers promise the type of agnostic development you speak of, but they're of questionable in practice. Usually they limit the features of a particular RDMBS you can access, and there are a whole host of other issues, like less-than-optimal performance.

If you know of an organization that has no external technological dependencies, please let me know!

Pete,

Relational databases can be a nightmare, but as I pointed out in this post, almost every challenge you can face with a relational database has been dealt with by someone. That doesn't mean the challenges aren't painful, but I'd argue it's probably going to be better for most organizations to deal with challenges that others have solved than to pick some NoSQL solution that you're a guinea pig for.

over 4 years ago

Avatar-blank-50x50

Jed Marang

Hi Patricio

Great points with regards to abstraction layers, i'd argue though that the inference of not "limiting features" is that you bind yourself to vendor specific functionality - this is dangerous practice and should only be undertaken at a mature point in any project. Doing so early on in any development is, IMO, a critical error in judgement.

"...almost every challenge you can face with a relational database has been dealt with by someone"

I would agree, many of the fundamental issues (particularly related to scalability) are very well understood, and have been for some time now - I would argue that it is these very same fundamental issues that has given rise to many of the very same NoSQL implementations that we are discussing. A prime example, with regards to the above, is that of horizontal sharding within MySQL vs MongoDB, the ease of redundant replica set implementations in Mongo Vs MySQL etc

"..As a result, they make bad assumptions that lead them to select NoSQL solutions that really aren't a good fit."

Lastly on this I agree 100% with that fact that many companies make bad assumptions with regards to their data, I would argue there though that the bad assumption would be following the same (limited) path that has been tried, tested and found to be very lacking with traditional RDBMS's. You dont need to look very far to find the pattern of companies experimenting and relying increasingly on NoSQL solutions Amazon, Facebook, Google, Twitter, LinkedIn to see that true scalability simply doesn't exist, practically and economically, within RDBMS's

over 4 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.