And since most of us aren’t working on applications that have millions of users, we get to keep using the tried and true methods, no need to bother with something that is only relevant at extreme high scale. The relational database has served us well, and can continue serving us in the future. Learning SQL was a very smart investment, after all.
Let us go back a bit to those Database Wars that I mentioned. In the 70s there were actually quite a lot of different types of databases competing with each other, anything from ISAM to DBase to relational databases. And as you can see, the relational database has won such a decisive victory that it rules undisputed for over a generation.
But one thing that we have to remember is that those Database Wars were fought on a drastically different ground than the one we have today.
1980 vs. 2012
In 1980, a 10 MB hard disk (that is in megabytes, about 2 songs or 3 pictures) cost around 4,000 $ US. Adjusting for inflation, that comes at about 11,000 $ US in today’s dollars. Just to compare, today a 10 MB of disk space would cost you about half a dollar cent. And those aren’t the only changes, of course. Computation speed, memory sizes and networks are all many orders of magnitude faster and cheaper than they were in the 80s.
Even more interesting is the differences in the type of applications being built. In the 80s, a typical application had exactly one user. Multi users’ applications had to support… 3 users. All of them at the same time! The UI paradigms were drastically different, as well. At the time, the master – details form was the top of the hill, the uncontested king of good UI design. But today… there are usually so many items and active elements on a single web page today as there were in entire applications then.
Why the history lesson, you ask? Why, to give you some perspective on the design choices that led to the victory of the relational databases. Space was at a premium, the interaction between the user and the application closely modeled the physical layout of the data in the database. That made sense, because there really were no other alternatives given the environment that existed at the time.
That environment is no longer here, and the tradeoffs made when 30 MB would cost as much as an annual salary are no longer relevant. In particular, one immensely annoying aspect of relational database is very much a problem today. Relational databases trade off read speed in favor of write speed. Because it made perfect sense to make this trade off when disk space was so costly, and making users wait an extra second was no big deal.
In separate studies conducted by both Google and Amazon, they found that even additional 100ms added to the latency of a page severely impacted their bottom line. And yet relational database tradeoff read speed (having to do joins and extra loads) for write speed (having to write small amount of data).
Another problem that pops up frequently with relational database is their inability to handle complex data types, such as collections or nested objects. Oh, you can certainly map that to a relational database, but that requires additional tables, and each additional table is going to make it that much more complex to query the data, work with it and display it to the user.
For many years, I have been working with customers on optimizing their applications using relational databases, and I’ve seen the same problems occur over and over again. That led me to the belief that the NoSQL databases aren’t suitable just for extremely scalable scenarios. NoSQL databases make sense for a wide range of options, and this realization led me to RavenDB.
In my company, we are using RavenDB as the backend database for everything from a blog, our ordering and purchasing systems, the daily build server and many more.
The major advantages that we found weren’t the ability to scale (although that exists), it is the freedom that it gives us in terms of modeling our data and changing our minds.
References: Embracing RavenDB from our NCG partner Oren Eini at the Ayende @ Rahien blog.
