Spanner

Corbett, James C.; Hochschild, Peter; Hsieh, Wilson C.; Kanthak, Sebastian; Kogan, Eugene; Li, Hongyi; Lloyd, Alexander; Melnik, Sergey; Mwaura, David; Nagle, David F.; Quinlan, Sean; Dean, J. Michael; Rao, Rajesh; Rolig, Lindsay; Saitō, Yasushi; Szymaniak, Michal; Taylor, Calvin W.; Wang, Ruth; Woodford, Dale; Epstein, Michael; Fikes, Andrew; Frost, Christopher; Furman, J. J.; Ghemawat, Sanjay; Gubarev, Andrey; Heiser, Christopher

doi:10.1145/2518037.2491245

Cited by 350 publications

(29 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Many distributed database systems (Sinfonia [4], Percolator [6], Spanner [7], Clock-SI [8] and Yesquel [9], for instance) guarantee validity and agreement in crashfailure executions through a two-phase commit (2PC) protocol [2]. 2PC induces two communication rounds among processes.…”

Section: Previous Resultsmentioning

confidence: 99%

See 1 more Smart Citation

How Fast can a Distributed Transaction Commit?

Guerraoui

Wang

2017

Proceedings of the 36th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems

View full text Add to dashboard Cite

The atomic commit problem lies at the heart of distributed database systems. The problem consists for a set of processes (database nodes) to agree on whether to commit or abort a transaction (agreement property). The commit decision can only be taken if all processes are initially willing to commit the transaction, and this decision must be taken if all processes are willing to commit and there is no failure (validity property). An atomic commit protocol is said to be non-blocking if every correct process (a database node that does not fail) eventually reaches a decision (commit or abort) even if there are failures elsewhere in the distributed database system (termination property).Surprisingly, despite the importance of the atomic commit problem, little is known about its complexity. In this paper, we present, for the first time, a systematic study on the time and message complexity of the problem. We measure complexity in the executions that are considered the most frequent in practice, i.e., failure-free, with all processes willing to commit. In other words, we measure how fast a transaction can commit. Through our systematic study, we close many open questions like the complexity of synchronous non-blocking atomic commit. We also present optimal protocols which may be of independent interest. In particular, we present an effective protocol which solves what we call indulgent atomic commit that tolerates practical distributed database systems which are synchronous "most of the time".

show abstract

Section: Previous Resultsmentioning

confidence: 99%

“…Many modern distributed information systems are transactional, including HP's Sinfonia [4], Yahoo's PNUTS [5], Google's Percolator [6] and Spanner [7], Clock-SI [8] and Yesquel [9].…”

Section: Introductionmentioning

confidence: 99%

How Fast can a Distributed Transaction Commit?

Guerraoui

Wang

2017

Proceedings of the 36th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems

View full text Add to dashboard Cite

show abstract

“…Megastore and its variants [1,11] and Spanner [5], which target read-dominated workloads, use this strategy. However, this extends the certification time of transactions that update objects, since in addition to the replication at the OMs, the TMs have to replicate their operations on the locks.…”

Section: Two-phase Commitmentioning

confidence: 99%

Spanner's concurrency control

Malkhi

Martin

2013

SIGACT News

View full text Add to dashboard Cite

Distributed storage systems have now become mainstream, partly due to exponential growth in data volumes. It is common for applications nowadays to access data that is partitioned or sharded across many nodes, and in addition, partially replicated. Large Internet companies further deploy applications that span multiple data centers.For a few years, it was common to settle for weak consistency in such settings, adhering to the so-called "NoSQL" approach. Indeed, an article that appeared in this column four years ago 1 reported a "fear of synchronization" among chief architects who had built large-scale distributed systems in industry. But in the past couple of years, we see this trend reversing. Both academic and industrial projects have recognized the need for strong consistency and so-called ACID transactions in large distributed storage systems. Such strong consistency is the topic of the current column.Our first contribution, by Dahlia Malkhi and Jean-Philippe Martin explains the concurrency control mechanism of Google's Spanner system. Our second contribution, by Ittay Eyal, discusses more generally fault-tolerant architectures for distributed ACID transactions. Many thanks to Dahlia, Jean-Philippe, and Ittay for their contributions! Farewell. On a personal note, this is my last issue as editor of the distributed computing column.

show abstract

“…This approach is used by shared storage KVSs such as BigTable [3], Spanner [7] and HBase 2 . The persistent data is not stored in the nodes of KVSs, but in underlying distributed file systems such as GFS [11] or HDFS [18].…”

Section: Partitioning In Key-value Storesmentioning

confidence: 99%

“…This allows key lookups to be performed locally, in a very efficient manner [10]. Other KVSs [3,7,5] rely on dedicated directory services that provide flexible mapping from virtual nodes to physical nodes. Essentially, this approach also uses random placement strategy.…”

Section: Data Placementmentioning

confidence: 99%

Efficient Node Bootstrapping for Decentralised Shared-Nothing Key-Value Stores

Han

Venugopal

2013

Middleware 2013

View full text Add to dashboard Cite

Abstract. Distributed key-value stores (KVSs) have become an important component for data management in cloud applications. Since resources can be provisioned on demand in the cloud, there is a need for efficient node bootstrapping and decommissioning, i.e. to incorporate or eliminate the provisioned resources as a members of the KVS. It requires the data be handed over and the load be shifted across the nodes quickly. However, the data partitioning schemes in the currentstate shared nothing KVSs are not efficient in quick bootstrapping. In this paper, we have designed a middleware layer that provides a decentralised scheme of auto-sharding with a two-phase bootstrapping. We experimentally demonstrate that our scheme reduces bootstrap time and improves load-balancing thereby increasing scalability of the KVS.

show abstract

Spanner

Cited by 350 publications

References 18 publications

How Fast can a Distributed Transaction Commit?

How Fast can a Distributed Transaction Commit?

Spanner's concurrency control

Efficient Node Bootstrapping for Decentralised Shared-Nothing Key-Value Stores

Contact Info

Product

Resources

About