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

in the target consistency tradeoffs (e.g., consistency-cost in [47,48] and consis-
tency performance in [8,11,49]) and in the way they define the consistency require-
ments. Hereafter, we present two adaptive consistency models (next section will
be devoted to our adaptive consistency solution Harmony). For both models, we
start by presenting the motivation and the use case, then we present the adap-
tive approach, and finally we describe the model implementation on the targeted
infrastructure.
10.5.1 r eD b lue C onsistenCy
Due to the high network latencies, strong consistency guarantees are too expensive
when storage systems are geographically distributed. Therefore, weaker consistency
semantics such as eventual consistency is the most popular choice for applications
that require high availability and performance. However, weaker consistency models
are not suitable for all applications classes, even if most operations within one appli-
cation require only eventual consistency. For instance, in the case of a social network,
a transaction that might combine privacy-related updates among other social activity
operations might need more than eventual consistency. Privacy-related operations
require strong ordering at all geographical sites in order not to violate the privacy
setting of the user. On the other hand, social activity operations might only require
eventual convergence of replicas no matter the ordering of the operations.
RedBlue consistency [8] is introduced to provide as fast responses as possible
and consistency when necessary. It provides two types of operations: Red and Blue.
Blue operations are executed locally and replicated lazily. Therefore, their ordering
can vary from site to site. In contrast, Red operations require a stronger consis-
tency. They must satisfy serializable ordering with each other and as a result gener-
ate communication across sites for coordination. Subsequently, the RedBlue order
is defined as a partial ordering for which all Red operations are totally ordered.
Moreover, every site has a local causal serialization that provides a total ordering of
operations that are applied locally. This definition of the RedBlue consistency does
not guarantee the replicas state convergence. Convergence is reached if all causal
serializations of operations at the level of each site reach the same state. However,
with the RedBlue consistency, blue operations might have different orders in dif-
ferent sites. Therefore, noncommutative operations executed in a different order
would not allow replicas convergence. As a result, noncommutative operations
should not be tagged as blue if the convergence is to be insured. An extension of
the RedBlue consistency consists in splitting original application operations into
two components. A generator operation that has no side-effect and is executed only
at the primary site and shadow operation , which is executed at every site. Shadow
operations that are noncommutative or violate the application variant (e.g., negative
values for a positive variable) are labeled Red while all other shadow operations are
labeled blue.
The RedBlue consistency is implemented in a system called Gemini storage sys-
tem. Gemini uses MySQL as its storage backend. Its deployment consists of several
sites where each site is composed of four components: a storage engine , a proxy
server , concurrency coordinator , and data writer . The proxy server is the component