This 3-part blog series was originally featured in Cloud Computing Journal. Here’s part 1 by NuoDB CEO Barry Morris.
The world runs on transactional database systems. Every business depends on them, and we each interact with them many times each day. Furthermore, the world needs to build thousands more applications of transactional database systems to support the next-generation web. Nothing controversial there, but there is a problem: transactional database systems have stubbornly refused to join the 21st century.
The rest of the world is moving toward data center architectures predicated on thousands of commodity machines, commodity networks, and “scale-out” designs. These data centers will offer on-demand computing services that can instantly increase or decrease capacity to applications as needed. It’s easy to just add more web servers, application servers, or storage servers as required. Unfortunately while that works at every other level in the computing stack, it does not work at the database layer. Database systems are scale-up systems, not scale-out systems.
Traditionally, if you want a transactional database to go faster, you need a bigger machine. Period. Solving that problem is the Holy Grail of the database world. And as with the other Holy Grail, many people have given up the quest. But there is a new set of ideas that may just change the game. There are three common design patterns for building distributed transactional databases (“Shared Disk”, “Shared Nothing” and “Synchronous Commit”), and there is now a new idea called Durable Distributed Cache (DDC). It is this fourth way that we at NuoDB are really excited about. But it makes sense to provide some background before talking about that.
Database transactions are pretty powerful things. People have often asked me to name applications that really need transactions, and my response is usually to ask them to name an application that really needs a database. It’s the wrong question in both cases, as you plainly don’t really need transactions, databases, compilers, operating systems, etc., any more than you really need an umbrella. The absence of some of these things can be worked around, and other tools and subsystems can be substituted by a rudimentary home-baked thing. The reason for using database transactions is not that you can’t find some kludgy way of working around them in your application, but that it vastly simplifies the semantics of your system, especially as relates to exceptional conditions. The simplification serves to reduce cost, reduce implementation time and increase quality and maintainability of the end product. Transactional guarantees are highly desirable in almost any application but we sometimes consider the computational (and dollar) costs too high. The best answer would not be in the direction of using transactional systems more sparingly, but in a technological innovation that allows us to use them more pervasively.
In order to illustrate the situation, let’s take an example in which you and I both want to take out the last $1,000 from the same account at the same time. The account balance is stored in an ACID compliant transactional database, and therefore the database system must ensure that at most one of us succeeds. There are multiple ways to do this if both transactions have to run on the same machine. Whatever algorithm is used, it effectively orders the transactions so that whichever of us is judged to have arrived first will get the $1,000. That works. And one cool thing is that it will work even faster if I get a bigger machine.
But what if I don’t want to buy a bigger machine? What if I want to speed it up by using a second small machine? Even in our very simple example you can quickly see the problem. Each of us has a transaction running on our behalf that is trying to decrement the $1,000 account balance by $1,000. If your transactions run on different machines, then we would each have more machine resources allocated to us and might expect to go faster, but our machines have to coordinate. There is no choice because it is not allowable for both transactions to succeed. In principle, each machine needs to obtain permission to update the value of the account balance. This involves network communications, and is orders-of-magnitude more expensive than coordinating the two transactions on a single machine. In many cases a second machine can actually slow down your applications, hence the traditional answer of just getting a bigger machine.
The Ever Bigger Machine strategy is far from ideal. Obviously there are limits to how big your big machine can be. You have to hope that your new web site does not attract too many active users for your maxed-out database server to handle. In addition to on-demand capacity, scale-out systems make other very tempting promises. Aside from much more attractive base economics relating to commodity hardware and/or cloud deployment, they also allow you to provision capacity to your load requirements, and potentially offer much better redundancy and availability models. So we are directed to the topic of this blog series, namely what are the alternative patterns for designing a truly distributed transactional database system?