Star

Abstract

In this paper, we present STAR, a new distributed in-memory database with asymmetric replication. By employing a singlenode non-partitioned architecture for some replicas and a partitioned architecture for other replicas, STAR is able to efficiently run both highly partitionable workloads and workloads that involve cross-partition transactions. The key idea is a new phase-switching algorithm where the execution of single-partition and cross-partition transactions is separated. In the partitioned phase, single-partition transactions are run on multiple machines in parallel to exploit more concurrency. In the single-master phase, mastership for the entire database is switched to a single designated master node, which can execute these transactions without the use of expensive coordination protocols like twophase commit. Because the master node has a full copy of the database, this phase-switching can be done at negligible cost. Our experiments on two popular benchmarks (YCSB and TPC-C) show that high availability via replication can coexist with fast serializable transaction execution in distributed in-memory databases, with STAR outperforming systems that employ conventional concurrency control and replication algorithms by up to one order of magnitude. PVLDB Reference Format:

Epoch-based commit and replication in distributed OLTP databases

“…In addition, COCO uses optimistic concurrency control and each record in the database has an associated TID. The TID of a record usually indicates the last transaction that modified the record and can be used to detect if a read from backup replicas is stale [34,63,69,72]. As a result, a transaction in COCO can read from nearest backup replicas and only validates with the primary replica in the commit phase, which significantly reduces network traffic and latency.…”

“…COCO assigns a TID to each transaction as well in this step. The assignment can happen either prior to or after read validation [34,63,[69][70][71][72], depending on whether the TID is used during read validation. There are some conditions to assign a TID.…”

“…Many recent single-node concurrency control protocols [34,43,72,74] adopted the design philosophy of Silo [63], in which "antidependencies" (i.e., write-after-read conflicts) are not tracked to avoid scaling bottlenecks. Instead, anti-dependencies are only enforced across epochs boundaries, which naturally fits into the design of COCO based on epoch-based commit and replication.…”

“…COCO is a distributed in-memory OLTP database, in which each table in COCO has a pre-defined schema with typed and named attributes. Transactions are submitted to the system through precompiled stored procedures with different parameters, as in many popular systems [34,62,63,67,70]. Arbitrary logic (e.g., read/write and insert/delete operations) can be implemented in a stored procedure in C++.…”

Zeus

“…For example, some mandate determinism [30,41,57,68], and are limited to noninteractive transactions that require the read/write sets of all transactions to be known prior to execution [58]. Others adopt epoch-based designs to amortize the cost of commit across several transactions [16,42,43]. Contrary to those, Zeus enhances programmability and supports fully-general transactions that need not wait the end of epochs to commit.…”