Research problems/questions, motivations and goals.
This paper was published to provide a novel approach to implement cloud storage system taking into
account the tradeoff of consistency and performance/availability resulting from read and write operation.
Suggested key-value storage is called Pileus and it allows the developers to declare their consistency
level and latency priorities through service level agreement(SLA).
The research addresses how to define and implement consistency-based SLA with different levels of
SLA. It offers range of consistency-latency choices between strong and eventual consistency. It allows
different applications that are accessing the cloud storage system to have different consistency-latency
level guarantees. It offers insights into usage by giving concrete scenarios of how the application can be
used. It also provides evaluations that compares the performance/consistency with the conventional static
configuration and server scheme.
Assumptions
The main assumption this research paper has is that both application developers and cloud storage
providers will benefit from allowing the developers to choose a range of performance and consistency
level for different applications in a declarative and adaptive manner.
Solutions/approaches/designs
Pileus system combines a traditional key-value store offered by current cloud storage providers with new
consistency choices and expanded service level agreements. Pileus manages a collection of replicated
key-value tables. Tables are composed of one or more data objects which contains key-value pairs in as a
byte sequence. The API offers two operations; Get, Put. Get differs with the traditional store in that it
takes a consistency-based SLA as an optional argument. Also, get returns whether the SLA was met or
not along with the data object that was requested. It supports transactions where each operations within
the transactions are performed with snapshot isolation and committed atomically. Operations are wrapped
within the Session, where each session takes the SLA as the argument.
Consistency levels for get operation includes subSLAs based on the value of consistency and latency
pair; strong, eventual, read-my-writes, monotonic, bounded and casual. Selecting different level limits the
set of servers that the read request is sent, within a spectrum of closer to primary site that may be more
distant. Developer can list the preference of different subSLAs specified as utility. If the parameter for the
session is not set as <eventual, unbounded>, the get operation will return error when none of the
subSLAs can be met in the given network environment.
Pileus system is composed with Storage nodes, Replication agents, and monitors. Storage nodes are
servers that hold data which are subdivided into master and secondary node. Replication agents coexists
with storage nodes and they periodically pull data from primary nodes and asynchronously propagates
the update. For scalability large table is sharded in to tablets. All puts are performed and ordered at
primary sites allowing authoritative get for getting answer for strongly consistent gets and avoiding
conflicts. Then secondary nodes receive update in timestamp order guaranteeing prefix consistency.
Each storage node maintains a metadata that includes tablet store(set of key, value, timestamp tuples)
and high time stamp(the timestamp of the latest data object that was updated). Get request responds with
the both requested data objects’ timestamp and hightime stamp of the node and the value.
Node selection takes into account 3 parameters; key that is being searched, SLA configuration, previous
data object that was read/written in the current session to compute minimum acceptable timestamp.
Probing the network latency, high timestamp is done through Monitor storage node. It also supports 3
operations; PNodeCons, PNodelat, PNodeSla. With these probability value, client calculates maximum
utility for each subSLAs provided in the configuration.
Evaluation methodologies
Adapting consistency to different conditions in accordance with application-specific SLAs can yield
significant benefits compared to selecting a fixed consistency. The goal is to measure how well the client’s
Get operations meet a given consistency-based SLA. Evalution is done with the usage the shopping cart,
and password checking SLA, comparing with the results of comparison groups including the systems that
gets from primary, randomly selects nodes and gets from the closest node. The values compared were
average delivered utility.
Key contributions and comparisons with other work (why is the paper novel?)
There are other storage systems like Amazon’s SimpleDB and DynamoDB, Google’s AppEngine data
store, Yahoo!’s PNUTS, and Oracle’s NoSQL Database offering read operations with a choice between
strong consistency and eventual consistency. However, the problem with these systems are that the
developers have to decide the consistency and performance configuration at the stage of the
development. Unlike other systems, Pileus allows the developers provide a SLA in a declarative manner.
Pileus is the first cloud storage system to offer a broad choice of consistency guarantees, and allow the
requested consistency to vary for each Get even when accessing the same data.
What are the shortcomings and how can one improve the paper? (included in the assumption
part too)
Regarding further improvement, additional optimization could have been included; using the internet
packet Current implementation of the Pileus prototype is manually configured by a system administratorto
select primary sites, create new replicas, migrate nodes, or repartition tables. Also, it may include
adaptive probing by monitoring node, usage of machine learning to predict a node’s high stamp and
sharing the network information within clients that is located in the same data center, dynamically
changing primary nodes, multi-node selection for parallel gets, multi-site put.