Database Reference
In-Depth Information
can be in the cloud, which is helpful if a cloud data storage provider would like to
localize transaction services for some of its data to a TC component. There can be
multiple DCs serviced by one TC, where transactions spanning multiple DCs are
naturally supported because a TC does not depend on where data items are stored.
Also, there can be multiple TCs, yet, a transaction is serviced by one specific TC.
The
Calvin
system [
221
] has been designed to run alongside a non-transactional
storage system with the aim of transforming it into a shared-nothing (near-)linearly
scalable database system that provides high availability and full ACID transactions.
These transactions can potentially span multiple partitions spread across the shared-
nothing cluster. Calvin accomplishes this goal by providing a layer above the storage
system that handles the scheduling of distributed transactions, as well as replication
and network communication in the system. The key technical feature of Calvin is
that it relies on a deterministic locking mechanism that enables the elimination of
distributed commit protocols. In particular, the essence of Calvin lies in separating
the system into three separate layers of processing:
The sequencing layer
which intercepts transactional inputs and places them into
a global transactional input sequence which represents the order of transactions
to which all replicas will ensure serial equivalence during their execution.
The scheduling layer
that orchestrates transaction execution using a deterministic
locking scheme to guarantee equivalence to the serial order specified by the
sequencing layer while allowing transactions to be executed concurrently by a
pool of transaction execution threads.
The storage layer
which handles all physical data layout. Calvin transactions
access data using a simple CRUD interface. Therefore, any storage engine
supporting a similar interface can be directly plugged into Calvin.
Each node in a Calvin deployment typically runs one partition of each layer. It
supports horizontal scalability of the database and unconstrained ACID-compliant
distributed transactions by supporting both asynchronous and Paxos-based syn-
chronous replication, both within a single data center and across geographically
separated data centers.
10.5
Summary
In this chapter, we discussed a set of research challenges, that have been brought on
by the reliance on cloud computing platforms and faced by application developers
and designers of cloud database systems, and pointed out alternative research
directions for tackling them. Table
10.1
summarizes some of the open research
challenges along with the key related factors which could influence the design of
their solutions. For user of cloud database services, we can draw the following
recommendations:
