Every type of database, all the times, had some shortcomings and incompetency, which paved the way to the rise and growth of newer databases to cater to the changing needs of the information technology industry. As experts point out, the latest NoSQL databases, too, have the same.
As we can see, the buzzword ‘NoSQL’ has been echoing louder for many years now, and this excitement is more about it offering the fastest and top-performing data stores. This is something groundbreaking to the modern-day organizations dealing with big data, but as the honeymoon of NoSQL comes to an end, it is now time to balance the excitement with some of the grim reality facts about the same.
This article is not meant to devalue any of the most innovative NoSQL databases as they continue to serve their purpose to the maximum. All these are also getting more and more streamlined to be more simple and effective mechanisms for data storage. We can find truly deep value in MariaDB, MongoDB, Cassandra, CouchDB, Riak, and similar NoSQL standouts now on the frontline.
However, as we start to feel lately, NoSQL systems are still far from being a perfect fit for the big data ecosystem and sometimes rub the wrong way. The smartest among the seasoned developers came to know about the same from the very beginning itself. With this in mind, they never burnt the erstwhile SQL manuals and did not cut off their devoted SQL vendors. Here, we are attempting to address the gripes, which will help you to set things better with a fairer understanding of the trade-offs too of NoSQL.
Hard truths about NoSQL
-
JOINs equate to more consistency
One prominent gripe people seem to have about the SQL database systems is the cost of computation in executing a JOIN between two distinct tables. The idea here is to store data in only one place and fetch it from there when needed. If there is a list of customers, then you put all their street addresses in a single table and then use customer IDs in all the other tables. While pulling the data, the JOIN acts to establish a connection between the IDs with the street addresses, and things remain consistent.
So, the evident trouble is that the JOINs may be much expensive, and some of the DBAs may put forth very complex JOIN commands too, which can turn even the fastest hardware to something sludgy. With this, there is no surprise that even the NoSQL developers also boasted of a lack of JOINs in the features list. This is like keeping the customer street addresses in the same table with everything else with the above example. In NoSQL, the approach is to store the key-value pairs for each entry, i.e., each customer. When needed, it is retrieved altogether.
Those people who want their database tables consistent do need JOINs, however. Once if you start to store the customer addresses with all other information about the same, finally, there may be many copies of the addresses in each of the tables. When there are many copies, you may also have to update those simultaneously. As RemoteDBA.com points out, this may work well sometimes, but it goes wrong, NoSQL may not help you with the transactions.
-
Handling tricky transactions
Another trouble spotted by experts is that NoSQL may make it so hard to keep different entries consistently. There are no such often transactions happening between tables to ensure that the changes to many tables are made together. For this, you are left by your won, and any crash in between may easily make the tables inconsistent.
As of late, some of the NoSQL implementations do offer a different approach to a transaction. For example, Oracle’s NoSQL product puts forth a transactional control over the data written on to one node and will let you choose any degree of consistency across different nodes. If you want to attain a foolproof consistency, you may have to wait for each of the writes to reach all available nodes. Many other similar NoSQL data stores may also be experimenting with adding more protection and structure to this framework.
-
Databases can be smarter
Another thing many of the NoSQL programmers boasting of is how the lightweight codes tend to work so quickly. This is generally true when tasks are basics, but this scenario changes as the problems they deal with get harder.
Let us consider the age-old challenge of JOIN. When NoSQL programmers start to generate JOIN commands based on their logic, they tend to do this more. The SQL developers may have spent many decades to develop the most sophisticated engines for handling the JOIN commands efficiently. Even for the baseline requirements, the SQL programmers tend to spend many days pulling out their hair to structure the SQL queries to take advantage of the latest intelligence. This may not be so simple, but as the programmer can figure it outrightly, the databases they work can sing lullabies.
As we know, a very sophisticated and hard-coded query language as SQL may always have the potential to outperform on comparing it with unsophisticated query languages, as seen on the NoSQL. This is not just a matter of simple results, but even when the querying actions become more complicated, SQL is executed rightly on the machine next to data. Even though it implies a little overhead in fetching the data while doing its works, a NoSQL server may usually ship it to where it is heading.
-
A lot of access models
SQL is more of a standard language in theory. Using SQL for a single database, you may be able to run the same query for the same purpose on a different compliant version. This claim may work well with a few basic questions, but the DBAs may know that it may take many years for you to learn the actual SQL idiosyncrasies on handling different versions of the same SQL database.
We see all these in the NoSQL world now as many of the projects running on the same start to add back things like schemas, transactions, and modern standards. NoSQL is still in its infancy and progressing, and we try to tear things down on to build them back strong. We can say that NoSQL had finished its initial phase of the revolution, and now the second phase is beginning by giving us more hopes.
