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

The PNUTS system does not have a traditional database log or archive data.
However, it relies on a pub/submechanism that act as a redo log for replaying updates
that are lost before being applied to disk due to failure. In particular, PNUTS pro-
vides a consistency model that is between the two extremes of general serializability
and eventual consistency [63]. The design of this model is derived from the observa-
tion that web applications typically manipulate one record at a time while different
records may have activity with different geographic locality. Thus, it provides per-
record timeline consistency where all replicas of a given record apply all updates
to the record in the same order. In particular, for each record, one of the replicas
(independently) is designated as the master where all updates to that record are for-
warded to the master. The master replica for a record is adaptively changed to suit the
workload where the replica receiving the majority of write requests for a particular
record is selected to be the master for that record. Relying on the per-record timeline
consistency model, the PNUTS system supports the following range of API calls
with varying levels of consistency guarantees

• Read-any : This call has a lower latency as it returns a possibly stale version

of the record.

• Read-critical (required version) : This call returns a version of the record

that is strictly newer than or the same as the required version .

• Read-latest : This call returns the latest copy of the record that reflects all

writes that have succeeded. It is expected that the read-critical and read-
latest can have a higher latency than read-any if the local copy is too stale
and the system needs to locate a newer version at a remote replica.

• Write : This call gives the same ACID guarantees as a transaction with a

single write operation in it (e.g., blind writes).

• Test-and-set-write (required version) : This call performs the requested

write to the record if and only if the present version of the record is the same
as the required version. This call can be used to implement transactions that
first read a record, and then do a write to the record based on the read, e.g.,
incrementing the value of a counter.

Since the system is designed to scale to cover several worldwide replicas, auto-
mated failover, and load balancing is the only way to manage the operations load.
Therefore, for any failed server, the system automatically recovers by copying data
from a replica to other live servers.

9.2.3 a mazon : D ynamo
Amazon runs a worldwide e-commerce platform that serves tens of millions custom-
ers at peak times using tens of thousands of servers located in many data centers
around the world. In this environment, there are strict operational requirements on
Amazon's platform in terms of performance, reliability, and efficiency, and to support
Amazon's continuous growth the platform needs to be highly scalable. Reliability is
one of the most important requirements because even the slightest outage has signifi-
cant financial consequences and impacts customer trust.