Opinions, News and Views on Semantic Technology and Research

Semantics Online

Subscribe to Semantics Online: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Semantics Online: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Semantics Online Authors: Haim Koshchitzky, Lori MacVittie, Charles Silver, Barry Morris, Maureen O'Gara

Related Topics: Cloud Computing, Datacenter Automation, SOA & WOA Magazine, Cloud Data Analytics, Big Data on Ulitzer


Can We Finally Find the Database Holy Grail?

What are the alternative patterns for designing a truly distributed transactional database system?

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?

In the rest of this series I'll lay out my views of the four alternative models: Shared-Disk, Shared-Nothing, Synchronous Commit and Durable Distributed Cache (DDC).

More Stories By Barry Morris

Barry Morris is CEO & Co-Founder of NuoDB, Inc. An accomplished software CEO with over 25 years of industry experience in the USA and Europe, running private and public companies ranging in scale from early startup phase to 1,000+ employees, he loves to build companies around industry-changing paradigm-shifts in technology. Morris was previously CEO of StreamBase and Iona Technologies.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.