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

In my last article I tried to explain NoSQL Do’s and Don’ts. Now it’s time to summarize the criteria that would represent an endorsement for either NoSQL or relational databases. And these criteria are going to break down into a few different areas like financial, issues of demand or load on the system, and the type of work, the workload that the system needs to take on.

Now, on the financial side we’re going to have some fairly novel conclusions here. The Economics of open source software themselves create a strong endorsement for NoSQL. But, there are open-source relational databases of course like MySQL and PostgreSQL. But much of the work that goes on in the relational world is still the territory of the commercial packages for Microsoft, Oracle, IBM, etc. If you think little bit more about open source software you will find, of course it’s not free at all. There are lot of hidden costs around resources and the operation of the databases which we keep ignoring initially. But your costs be likely to increase with your workforce and do not forget to count on the maintenance cost J. Whereas with relational databases that are acquired under commercial licenses, your cost will be likely to increase with your customer base.

Another asset of the financial discussion, which is motivating and impressing venture capitalists in the startup world where NoSQL databases are somewhere between hot and just almost assumed. This means if any startups is trying to look for funding, they have more success if their architecture is based on a NoSQL database rather than a relational one. The relational one to a venture capitalist may seem old-fashioned, and for whatever reason, it may not pass certain tests. If any startup is not in that demand, then it may be kind of bankrupt in terms of your integrity to use NoSQL just to attract a venture capitalists, and most likely the smart VC’s would probably recognize that.

On the demand side if we’re in an enterprise application or if we’re building some kind of business-to-business connection, some kind of software that does data integration on a business-to-business basis, most likely relational is going to work well there. And then finally, if guaranteed consistency is important and if the diversity of the reporting and the query that you’re going to be doing is wide, well then relational is really what you need; because in a NoSQL world where in effect you have to write a different program for every query.

What we are going to do in this module is juxtapose a bunch of things against what we did in the previous module, where we looked at various places where NoSQL is a killer app. But just because NoSQL Databases work well in specific situations ought not lead you to the idea that relational databases are in some way obsolete or no longer applicable. The reality is that there’s still very broad and common situations where relational databases are indispensable. So it’s important that we kind of reconnect with that reality and understand the NoSQL applicability in the context.

Let’s look at about five different qualities or scenarios where we will compare NoSQL and RDBMS. All of these really will underscore why relational is so important.

• Atomic Transactions
• Formal Schema
• Line of Business Applications
• Declarative Query
• Banded Reporting

Atomic Transactions required in general business systems. And what an atomic transactions means in a simplified kind of explanation is that it’s a system capable of grouping multiple individual changes to database into a single indivisible step so that if any part of these operations succeeds than they all must succeed and if any one of them fails then they all must fail and we are not allowed to be a part of it. That would leave the database in an inconsistent, invalid state. Whereas Transaction handling in NoSQL is challenging and NoSQL solutions have lighter weight transactional semantics than relational databases, but still have facilities for atomic operations at some level.

Formal Schema quality of relational database as it is so important. Any regular business process absolutely relies on the idea of a formal schema because process is based on the idea that, there are specific pieces of information which must always be there and the structure of this information must be must be predictable and repeatable. If we can’t have the formal schema then process may not work. Whereas NoSQL databases are frequently called “schemaless,” because they don’t have the formal schema associated as relational databases. NoSQL databases do not supports and relationships, joins. On the top of that, the things that NoSQL databases accommodate and end up facilitating aren’t especially necessary in these business process scenarios.

Line of Business Applications end up being rooted in the idea of a consistent schema, because if you think about the screens in a line of business application, and you realize that there are fields on the screen and those fields end up being data-bound to particular fields in the database, that’s sort of implicitly based on the notion of a declared schema. You can’t declare the screen design, unless you can also declare the schema. Taking this even further, the whole notion of object-relational mapping is based on the idea that even before the application’s written, you create a mapping between the database and the object-oriented pieces of code in your application. If the schema’s not there, then you can’t map it. It’s just as simple as that.

Declarative Query is one of the important capabilities of a relational database. Relational databases are very good at sort of understanding what the schema of their databases are and then analyzing a query and building an optimized execution plan, so it can be satisfied very quickly. As there is no formal schema in NoSQL, crucial Ad Hoc queries in application or reporting become very difficult. Not only that, but we lose out on query optimization, versatility of the engine to really adapt to any kind of query. So, all of the advantages that accumulate to declarative query, stored procedures, versus crucial queries written for NoSQL in a MapReduce fashion or any other method.

Banded Reporting is the way most operational reporting works. we have a detail section that is repeated for every single row in the data that we are reporting on. And all the sections in the report itself is based on a layout. The layout is based on knowing what the schema is in advance and specifying which piece of data goes where. And then the grouping sections around those detail sections work the same way. Now, how are you going to design the report, in terms of which data is in which position if you don’t know what all of that data is? You end up being left in a NoSQL situation. But there are couple of open source reporting tools which supports NoSQL Databases with additional drivers but again there is no declarative queries for these reports so you end up using MapReduce and other frameworks.

So, relational databases aren’t going out of style. They’re not merely usable. They are absolutely crucial and necessary to a whole range of software and data-processing scenarios.

Hope this reading helps you to understand the difference between NoSQL and Relational database.

Sandip