�ݺ�ߣ

Client-Centric Consistency
Models
Bhavana Pallepati

Client-Centric Consistency Models
 The previously studied consistency models concern themselves with maintaining a
consistent (globally accessible) data-store in the presence of concurrent read/write
operations.
 Another class of distributed data store is that which is characterized by the lack of
simultaneous updates. Here, the emphasis is more on maintaining a consistent view
of things for the individual client process that is currently operating on the data-
store.

Client Centric Consistency
 In many cases concurrency appears only in restricted form.
 In many applications most processes only read data.
 Some degrees of inconsistency can be tolerate.
 In some cases if for a long time no update takes place all replicas gradually
become consistent.

Client-Centric Consistency
 Provide guarantees about ordering of operations only for a single client, i.e.
 Effects of an operations depend on the client performing it
 Effects also depend on the history of client’s operations
 Applied only when requested by the client
 No guarantees concerning concurrent accesses by different clients
 Assumption:
 Clients can access different replicas, e.g. mobile users

Eventual Consistency
- Eventual consistency for replicated data is fine if clients always access the same replica. Client centric
consistency provides consistency guarantees for a single client with respect to the data stored by that client

Client-Centric Consistency Models
Clients access distributed data store using, generally, the local copy. Updates are
eventually propagated to other copies.
a) Monotonic read
b) Monotonic write
c) Read your writes
d) Writes follow reads

Monotonic Reading
 Definition: A DDS provides monotonic-read consistency if the following holds:
 If process P reads the value of data item x, any successive read operation on x by
that process will always return the same value or a more recent one
(independently of the replica at location L where this new read will be done).

Example Systems
 Distributed e-mail database with distributed and replicated user-mailboxes.
 Emails can be inserted at any location.
 However, updates are propagated in a lazy (i.e. on demand) fashion.

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

Monotonic Writing
 Definition: DDS provides monotonic-write consistency if the following holds:
 A write operation by process P on data item x is completed before any
successive write operation on x by the same process P can take place.
 Remark: Monotonic-writing ~ FIFO consistency
 Only applies to writes from one client process P
 Different clients -not requiring monotonic writing may see the writes of
process P in any order

Example
 The write operations performed by a single process P at two different local copies of the
same data store
a) A monotonic-write consistent data store.
b) A data store that does not provide monotonic-write consistency.

Reading Your Writes
 Definition: DDS provides “read your write” consistency if the
following holds:
 The effect of a write operation by a process P on a data item x at
a location L will always be seen by a successive read operation
by the same process.
 Example of a missing read-your-write consistency:
 Updating a website with an editor, if you want to view your
updated website, you have to refresh it, otherwise the browser
uses the old cached website content.
 Updating passwords

Example
a) A data store that provides read-your-writes consistency.
b) A data store that does not.

Writes Following Reads
 Definition: DDS provides “ writes-follow-reads” consistency if the following
holds:
 A write operation by a process P on a data item x following a previous read
by the same process, is guaranteed to take place on the same or even a more
recent value of x, than the one having been read before.

Example
a) A writes-follow-reads consistent data store
b) A data store that does not provide writes-follow-reads consistency

Implementing Client Centric Consistency
 Naive Implementation (ignoring performance):
 Each write gets a globally unique identifier
 Identifier is assigned by the server that accepts this write operation for the
first time
 For each client two sets of write identifiers are maintained:
 Read-set(client C) := RS(C)
 {write-IDs relevant for the reads of this client C}
 Write-set(client C) := WS(C)
 {write-IDs having been performed by client C}

Implementing Monotonic Reads
When a client C performs a read at server S, that server is handed the client’s
read set RS(C) to control whether all identified writes have taken place locally
at server S. If not, server has to be updated before reading!

Implementing Monotonic Write
 If client initiates a write on a server S, this server S gets the clients write-set in
order to update server S. A write on this server is done according to the times
stamped WID.
 Having done the new write, client’s write-set is updated with this new write. The
response time of a client might thus increase with an ever increasing write-set.
 However, what to do if all the reader write-sets of a client get larger and larger?

Improving Efficiency with RS and WS
 Major drawback: potential sizes of read- and write sets 
 Group all write- and read-operations of a client in a so called session (mostly
assigned with an application)
 Every time a client closes its current session, all updates are propagated and
these sets are deleted afterwards

Summary on Consistency Models
 Choosing the right consistency model requires an analysis of the following trade-
offs:
 Consistency and redundancy
 All replicas must be consistent
 All replicas must contain full state
 Reduced consistency  reduced reliability
 Consistency and performance
 Consistency requires extra work
 Consistency requires extra communication
 May result in loss of overall performance

�ݺ�ߣ

Client Centric Consistency Model

More Related Content

Client Centric Consistency Model