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 monotonic-read consistent data store 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 monotonic-write consistent data store. 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 data store that provides read-your-writes consistency. 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 writes-follow-reads consistent data store 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

Thank You