NoSQL as the Trend for databases in the Cloud?

SQL seems to be somewhat old fashioned when it comes to scalable databases in the cloud. Non-relational databases (also called NoSQL) seem to take over in most data storage fields. But why do those databases seem to be more popular than the “classic” relational databases? Is it due to the fact that professors at universities “tortured” us with relational databases and therefore reduced our interest – the interest of the “new” generation for relational databases? Or are there some hard facts that tell us why relational databases are somewhat out of date?
I was at a user group meeting in Austria, Vienna, one month ago where I talked about NoSQL databases. The topic seemed to be of interest to a lot of people. However, we sat together for about four hours (my talk was planned for one hour only) discussing NoSQL versus SQL. I decided to summarize some of the ideas in a short article as this is useful for cloud computing.
If we look at what NoSQL offers, we’ll find a numerous offers on NoSQL databases. Some of the most popular ones are MongoDB, Amazon Dynamo (Amazon SimpleDB), CouchDB, and Cassandra. Some people might think that non-relational databases might be for those people who are too “lazy” to do their complex business logic in the database. In fact, this logic reduces the performance of a system. If there is a need for a high-responsive and available system, SQL Databases might not be your best choice. But why is NoSQL more responsive than SQL-based systems? And why is there this saying that NoSQL allows better scalability than SQL-based systems? To understand this topic, we need to go back 10 years.
Dr. Eric A Brewer in his keynote “Symposium on Principles of Distributed Computing 2000” (Towards Robust Distributed Systems, 2000) addressed a problem that arises when we need high availability and scalability. This was the birth of the so-called “CAP Theorem.” The CAP Theorem says that a distributed system can only achieve two out of the three states: “Consistency, Availability and Partition tolerance.” This means:

• That every node in a distributed system should see the same data as all other nodes at the same time (consistency)
• That the failure of a node must not affect the availability of the system (availability)
• That the system stays tolerant to the loss of some messages

Nowadays when talking about databases we often use the term “ACID,” but NoSQL is related to another term: BASE. Base stands for “Basically Available, Soft state, eventually consistent.” If you want to go deeper into eventually consistent, read the post by Werner Vogels – Eventually Consistent revisited. BASE states that all updates that occur to a distributed system will be eventually consistent after a period of no updates. For distributed systems such as cloud-based systems, it is simply not possible to keep a system consistent at all times. This results in bad availability.
To understand eventually consistent, it might be helpful to look at how Facebook is handling their data. Facebook uses MySQL, which is a relational (SQL) database. However, they simply don’t use such features as joins that MySQL offers them; Facebook joins data on the web server. You might think “What, are they crazy?” However, the problem is that the joins Facebook needs will sooner or later result in a very slow system. David Recordon, Manager at Facebook, stated that joins are better performing on the web server [1]. Facebook must know what is good performance or not as they will store some 50 petabytes of data by the end of 2010. Twitter, another social platform that needs to scale their platform, should also think about switching to NoSQL platforms. This will hopefully reduce the “fail whale” to a minimum [2].
Summing it up, NoSQL is relevant for applications that are in the need of large-scale global Internet applications. But are there any other benefits for NoSQL databases? Another benefit is that there are often no schemas associated with a table. This allows the database to adopt new business requirements. I’ve seen a lot of projects where the requirements changed over the years. As this is rather hard to handle with traditional databases, NoSQL allows easy adoption of such requirements. A good example of this is Amazon. Amazon stores a lot of data on their products. As they offer products of different types – such as personal computers, smartphones, music, home entertainment systems and books – they need a flexible database. This is a challenge for traditional databases. With NoSQL databases it’s easy to implement some kind of inheritance hierarchy – just by calling the table “product” and letting every product have its own fields. Databases such as Amazon Dynamo handle this with key/value storage. If you want to dig deeper into Amazon Dynamo, read Eventually Consistent [3] by Werner Vogels.
Will there be some sort of “war” between NoSQL and SQL supporters like the one of REST versus SOAP? The answer is maybe. Who will win this case? As with SOAP versus REST, there won’t be a winner or a loser. We will have more opportunities to choose our database systems in the future. For data warehousing and systems that require business intelligence to be in the database, SQL databases might be your choice. If you need high-responsive, scalable and flexible databases, NoSQL might be better for you.
Resources

1. Facebook infrastructure
2. Twitters switches to NoSQL
3. Eventually Consistent