Download presentation
Presentation is loading. Please wait.
1
CLIENT-CENTRIC CONSISTENCY MODELS
Muluken Gebremariam CSc 8320 Advanced Operating Systém Chapter 7.3 Instructor: Dr. Yanqing Zhang
2
Contents Sequential Consistency Client–Centric Consistency
2.1 Eventual Consistency 2.2 Monotonic Read Consistency 2.3 Monotonic Write Consistency 2.4 Read-your-writes Consistency 2.5 Writes-follows-reads Consistency Consistency in Current Databases Consistency for Future Databases
3
1. Sequential Consistency
Previous consistency models provide a system wide consistent view on a data store. Assumption concurrent processes may be simultaneously updating the data store Processes get Copy of the object that reflects all changes Mutual exclusive access Strength Highly Consistent Weakness Sequential consistency Performance
4
2. Client–Centric Consistency
In distributed systems, maintaining sequential consistency in order to control the concurrent operations is essential. In some special data stores without simultaneous updates, client-centric consistency models can deal with inconsistencies in a less costly way. The following models are some client-centric consistency models: Eventual Consistency Monotonic Read Consistency Monotonic Write Consistency Read-your-writes Consistency Writes-follows-reads Consistency
5
2.1 Eventual Consistency Special class of distributed data stores.
System characteristics Lack of simultaneous updates, or when such updates happen, they can easily be resolved. Most operations involve reading data. Protocol Weak consistency model. Hide inconsistencies in a cheap way.
6
2.2 Eventual Consistency In many database systems most processes only read data from the database. Only one, or very few processes perform update operations. Such distributed and replicated databases tolerate a relatively high degree of inconsistency. If no updates take place for a long time, all replicas will gradually become consistent. Essentially requires only that updates are guaranteed to propagate to all replicas.
7
2.2 Eventual Consistency DNS World Wide Web
Name space is partitioned into domains, where each domain is assigned to a naming authority. Only that authority is allowed to update its part of the name space. No write-write conflicts. Only read-write conflicts. Lazy update propagation is acceptable World Wide Web Web pages are updated by a single authority No write-write conflicts to resolve. Browsers and Web proxies locally cache a fetched pages. They may return out-of-date Web pages. Inconsistency is acceptable (to a certain degree).
8
2.2 Monotonic Reads 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 value. Time never moves backwards. Example Distributed e- mail database. Mail can be inserted in a mailbox at any location. Suppose a user reads his mail in San Francisco. When the user later flies to New York and opens his mailbox again, the messages that were in the mailbox in San Francisco will also be in the mailbox when it is opened in New York.
10
2.3 Monotonic Writes A write operation by a process on a data item X is completed before any successive write operation on X by the same process. Strong: Write operations by the same process are performed in the same order as they are initiated. Weak: The effects of a write operation are seen only if all preceding writes have been carried out as well. For commutative write operations
12
2.4 Read Your Writes 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. Example Updating web documents and subsequently viewing the effects. The browser or the server returns the cached copy. Integrate the editor and browser into a single program, the cache is invalidated when the page is updated, so that the updated file is fetched and displayed.
13
2.2 Eventual Consistency
15
2.5 Writes Follow Reads 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. Example Writes-follow-reads consistency can be used to guarantee that users of a network group see a posting of a reaction to an article only after they have seen the original article. A user first reads an article A. Then, he reacts by posting a response B. By requiring writes-follow-reads consistency, B will be written to any copy of the newsgroup only after A has been written as well.
17
3. Consistency in Current Databases
MongoDB From the point of view of client applications, whether a MongoDB instance is running as a single server or a replica set is transparent, read operations to a replica set by default return results from the primary, and are consistent with the last write operation. Riak Allows reads and writes with three different parameters: (N) for nodes, (W) for writes, and (R) for reads. N represents the number of nodes where data will be replicated. W is the number of nodes that must be written successfully before a response is returned. R is the number of nodes from which data must be read in order to reply to a request.
18
3. Consistency in Current Databases
Amazon SimpleDB's Eventual consistency model. New feature : Consistent read Only guarantees that reads reflects the complete set of batch updates, or none of those updates. Amazon DynamoDB Eventually consistent by default. Offers an option to request the latest version of the data. Strongly consistent read
19
3. Consistency in Current Databases
Microsoft Azure: Cosmos DB Provides five consistency levels: Strong, bounded-staleness, session, consistent prefix, and eventual. CouchDB Eventually consistent. Incremental replication: periodically copying of document among servers Automatic conflict detection and resolution The winning version is saved as the most recent version The losing version is saved this as a previous version
20
4. Consistency for Future Databases
Choose strong consistency (conventional SQL) at the cost of scale Chose eventual consistency (NoSQL) and get enhanced scale at the cost of consistency across nodes. Developers spend a significant fraction of their time building extremely complex and error-prone mechanisms to cope with eventual consistency and handle data that may be out of date. Developers should not have to deal with eventual consistency. Vendors should stop hiding behind the CAP theorem as a justification for eventual consistency.
21
4. Consistency for Future Databases
22
4. Consistency for Future Databases
New distributed, consistent systems like Google Spanner concretely demonstrate the falsity of a trade-off between strong consistency and high availability. Google’s Cloud Spanner and CockroachDB were both successful in providing horizontal scale without sacrificing strong consistency. With Cosmos DB, Microsoft offers multiple consistency models in the same database, so the choice of model can be a function of the workload rather than the product.
23
4. Consistency for Future Databases
Instead of compromising performance or consistency, investment needs to be made to make database software scale while preserving consistency. The next generation of commercial distributed databases rather than accepting weak eventual consistency, they will adopt far stronger models like ACID transactions or strong eventual consistency, making them more powerful and productive tools in the enterprise. But they will not be easy to build.
24
References [1] Andrew S. Tanenbaum and Maarten Van Steen. Distributed Systems Principles And Paradigms, pp , CreateSpace Independent Publishing Platform; 2 edition ,February 26, 2016 [2] Mawahib Musa Elbushra, Jan Lindström: Eventual Consistent Databases: State of the Art, OJDB 2014, 1(1), Pages 26-41, 2014, [3] MongoDB: Agile and Scalable. [3] Anderson, C. J., Lehnardt, J., and Slater, N.: CouchDB: The Definitive Guide. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA January 2010, First Edition [4] Amazon SimpleDB, [5] DynamoDB, [6] Sivasubramanian, S.: Amazon DynamoDB: a seamlessly scalable non-relational database service. In proceeding SIGMOD International Conference on Management of Data, ACM New York, NY, USA, 2012, pp [7] Riak, [8] Zigmars Raascevskis. The future of cloud computing , September 11, 2015 [9] Serdar Yegulalp. Why Microsoft's Cosmos DB represents the future of cloud databases, the-future-of-cloud-databases.html , InfoWorld | MAY 11, 2017 [10] Wikipedia. Consistency model,
25
Thank you!
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.