A recent series of posts by C Mohan offers a lot of food for thought. And Mohan knows a thing or two about databases. As I said in an earlier tweet,
“tracking @seemohan ‘s database accomplishments is a #bigdata problem.”
Many of the things that we see in the current NoSQL products are really a continuation of a trend that one can trace back to the dawn of relational databases (RDBMS’) themselves.
A long time ago (thirty or forty years ago), there were CICS/ISAM (mainframe) applications that had a very close understanding of the physical record layout. The benefits of generalization and abstraction proposed by CODASYL and later the relational model allowed applications to focus on querying the data in some simple language and not concern themselves with the physical layout and representation of data in files. The benefits of abstraction provided by a simple ubiquitous programming (query) language allowed for an explosion of applications and the popularity of the initial databases.
Later, the popularity of Object Oriented Programming Languages fueled the rise of the object databases and some of us remember the conferences where the death of the relational database was predicted to be imminent. Yet, over time, the benefits of the standardized abstraction and the now ubiquitous Structured Query Language (SQL) eventually won out and relational databases now incorporating some of the object features continued to develop and prosper while the Object Database was largely relegated to a small niche.
More recently, with the emergence of large databases and the need to perform complex analytics, we saw the explosion of OLAP and Cube based technologies. Again we had dire predictions of the imminent death of the relational database. Yet, over time, the benefits of standardized abstraction and SQL, along with developments in the database tier (such as the emergence of MPP databases, column store databases, and hardware accelerated MPP databases) led to the renewal of the relational database and the OLAP and Cube technologies have been relegated to specific niches.
The picture above depicts (click on the image for a larger version) the progression of data management technologies over the past four decades and shows the repeated swing from “specialized” solutions to “general purpose” solutions. The little green dot is an approximation of where we are on this journey (today) and it is certainly my belief that we are seeing history repeat itself. (In subsequent blog posts, we’ll talk in more detail about specialization and generalization).
NoSQL is a result of the new applications and workloads that data management systems are being faced with these days. And these applications have led to the creation of several alternate technologies, just as we have seen in the past, and yet another declaration of the imminent death of the relational database. One must however marvel at the sheer number and diversity in these NoSQL solutions and necessity is no doubt the mother of NoSQL (link to Matt Aslett‘s blog), just as necessity was also the mother of the Object Database and the OLAP Cube.
But, as history has shown, the relational database will return and all this hoopla is just #nonsensql. The benefits of the standardized abstraction and the ubiquitous Structured Query Language will prevail. Over the next few blog posts, we will delve more deeply into the benefits of standardization and understand why it is that the relational database keeps coming back in the face of all of these supposed shortcomings.
References:
@seemohan (C. Mohan) Part 1: The NoSQL hoopla … What is NonsenSQL about it?,
@seemohan (C. Mohan) Part 2: The NoSQL hoopla … What is NonsenSQL about it?,
@seemohan (C. Mohan) Part 3: The Myths about Transactions (ACID) and NoSQL &
@seemohan (C. Mohan) Part 4: A Request and an Offer to NoSQL Techies .
@maslett (Matt Aslett) Necessity is the mother of NoSQL.
Add new comment