Consistency Models cont'

1
Consistency Models(cont.)

• Ref Tanenbaum/van Steen chpt 6

2
Outline

• Eventual Consistency
• Client-Centric Consistency Models
• Monotonic reads
• Monotonic writes
• Read your writes
• Writes follow reads
• Implementation Issues
• Replica placement
• Update propagation
• Push vs. Pull protocols
• Epidemic protocols

3
Eventual Consistency

• Models such as sequential consistency were
  developed in the context of parallel programs
  running on tightly coupled shared-memory
  multiprocessors with possibly many concurrent
  readers/writers such models are not well suited
  for distributed systems with significant
  interprocessor communication delays
• In distributed systems, much weaker forms of
  consistency, with more restrictive use patterns
  of the shared data store are often acceptable,
  e.g.,
• Only a few (or even one) possible writers of
  data, and/or
• Read-mostly data (seldom modified), and/or
• Stale data may be acceptable (e.g., web)
• Eventual consistency
• If no updates take place for a long time, all
  replicas will eventually become consistent
• Implementation Need only ensure updates
  eventually reach all of the replicated copies of
  the data
• Update propagation - come back to this later

4
Eventual Consistency Mobile Users

• Mobile users present a challenge
• Client may access replica 1, make some updates
• Client moves, accesses replica 2
• Modifications to replica 1 may not have migrated
  to replica 2 yet!

5
Client Centric Consistency

• Consistency models for accessing databases by
  mobile users
• Clients access any (typically a nearby) copy of
  the data
• Only provide consistency guarantees of data
  accesses made for individual clients (not
  concerned with ensuring consistency across
  multiple clients, e.g., ensuring all see the same
  ordering of writes)
• Assume
• Distributed data store
• Updates eventually propagated to all copies
• Assume data items have a single owner and only
  the owner can update the data
• Four consistency models
• Monotonic-reads
• Monotonic-writes
• Read-your-writes
• Writes-follow-reads

6
Notation

• Note writes do not necessarily completely
  overwrite data (may only update part of the data)
• xit version of data item X at local copy Li at
  time t
• WS(xit) set of write operations on x at
  location Li from initialization until time t
• Variable x has taken into account (at least)
  writes at Li until time t
• WS(xit1 xjt2) set of write operations on x
  at locations Li until time t1 and Lj until time
  t2
• Variable x has taken into account (at least)
  writes at Li until time t1 and writes at Lj
  until t2
• Here, in most cases omit t - clear by context

7
Monotonic Reads
Monotonic-read consistency if a process reads
the value of a data item x, any successive read
operation on x by that process will always return
that same value or a more recent one If a mobile
process sees a version x at time t, it will never
see an older version at a later time

• The read operations performed by a single process
  P at two different local copies of the same data
  store.
• A monotonic-read consistent data store
• A data store that does not provide monotonic
  reads.

8
A Simple Implementation

• Basic idea Client keeps a log of writes it has
  seen already, and makes sure each copy it reads
  is up to date
• Each write operation assigned a globally unique
  id to identify that write (and the writer)
• Each copy keeps a log of writes that have
  occurred on that copy
• Each client keeps track of a set of write
  identifiers
• Read set set of writes relevant to the reads
  done by the client
• Read operation
• Client hands its read-set to server
• Server checks writes in the read set have been
  done on this copy
• If any write has not been done yet, contact
  server that did missing write to update this copy
  before completing read operation
• Efficiency
• Logs may become large
• Can use sessions and clear log at end of each
  session

9
Monotonic Writes
A write operation performed by a process P at a
new location will operate on a copy that reflects
the results of Ps previous write
operations Monotonic-write consistency a write
operation by a process on a data item x is
completed before any successive write operation
on x by the same process Some similarity to FIFO
consistency writes propagated to all copies in
the correct order
Monotonic-write consistent data store writes x1
propagated to L2 before writes x2
Data store that does not provide monotonic-write
consistency writes x2 do not take into account
writes x1
10
Implementation

• Extend monotonic-read consistency implementation
  for each client
• Basic idea before write, make sure copy being
  updated includes results of all previous writes
• Each client keeps
• Write set set of writes this client has
  performed
• Write operation
• Client hands its write-set to server
• Server checks writes in the write set have been
  done on this copy
• If any write has not been done yet, contact
  server that did missing write to update this copy
  before completing read operation

11
Read Your Writes
Read-your-writes consistency the effect of a
write operation by a process on data item x will
always be seen by a successive read operation on
x by the same process

• A data store that provides read-your-writes
  consistency.
• A data store that does not.

12
Writes Follow Reads
Writes-follow-reads consistency a write
operation by a process on a data item x following
a previous read operation on x by the same
process is guaranteed to take place on the same
or a more recent value of x that was read Write
occurs on a copy of x that is at least as recent
as the last copy read by the process

• A writes-follow-reads consistent data store
• A data store that does not provide
  writes-follow-reads consistency

13
Replica Placement

• Where should copies be placed?
• Permanent replicas
• Mirroring sites
• Geographically placed to improve performance,
  reliability
• Server-initiated replicas (push caches)
• Copies created near clients when demand spikes
• Deleted when demand falls below threshold
• Client initiated replicas (client caches)
• Temporary cache created near client

14
Update Propagation

• What to propagate?
• Notification of update only (to invalidate cached
  copies)
• Transfer data from one copy to another (update
  protocols) - useful when data seldom modified
• Propagate update operation to other copies
  (active replication)
• Push protocols (server-based protocols)
• Propagate update to other servers w/o them asking
  for data
• Useful if high degree of consistency needed
  (caches stay in close synchrony)
• Efficient if high read-to-update ratio (seldomly
  modified data)
• Pull protocols (client-based protocols)
• Cache pulls in data as needed, e.g., web browser
  cache checks if newer version available on each
  access
• More efficient if low read-to-update ratio
  (seldom read data)
• Relatively high miss penalty

15
Pull versus Push Protocols

• A comparison between push-based and pull-based
  protocols in the case of multiple client, single
  server systems.

16
Update Propagation Epidemic Protocols

• Assume eventual consistency
• Data initially at only one server need to
  spread updates to replicas across multiple
  servers
• Servers classified as
• Infected holds update that it is willing to
  spread to other servers
• Removed updated server not willing to spread
  update
• Susceptible has not yet been updated
• Anti-entropy model each server P periodically
  picks at random server Q to exchange updates
  three approaches
• P only pushes updates to Q not very effective in
  spreading updates to many servers (some may
  remain susceptible for a long time)
• P only pulls updates from Q susceptible servers
  pull in updates
• P and Q send updates to each other
• Gossip protocols (rumor spreading)
• If P has been updated, it contacts an arbitrary
  server Q to push the update
• If Q already has the update, P becomes removed
  with probability 1/k
• Analogous to rumor spreading in real life
• Tends to work well in practice, but doesnt
  guarantee everyone updated

17
Summary

• Client-based protocols
• Try to maintain consistency from the perspective
  of individual clients
• Leave to relatively relaxed protocols, but with
  simpler implementations
• Implementation issues
• Replica placement
• Push protocols offer fast access, but may
  generate unnecessary update traffic
• Update propagation scheme needed