Consistency Management in Cloud Storage Systems - Large Scale and Big Data: Processing and Management - page 340

implies that the read operation must wait for all the replicas to reply and insures that
all replicas are consistent to return the data to the client. In contrast, in a read consis-
tency of level of Quorum (Quorum is computed as

replicationfactor
2

), two out
of the three (the replication factor is set to three) replicas are contacted to fulfill the
read request and the replica with the most recent version would return the requested
data. In the background, a read repair will be issued to the third replica and will
check for consistency with the first two. If inconsistency occurs, an asynchronous
process will be launched to repair the stale nodes at a later time.

+ 1

10.4.3 y ahoo ! Pnuts
Yahoo!'s requirements for a data management platform that provides scalability, fast
response, reliability, and high availability in different geographical areas, led them
to the design and implementation of PNUTS [31]. PNUTS is a massively parallel
geographically distributed storage system. Its main purpose is to host and serve data
for Yahoo! web applications. PNUTS relies on a novel relaxed consistency model
to cope with availability and fault-tolerance requirements at large scale. PNUTS
provides the user with a simplified relational model. Data is stored in a set of tables
of records with multiple attributes. An additional data type provided to the users is
the “blob” type. A blob encapsulates arbitrary data structures (not necessarily large
objects) inside records.
PNUTS divides the system into a set of regions. Regions are typically, but not nec-
essarily, geographically distributed. Every region consists of a set of storage units ,
a tablet controller , and a set of routers . Data tables are decomposed horizontally
into smaller data structures called tablets that are stored across storage units (serv-
ers) within multiple regions. On the other hand, the routers functionality is to locate
data within tablets and storage units based on a mapping computed and provided by
the tablet controller. PNUTS introduces the novel consistency model of per record
timeline consistency described in Section 10.3. Therefore, it uses an asynchronous
replication scheme. To provide reliability and replication, PNUTS relies on a pub/
submechanism, called Yahoo! Message Broker (YMB). With YMB, PNUTS avoids
other asynchronous replication protocols such as Gossip, and optimizes geographi-
cal replication. Moreover, a replica does not need to acquire the location of other
replicas. Instead, it needs to just subscribe to the data updates within YMB.
For applications and users to deal with timeline consistency, API calls, which pro-
vide varying consistency guarantees, were proposed. The read-any call may return
stale data to the users favoring performance and fast response to consistency. In
common cases, a class of applications require the read data to be more recent than a
given version. The API call read-critical (required_version) is proposed to deal with
these requirements. In contrast, the read-latest call always returns the most recent
version of data. This call, however, may be costly in terms of latency. Moreover,
the API provides two calls for writing data. The write call gives ACID guaran-
tees for the write (a write is a transaction with a single operation). In contrast, test-
and-set-write(required_version) checks the version of the actual data in the system.
If, and only if, the version matches required_version , the write is performed. This