Results 1 - 10
of
10
Transaction Chains: Achieving Serializability with Low Latency in Geo-distributed Storage Systems. In:
- 24th ACM SOSP,
, 2013
"... Abstract Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serializable transactions and low latency, under two conditions. Fir ..."
Abstract
-
Cited by 24 (1 self)
- Add to MetaCart
(Show Context)
Abstract Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serializable transactions and low latency, under two conditions. First, transactions are known ahead of time, permitting an a priori static analysis of conflicts. Second, transactions are structured as transaction chains consisting of a sequence of hops, each hop modifying data at one server. To demonstrate this idea, we built Lynx, a geo-distributed storage system that offers transaction chains, secondary indexes, materialized join views, and geo-replication. Lynx uses static analysis to determine if each hop can execute separately while preserving serializability-if so, a client needs wait only for the first hop to complete, which occurs quickly. To evaluate Lynx, we built three applications: an auction service, a Twitter-like microblogging site and a social networking site. These applications successfully use chains to achieve low latency operation and good throughput.
On Exploiting Locality for Generalized Consensus Alexandru Turcu Binoy Ravindran
"... Abstract-Single leader-based Consensus protocols are known to stop scaling once the leader reaches its saturation point. On the other hand, establishing Consensus of commands by taking into account only their dependencies (as specified by Generalized Consensus) is appealing because of the potential ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract-Single leader-based Consensus protocols are known to stop scaling once the leader reaches its saturation point. On the other hand, establishing Consensus of commands by taking into account only their dependencies (as specified by Generalized Consensus) is appealing because of the potentially higher parallelism and lower latency. However, current solutions have well-known pitfalls due to the higher quorum size, which is required to exploit low-latency fast decisions, and the need for tracking dependency relations. In this paper we briefly introduce M 2 P AXOS, a new implementation of Generalized Consensus that provides a fast decision of commands by leveraging a classic quorum size, which matches just the majority of nodes deployed. M 2 P AXOS does not establish command dependencies based on conflicts; rather it associates accessed objects with nodes, so that the delivery decision of commands operating on the same objects is made by a common node. The evaluation study of M 2 P AXOS confirms its effectiveness by showing an improvement up to 7× over state-of-the-art (Generalized) Consensus protocols.
Design and Implementation is sponsored by USENIX. Extracting More Concurrency from Distributed Transactions
"... Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, l ..."
Abstract
- Add to MetaCart
(Show Context)
Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, leaving many opportunities for concur-rency on the table. This paper presents ROCOCO, a novel concurrency control protocol for distributed transactions that outperforms 2PL and OCC by allowing more con-currency. ROCOCO executes a transaction as a collec-tion of atomic pieces, each of which commonly involves only a single server. Servers first track dependencies be-tween concurrent transactions without actually executing them. At commit time, a transaction’s dependency infor-mation is sent to all servers so they can re-order conflict-ing pieces and execute them in a serializable order. We compare ROCOCO to OCC and 2PL using a scaled TPC-C benchmark. ROCOCO outperforms 2PL and OCC in workloads with varying degrees of contention. When the contention is high, ROCOCO’s throughput is 130% and 347 % higher than that of 2PL and OCC. 1
Extracting More Concurrency from Distributed Transactions
"... Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, l ..."
Abstract
- Add to MetaCart
(Show Context)
Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, leaving many opportunities for concur-rency on the table. This paper presents ROCOCO, a novel concurrency control protocol for distributed transactions that outperforms 2PL and OCC by allowing more con-currency. ROCOCO executes a transaction as a collec-tion of atomic pieces, each of which commonly involves only a single server. Servers first track dependencies be-tween concurrent transactions without actually executing them. At commit time, a transaction’s dependency infor-mation is sent to all servers so they can re-order conflict-ing pieces and execute them in a serializable order. We compare ROCOCO to OCC and 2PL using a scaled TPC-C benchmark. ROCOCO outperforms 2PL and OCC in workloads with varying degrees of contention. When the contention is high, ROCOCO’s throughput is 130% and 347 % higher than that of 2PL and OCC. 1
Building Consistent Transactions with Inconsistent Replication (Extended Version)
"... Abstract Application programmers increasingly prefer distributed storage systems with strong consistency and distributed transactions (e.g., Google's Spanner) for their strong guarantees and ease of use. Unfortunately, existing transactional storage systems are expensive to use -in part becaus ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract Application programmers increasingly prefer distributed storage systems with strong consistency and distributed transactions (e.g., Google's Spanner) for their strong guarantees and ease of use. Unfortunately, existing transactional storage systems are expensive to use -in part because they require costly replication protocols, like Paxos, for fault tolerance. In this paper, we present a new approach that makes transactional storage systems more affordable: we eliminate consistency from the replication protocol while still providing distributed transactions with strong consistency to applications. We present TAPIR -the Transactional Application Protocol for Inconsistent Replication -the first transaction protocol to use a novel replication protocol, called inconsistent replication, that provides fault tolerance without consistency. By enforcing strong consistency only in the transaction protocol, TAPIR can commit transactions in a single round-trip and order distributed transactions without centralized coordination. We demonstrate the use of TAPIR in a transactional key-value store, TAPIR-KV. Compared to conventional systems, TAPIR-KV provides better latency and throughput.
CumuloNimbo: A Cloud Scalable Multi-tier SQL Database
"... This article presents an overview of the CumuloNimbo platform. CumuloNimbo is a framework for multi-tier applications that provides scalable and fault-tolerant processing of OLTP workloads. The main novelty of CumuloNimbo is that it provides a standard SQL interface and full transactional support wi ..."
Abstract
- Add to MetaCart
(Show Context)
This article presents an overview of the CumuloNimbo platform. CumuloNimbo is a framework for multi-tier applications that provides scalable and fault-tolerant processing of OLTP workloads. The main novelty of CumuloNimbo is that it provides a standard SQL interface and full transactional support without resorting to sharding and no need to know the workload in advance. Scalability is achieved by distributing request execution and transaction control across many compute nodes while data is persisted in a distributed data store. In this paper we present an overview of the platform. 1
Extracting More Concurrency from Distributed Transactions
"... Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, l ..."
Abstract
- Add to MetaCart
(Show Context)
Distributed storage systems run transactions across ma-chines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL se-rializes transactions as soon as they conflict and OCC resorts to aborts, leaving many opportunities for concur-rency on the table. This paper presents ROCOCO, a novel concurrency control protocol for distributed transactions that outperforms 2PL and OCC by allowing more con-currency. ROCOCO executes a transaction as a collec-tion of atomic pieces, each of which commonly involves only a single server. Servers first track dependencies be-tween concurrent transactions without actually executing them. At commit time, a transaction’s dependency infor-mation is sent to all servers so they can re-order conflict-ing pieces and execute them in a serializable order. We compare ROCOCO to OCC and 2PL using a scaled TPC-C benchmark. ROCOCO outperforms 2PL and OCC in workloads with varying degrees of contention. When the contention is high, ROCOCO’s throughput is 130% and 347 % higher than that of 2PL and OCC. 1
Transaction chains: achieving serializability with low latency in geo-distributed storage systems
, 2013
"... Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serial-izable transactions and low latency, under two conditions. First, trans ..."
Abstract
- Add to MetaCart
(Show Context)
Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serial-izable transactions and low latency, under two conditions. First, transactions are known ahead of time, permitting an a priori static analysis of conflicts. Second, transac-tions are structured as transaction chains consisting of a sequence of hops, each hop modifying data at one server. To demonstrate this idea, we built Lynx, a geo-distributed storage system that offers transaction chains, secondary indexes, materialized join views, and geo-replication. Lynx uses static analysis to determine if each hop can execute separately while preserving serializability—if so, a client needs wait only for the first hop to complete, which occurs quickly. To evaluate Lynx, we built three applications: an auction service, a Twitter-like microblog-ging site and a social networking site. These applications successfully use chains to achieve low latency operation and good throughput. 1
Transaction chains: achieving serializability with low latency
, 2013
"... Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serial-izable transactions and low latency, under two conditions. First, trans ..."
Abstract
- Add to MetaCart
(Show Context)
Currently, users of geo-distributed storage systems face a hard choice between having serializable transactions with high latency, or limited or no transactions with low latency. We show that it is possible to obtain both serial-izable transactions and low latency, under two conditions. First, transactions are known ahead of time, permitting an a priori static analysis of conflicts. Second, transac-tions are structured as transaction chains consisting of a sequence of hops, each hop modifying data at one server. To demonstrate this idea, we built Lynx, a geo-distributed storage system that offers transaction chains, secondary indexes, materialized join views, and geo-replication. Lynx uses static analysis to determine if each hop can execute separately while preserving serializability—if so, a client needs wait only for the first hop to complete, which occurs quickly. To evaluate Lynx, we built three applications: an auction service, a Twitter-like microblog-ging site and a social networking site. These applications successfully use chains to achieve low latency operation and good throughput. 1
