TRANSACTIONS ARE AMAZINGLY powerful mechanisms,
and I’ve spent the majority of my almost 40-year career
working on them. In 1982, I first worked to provide
transactions on the Tandem NonStop System. This
system had a mean time between failures measured in
years4 and included a geographically distributed two-phase commit offering excellent availability for strongly
New innovations, including Google’s Spanner, 2 offer
strongly consistent transactional environments at
extremely large scale with excellent availability. Building
distributed transactions to support highly available
applications is a great challenge that has inspired excellent
innovation and amazing technology. Unfortunately,
this is not broadly available to application developers.
In most distributed transaction systems, the failure
of a single node causes transaction commit to stall.
This in turn causes the application to
get wedged. In such systems, the larger
it gets, the more likely the system is going to be down. When flying an airplane
that needs all of its engines to work,
adding an engine reduces the availability of the airplane. Running a distributed transaction system over thousands
of nodes is impractical without special
mechanisms to tolerate outages. When
application developers build systems
using non-highly available distributed
transactions, the solutions are brittle
and must be discarded. Natural selection kicks in…
Instead, applications are built using
techniques that do not provide transactional guarantees but still meet the needs
of their business.
This article explores and names
some of the practical approaches used
in the implementation of large-scale
mission-critical applications in a world
that rejects distributed transactions.
Topics include the management of
fine-grained pieces of application data
Article development led by
An apostate’s opinion.
BY PAT HELLAND
This is an updated and abbreviated version of an article by the same name first published
in Proceedings of the Conference on Innovative Database Research, 2007.