Big Data, Data Analytics and Data Science | BI-BIGDATA.com

In this article I’ll be explaining about Do’s and Don’ts about NoSQL. Essentially I will be talking about the set of circumstances, the scenarios where NoSQL Database makes the most sense and the scenarios where it really doesn’t make a lot of sense and where relational databases would in fact be more appropriate. By sketching out the different scenarios for the different types of databases, you’ll then be in a good position to understand, based on whether your requirement is exposed to one set of scenarios, the other set or both, whether NoSQL databases are appropriate for your organization and for your requirements.

Let’s begin with performance, and if remember about the cap theorem which I explained in my article “NoSQL Categories Breakdown” couple of weeks back, where it turned out that NoSQL databases have enhanced availability over relational databases but at the cost of moderated database consistency. That would sort of imply that NoSQL databases always perform better. The reality is they do perform better but in very specific kind of web scale scenarios where the load on the system is huge, and the necessity of what must be retrieved and saved is actually rather straightforward and simple. In those situations NoSQL databases work well, and will perform faster than a lot of relational databases.

But in other context where we don’t have that kind of load, NoSQL databases may actually be slower, quite a bit slower in fact. So, in general for a line of business application loads you’re going to want to use relational databases. They’ll be just as fast and probably faster, plus because of the consistency guarantees they’ll be much more reliable, and for a business application that may be something that’s not a luxury but rather a necessity. On the other hand, in those cases where you have the simple storage and retrieval, but you have to do an awful lot of it, then NoSQL may be best.

Suitability, which really translates into the idea of having examples of where one or the other works well. Think about just the example of storing and retrieving configuration data, personalization data, environmental data for the way an application have to come up and look and be skinned and be branded, all kinds of settings data, the kinds of things that would probably get stored in a flat file if it were just a desktop application that needed to save and retrieve them. These are the kinds of things that tend to work pretty well for a NoSQL database. Also, log data or any event-driven data, although you will very often find relational databases used for those kinds of workloads, NoSQL databases in many cases will be a more appropriate choice.

On the other hand, if you think about anything really that’s transactional, especially financial transactional applications, anything to do with stock trades, accounting, credit card transactions, these are things for which using a NoSQL database would really be a bit obtuse. You can probably use relational for anything, and you can probably use NoSQL for anything. There’s a law of computation that basically says any problem can be computed in any language, and by extension, that likely means any data requirement can probably be satisfied by any database. But it wouldn’t be satisfied especially well. So, realize that while there is overlap, there are gray areas.

For the most part, things are rather mutually exclusive as to where each of these types of databases works well. And one sure way to come up with a bad decision is to try and come up with an endorsement for one or the other in every single case. That will almost always get you in trouble.

The real question is whether the scenarios where relational works best are ones that you see in your business, or whether the scenarios for NoSQL are the ones that you see in your business, or whether you see a mix. If you only see one set of scenarios, then yes, it will appear that one database type is always the answer. But that’s because the questions that you’re asking are in effect limited.

In my next article I’ll explain the difference between NoSQL and RDBMS.

Stay tuned.

Sandip