An Overview of the NoSQL World - Large Scale and Big Data: Processing and Management - page 315

transactional concurrency control and recovery. The TC passes requests to the
appropriate data component (DC). The DC, guaranteed by the TC to never receive
conflicting concurrent operations, needs to only support atomic record operations,
without concern for transaction properties that are already guaranteed by the TC.
In this architecture, data can be stored anywhere (e.g., local disk, in the cloud) as
the TC functionality in no way depends on where the data is located. The TC and
DC can be deployed in a number of ways. Both can be located within the client,
and that is helpful in providing fast transactional access to closely held data. The
TC could be located with the client while the DC could be in the cloud, which is
helpful in case a user would like to use its own subscription at a TC service or
wants to perform transactions that involve manipulating data in multiple loca-
tions. Both TC and DC 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 [62] has been designed to run alongside a nontransactional
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 intercepts transactional inputs and places them into
a global transactional input sequence, which represents the order of trans-
actions to which all replicas will ensure serial equivalence during their
execution.
• The scheduling layer orchestrates transaction execution using a determin-
istic locking scheme to guarantee equivalence to the serial order specified
by the sequencing layer while allowing transactions to be executed concur-
rently by a pool of transaction execution threads.
• The storage layer handles all physical data layout. Calvin transac-
tions access data using a simple CRUD interface. Therefore, any stor-
age 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 synchro-
nous replication, both within a single data center and across geographically sepa-
rated data centers.