Anh Nguyen

The emergence of continuous consistency model (CCM)

Conit-based CCMWhat is it?PoliciesExamples

DiscussionBreak…

The composability of consistency conditions Discussion

Summary2

Understand the ideas of CCM, and Conit-based CCM Examples▪ Identify conits, parameters

Understand the general meaning of the framework of the composability of consistency conditionsWhat is it?What is it for?Basic consistency conditions

3

The availability of servicesThe exponential increase in access to Web

services

Network failures

0.1% improvement in availability ≈ 8 hours of additional uptime/year ≈ $1 million in additional revenue

Replication is a key approach4

Despite being a really promising solution to improve the availabality of services, it also brings about many new issuesInconsistency among replicas

Ex: distributed database

5

Strict consistency modelsSynchronise accesses to a subset of replicas to achieve a uniform view of write orderings

One-copy serializability

Impose performance overheadLimit system availability

Keep the system consistent

Well-known tradeoffs between consistency and availability

6

Optimistic consistency modelsAllow multiple updates to take place simultaneously at defferent replicas

Resolve conflicts: reconciliation algorithms (Ficus)

Improve performanceImprove system availability

Unbounded rate of conflicting updates can quickly leave the system in a ”delusional” state

Designers have been forced to choose from either consistency guarantees (strict consistency models) or none at all (optimistic consistency models)Different applications have different requirements about

consistency (the level of consistency)Bulletin board vs Airline reservation system

An application may need different levels of consistency during its runtime or under certain circumstancesA dynamic web page tracking the score of a football game

→ Continuous consistency models: enable services to describe and to specify different levels of consistency in between traditional strong and optimistic consistency

7

Haifeng Yu and Amin Vahdat introduced the concept of a conit (consistency unit)

The conit-based CCMallows a broad range of replicated services to

conveniently and quantitatively express their consistency requirements

applicable to a wide range of applications (generality)

able to efficiently enforce target consistency levels (practicality)

8

A conit is a logical consistency unit

The space of consistency is parameterized by the following metricsNumerial error: the total weight of writes on a conit

not seen by a replica

Order error: the number of writes that have not established their commit order at any one replica

Staleness: a real-time bound on the delay of write propagation among replicas

9

An example: a replicated bulletin board service where users may post/retrieve news messages to/from any replicaConit: number of all news messages

Numerial error: the total number of messages posted system-wide but not seen locally

Order error: the number of out of order messages on a given replica (messages seen locally but not committed)

Staleness: the delay of messages10

An exercise Airline Reservation System

A replicated e-commerce service that accepts inquiries and purchase orders on a catalog

Each server maintains a full replica of the flight information database and accepts user reservatinos and inquiries about seat availability

Conitrepresents for the number of available seatsAt a state of the system

Committed value of the number of available seats: 300At a replica:

the number of available seats is 350The number of seats currently booked by users (not committed yet): 100Numerial error: Order error: Staleness

11

50100

12

The continuity of conit-based CCM (numerical error, order error, staleness) Strict consistency models: (0,0,0) Optimistic consistency models: (∞, ∞, ∞) Real values for the parameters achieve the continuity

The level of service consistency is adjusted flexibly by changing (numerical error, order error, staleness)

Each replica can have its own independent consistency level for a conit. This allows the system to route client requests to replicas with appropriate consistency bounds on a per-request basis In the airline reservation system, requests from ”preferred”

clients may be directed to a replica that maintains higher consistency levels (reducing the probability of an inconsistent access)

13

AffectConit(): how each write affects the return value of a conit F. The systemcan then infer the return value of F by summing all accumulated numerical weights

DependonConit(): declare the required consistency level on each access14

Continuous consistency programmingCrystallise high-level application consistency

semantics. ”what does 90% consistency mean?”

Conit, numerical error, order error, staleness

AffectConit()

DependonConit()

TACT: A middleware layer

15

Can conit-based CCM model the consistency of all (most) services?

DifficultiesThe number of conits changes rapidly?

Adaptability

Haifeng Yu, Amin Vahdat, ”The Costs and Limits of Availability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006)

16

17

DependonConit(): declare the required consistency level on each access

Another approach to express different levels of consistency Defines basic consistency conditions

A formal framework that enables composing a collection of consistency conditions into a more restrictive one

Proves that a given implementation of a high level condition is correct

Can be used to devise flexible, composable implementation of consistency conditions

18

Definitions and conventions Client processes: p1, p2, …, pn

An operation: op (read, write) An invocation event: inv(op) A corresponding response event: resp(op)

A history (H): a sequence of invocation and response events A sequential history: each invocation event is immediately followed by

the matching response event

A serialization (S) of a history H: a sequential history containing all the operations of H

A sequential history H to be legal if the value returned by each read operation r in H is the same as the value written by the last write operation that accesses the same object before r in H

19

Composability framework Consistency condition (consistency): a set of restrictions on

allowed histories (level of consistency)

Eventual Propagation: every write operation by any process must be seen by all other processes

Strong consistency conditions require the existence of some special legal serialization of the history All processes view the operations in the same logical order

Weaker conditions only require the existence of one special serialization for each process Each process views the operations in a different logical order

A history preserves a consistency condition by requiring the existence of a serialization set that obeys certain ordering restrictions

20

Basic consistency conditionsRead Your Writes (for a local history)

for every two operations write and read in the local history

If write precedes read, the return value of read is the value updated by write

FIFO of Reads (for a local history)for every two operation read1 and read2 in the local

history

If read1 precedes read2, the return value of read2 is ”newer” or equal to the return value read1

21

Basic consistency conditionsFIFO of Writes (for a local history)

For every two operations write1 and write2 in the local history

If write1 precedes write2, the object is updated by write1 and then write2

Reads Before Writes (for a local history)For every two operations read and write in the

local history

If read precedes write, the return value of read is the value not updated by write

22

Basic consistency conditionsLocal Causality (for a local history)

For every three operations write1, read, and write2 in which read and write2 are in the local history (write1 is not)

If the return value of read is a result written by write1 and read precedes write2, the object is updated by write1 and then write2

Total order

23

An example of useful compositionsAny history that is consistent with respect to Total

Order and Reads Before Writes is also consistent with respect to Local Causality

An applicationThere are several simple clients and a few

supervisor clients. Each simple client reads and writes to different objects than the other simple clients. Supervisors can read all objects

Simple clients: FIFO of Writes and Read Your Writes

Supervisors: FIFO of Reads

24

In an deal systemEach basic condition will be

implemented as a layer of code

When a given application needs a specific high-level consistency condition, it could simply pick the layers that implement the collection of basic conditions from which the high-level condition is composed of

25

Difficulties?Implementation compositions of

conditionsIn compile time?On-the-fly?

Does a complete set of basic consistency conditions to generate any consistency condition exist?

26

Conit-based CCMThe composability of consistency

conditions

Adaptability and Dependability

27

Section 7.5.1 in TvS

"Design and Evaluation of a Conit-based Continuous Consistency Model for Replicated Services." ACM Transactions on Computer Systems, by Yu and Vahdat

"On the composability of consistency conditions“ Information Processing Letters by Friedman, vitenberg, and Chockler

”The Costs and Limits of Availability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006), by Haifeng Yu, Amin Vahdat

28