How It All Fits Together

As we have described often, transactions need to provide some guarantees if applications are to benefit from them.

Distributed transactions need to provide similar guarantees.

Guarantees distributed systems should provide

Some basic guarantees commonly used are contained in the ACID acronym that we analyzed earlier.

Consistency and durability guarantees

Consistency and durability do not require very different treatment in a distributed setting when compared to a centralized, single-node system. For durability, it’s enough for the data to be stored in non-volatile storage before it is acknowledged by the client.

To achieve durability in a distributed system, we should store data in more than one replicas before acknowledging, so that the system can survive the failures of a single node.

To achieve consistency, the system can introduce some additional read and write operations in the transaction’s context to guarantee the preservation of application consistency. These operations may be automatically generated, such as referential integrity constraints from foreign keys or cascades, or they may be defined by the application, e.g., via triggers.

Atomicity and isolation guarantees

The guarantees of atomicity and isolation are more challenging to preserve, and we previously analyzed some of the algorithms we can use for this purpose.

The course examined some algorithms that can help preserve isolation across transactions, and some algorithms that can help preserve atomicity in a distributed system.

Combining algorithms to guarantee all properties

The algorithms must combine to guarantee all properties: atomicity, consistency, isolation, and durability.

Some combinations of these algorithms might be easier to implement in practice because of their common characteristics. For example, two-phase locking has very similar characteristics to two-phase commit, so it’s easier to understand how they can be combined.

SpannerJ. C. Corbett et al., “Spanner: Google’s Globally-Distributed Database,” in Proceedings of OSDI 2012, 2012. is an example of a system that uses a combination of these two techniques to achieve atomicity and isolation, as explained later in the course.

Complexity in algorithms

Looking at the previous algorithms presented, it is easy to realize that some of them introduce either brittleness (e.g., two-phase commit) or a lot of additional complexity to a system (e.g., quorum-based commit).

Algorithms that work for both systems

The algorithms presented for isolation can be used in both centralized and distributed systems. However, their use in a distributed system has several additional implications.

For example, two-phase locking requires the use of distributed locks, which is something that is not trivial to implement in a distributed system, as we will explain later in the course.

Optimistic techniques, such as snapshot isolation,C. Binnig, S. Hildenbrand, F. Farber, D. Kossmann, J. Lee, and N. May, “Distributed Snapshot Isolation: Global Transactions Pay Globally, Local Transactions Pay Locally,” The VLDB Journal, Volume 23 Issue 6, December 2014, 2014. require a lot of data transfer between different nodes in a distributed system, which has adverse effects on performance.

As a consequence, using transactions in a distributed system comes at a higher cost compared to a centralized system. So, systems that do not have a strong need for distributed systems can be designed to operate safely without them.

That is also one of the reasons why many distributed databases either do not provide full support for ACID transactions or force the user to opt in to use them explicitly.