Denny's SQL Secrets
Relational Database Engine: Doomed in a NoSQL World?
- By Denny Cherry
Ever since NoSQL burst onto the mainstream database world in the late 1990s there have been a group of people who have been saying that NoSQL is going to kill off the relational database engine. This general statement has been made for various reasons including:
- NoSQL scales out easier than a relational engine.
- Developers can work easier and faster in a NoSQL platform.
- NoSQL databases are designed to do one thing really well, so you just need to use the right NoSQL engine.
While all of these things are true, not a single one of them, nor all of them combined, spells the death of the relational database engine. The relational engines do some very important things which some NoSQL database engines don't do -- a lot of which revolves around the principal of ACID that we have in the relational database world. ACID within the context of a relational database stands for atomicity, consistency, isolation and durability. While many NoSQL platforms handle some of these properties many systems require that all four properties are properly accounted for.
A fantastic example of this can be found in the failure of two Bitcoin exchanges in early 2014. Let's start by looking at the Flexcoin failure in March 2014. Flexcoin as a Bitcoin exchange failed directly because of the lack of consistency within the NoSQL platform which they chose to build their exchange on. In the words of the exchange, "The attacker successfully exploited a flaw in the code which allows transfers between Flexcoin users. By sending thousands of simultaneous requests, the attacker was able to 'move' coins from one user account to another until the sending account was overdrawn, before balances were updated."
This was able to happen because the database didn't support consistency in the same way that the large relational database engines (Microsoft SQL Server, Oracle, IBM DB2, Sybase, Informix, etc.) do. This allowed attackers to effectively overdraw a Bitcoin account to the tune of 896 Bitcoins which at the time was worth about $500,000. What makes this worse is that a second Bitcoin exchange, named Poloniex, ran into the exact same problem right around the same time losing more money to thieves.
Now to be fair to the NoSQL database platforms out there this problem came up because the companies in question used old first-generation NoSQL database software which was known to not support concurrency. In other words, the people that built these Bitcoin exchanges never should have selected the database version that they did.
The various NoSQL platforms which are available are tools which solve a specific need, just like the relational database engine. If I need a database where I can run an OLTP workload, have data integrity and run summary reports quickly and easily, a relational database is the way to go. If I need somewhere to store large documents then a NoSQL platform is going to be a better option. If I'm looking for a platform with a ridged schema for the data, where indexes are specifically created as needed, then the relational database engine is where I'm going to be looking. If I'm looking for a non-schema platform for an application that is close to or 100 percent singleton operations, then a NoSQL platform is the way to go.
Just like any tool there is a right way and a wrong way to use both the relational database engine and the various NoSQL engines which are available. And there are plenty of examples on the Internet of people using the wrong tool for the job and the project failing miserably.
So is the relational database management system going to go away? Probably not. And if it is, it isn't because of NoSQL database.
About the Author
Denny Cherry is the owner and principal consultant for Denny Cherry & Associates Consulting and has over a decade of experience working with platforms such as Microsoft SQL Server, Hyper-V, vSphere and Enterprise Storage solutions. Denny's areas of technical expertise include system architecture, performance tuning, security, replication and troubleshooting. Denny currently holds several of the Microsoft Certifications related to SQL Server for versions 2000 through 2008 including the Microsoft Certified Master as well as being a Microsoft MVP for several years. Denny has written several books and dozens of technical articles on SQL Server management and how SQL Server integrates with various other technologies.