Distributed Transactional Systems Cannot Be Fast

Abstract

We prove that no fully transactional system can provide fast read transactions (including read-only ones that are considered the most frequent in practice). Specifically, to achieve fast read transactions, the system has to give up support of transactions that write more than one object. We prove this impossibility result for distributed storage systems that are causally consistent, i.e., they do not require to ensure any strong form of consistency. Therefore, our result holds also for any system that ensures a consistency level stronger than causal consistency, e.g., strict serializability. The impossibility result holds even for systems that store only two objects (and support at least two servers and at least four clients). It also holds for systems that are partially replicated. Our result justifies the design choices of state-of-the-art distributed transactional systems and insists that system designers should not put more effort to design fullyfunctional systems that support both fast read transactions and ensure causal or any stronger form of consistency.

The Impossibility of Fast Transactions

“…Finally, in contrast to previous work [20,21,12,22,13], and to the best of our knowledge, our work is the first one that brings fault-tolerance and fast transactions together into attention. As a matter of fact, the original work of Lu et al [13] that defines fast transactions, presents the COPS-SNOW data store that supports such fast transactions.…”

“…Tomsic et al [20] investigate the relation between the consistency, the speed, and the freshness of reads and among others show that visible fast transactions are possible by reading an arbitrarily old snapshot of the database and hence such a data store does not provide the weak property of eventual visibility. Didona et al [12,22] look into causally-consistent data stores and investigate the cost fast readonly transactions impose on writes, as well as prove that a data store cannot provide fast read-only transactions in combination with write transactions. In contrast to previous work [13,21,20,12,22] we consider the weaker consistency model of monotonic writes and hence we strengthen our impossibility result.…”

“…Didona et al [12,22] look into causally-consistent data stores and investigate the cost fast readonly transactions impose on writes, as well as prove that a data store cannot provide fast read-only transactions in combination with write transactions. In contrast to previous work [13,21,20,12,22] we consider the weaker consistency model of monotonic writes and hence we strengthen our impossibility result. Finally, note that real systems [34,35] that provide fast transactions, either assume strong synchrony (e.g., Spanner [34] relies on global time), or provide visible read-only transactions and hence are not fault-tolerant.…”

“…The notion of dec is the first one we are aware of to capture formally the notion of k-version read or a k-version data store in an elegant way. Other approaches [12,22,21] are not formal enough and can be potentially circumvented (see related in Section 5). Fast reads.…”

“…In the same work, Lu et al prove that fast read-only transactions are possible by presenting COPS-SNOW, a causally-consistent data store that provides fast read-only transactions. Because of the critical importance of fast read-only transactions for industrial data stores, fast read-only transactions have received much attention of late [20,21,12,22]. However, all this research [20,21,12,22,13] targets the ideal case where servers never fail.…”