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

The G-Store system [29] has been presented as a scalable data store that provides
transactional multikey access guarantees over non-overlapping groups of keys using
a key-value store. The main idea of GStore is the Key Group abstraction that defines
a relationship between a group of keys and represents the granule for on-demand
transactional access. This abstraction allows the Key Grouping protocol to collocate
control for the keys in the group to allow efficient access to the group of keys. In
particular, the Key Grouping protocol enables the transfer of ownership for all keys
in a group to a single-node that then efficiently executes the operations on the Key
Group. At any instance of time, each key can only belong to a single group and the
Key Group abstraction does not define a relationship between two groups. Thus,
groups are guaranteed to be independent of each other and the transactions on a
group guarantee consistency only within the confines of a group. The Key Grouping
protocol ensures that the ownership of the members of a group reside with a single
node. Thus, the implementation of the transaction manager component does not
require any distributed synchronization and is similar to the transaction manager of
any single-node relational database management systems. The key difference is that
in G-Store, transactions are limited to smaller logical entities (key groups). A simi-
lar approach has been followed by the Google Megastore system [9]. It implements
a transactional record manager on top of the Bigtable data store [21] and provides
transaction support across multiple data items where programmers have to manu-
ally link data items into hierarchical groups and each transaction can only access a
single group. Megastore partitions the data into a collection of entity groups , a priori
user-defined grouping of data for fast operations, where each group is independently
and synchronously replicated over a wide area. In particular, Megastore tables are
either entity group root tables or child tables. Each child table must declare a single
distinguished foreign key referencing a root table. Thus, each child entity references
a particular entity in its root table (called the root entity). An entity group consists of
a root entity along with all entities in child tables that reference it. Entities within an
entity group are mutated with single-phase ACID transactions (for which the commit
record is replicated via Paxos). Operations across entity groups could rely on expen-
sive two-phase commit operations but they could leverage the built-in Megastore's
efficient asynchronous messaging to achieve these operations. Google's Spanner
[27] has been presented as a scalable and globally distributed database that shards
data across many sets of Paxos state machines in datacenters that are spread all over
the world. Spanner automatically reshards data across machines as the amount of
data or the number of servers changes, and it automatically migrates data across
machines (even across datacenters) to balance load and in response to failures. It
supports general-purpose transactions, and provides a SQL-based query language.
Deuteronomy [47] have presented a radically different approach toward scaling
databases and supporting transactions in the cloud by unbundling the database
into two components: (1) The transactional component (TC) that manages trans-
actions and their concurrency control and undo/redo recovery but knows nothing
about physical data location. (2) The data component (DC) that maintains a data
cache and uses access methods to support a record-oriented interface with atomic
operations but knows nothing about transactions. Applications submit requests
to the TC, which uses a lock manager and a log manager to logically enforce