NoSQL - Do I Really Need It?

From time to time, Something New appears on the horizon. Sometimes it's been designed by a committee, sometimes by a group of astronaut architects. Sometimes I reject it by default, if it just makes me stupid, like EJB for example. But sometimes I come across something different, something that makes me think differently. Git, for example, totally changed my outlook on version control. I like paradigm shifts, especially when they make my life easier.

NoSQL is a good candidate for a Git-like "Wow!!" experience. It's light, it's sexy. It's becoming more and more popular. There are a lot of implementations even though it hasn't matured yet. Query language standarization is in progress. Big companies like Facebook and Yahoo are using it. In other words, NoSQL is as hot as the summer weather today here in Warsaw

Why is NoSQL so hot? What's missing from my traditional RDBMS? How might NoSQL change the projects I'm working on right now? The root question is: "Is it really worth taking the leap to NoSQL?"

NoSQL came out during the Web 2.0 era. Web applications had changed, they had become more and more about persistent storage for thought streams and less about business entities. Posts on blogs, comments, holiday pictures, user profiles, all had a simple document-like model in a database. Documents are sets of properties, names. Each document is stored with a key or id. People like to share what's on their mind, so volumes grow rapidly. Storage becomes a real problem. It becomes expensive and extensive. Terabytes of human thoughts stored on highly transactional, ACID-driven databases designed to store financial data.

The solution was simple. Let's get rid of schemas, transactions, and ACID bondage. Yeah! ACIDis so 70s . So let's make it simple, like a persistent hash map, let's make it distributable, to avoid pernicious hardware solutions. So they made it. NoSQL solutions delivered to the people.

NoSQL is awesome. But I'm still not using it.

Why not? Every appliction I'm working on has at least one part which would be a good cadidate to implement on a NoSQL database. Like content management modules, products descriptions, news, and so on. But business applications have to satify the needs of all their departments.

CMS and product description modules are used by marketing/PR departments. These guys are known to change their minds often, I mean very often. A schema-less approach could be helpful to them, because storing yet another "only-marketing-guys-understand-it" field can be done without any DBA activity.

But what about other departments? Especially the financial guys? Can they handle non-atomic updates performed on their "money-like" columns? I don't think so. They love ACID even if they don't understand it. RDBMSs were developed for them.

Now you're facing the problem of how to store two totally different kinds of data: loosely coupled documents, and strictly-related business entities. Your choices are:

• NoSQL (Downside: not at all easy to implement strong enough reliability to handle finances)

• RDBMS (Downside: storing content in tables looks awkward sometimes)

• NoSQL for documents and RDBMS for money (Which one will serve as master?)

Sadly, when you look at the downsides, RDBMS is still the winner. Elegance is not as important as reliability when money is on the table. The old way still works for enterprise-level applications. You may call me a dinosaur defending my Java + RDBMS solutions, but that pair is still the unbeatable standard.

Now I'm going to wander off and dream about orthogonal persistency on a hardware-based Lisp machine.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/301743/viewspace-738656/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/301743/viewspace-738656/