Answers(2) - Name Madhubabu Sandara CSE 586 Assignment 5 Q2...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
Name: Madhubabu Sandara Date: 3/31/2010 CSE 586 - Assignment 5 Q2. Review - Eventual Consistency Amazon’s CTO posted to try to make Eventual Consistency and its tradeoffs more clearly for all. He lays a lot of good theoretical groundwork that boils down to explaining that there are tradeoffs and you can’t have it all. Eventually, you have to keep multiple copies of the data to scale. Once that happens, it becomes harder and harder to maintain consistency and still scale. As Werner points out, session consistency is good enough for many web applications. When I make a change to the database, I should see it on subsequent reads, but anyone else who looks often does not need to see the latest value right away. Session consistency also has the advantage of being easy to implement. As long as a client reads and writes from the same replica in the cluster for the duration of the session, you have session consistency. In the event that node goes down, you terminate the session and force the client to start a new session on a replica that is up. Werner did not talk about it, but some implementations of session consistency can cause headaches if a lot of clients doing updates to the same data where they care what the previous values were. The simplest example is a counter where two clients with sessions on different replicas both try to increment a value i and end up with i+1 in the database rather than i+2. However, there are ways to deal with this kind of data. For example, just for the data that needs it, we can use multi- versioning while sending writes to all replicas or forcing all read-write sessions to the same replica. Moreover, a surprising vast amount of application data does not have this issue because there is only one writer, there are only inserts and deletes not updates, or the updates do not depend on previous values. The author provides a full taxonomy of concepts (i.e. Monotonic Write Consistency et al) with which to think about all this and evaluate the trade offs. He also does a good job pointing out how often even conventional RDMS’s wind up dealing with inconsistency. Some of the best examples include the idea that your mechanism for backups is often not fully consistent. The right answer for many systems is to require that writes always work, but that reads are only eventually consistent. Q3. Review - How to Build a Highly Available System Using Consensus The author in his paper explains that Fault-tolerant consensus is expensive. Adding a timeout to an exclusive lock makes a fault-tolerant lock or ‘lease’. A process holds a lease on a state component or ‘resource’ until an expiration time; then the process is the ‘master’ for the resource until it holds the lease. No other process will touch the resource until the lease expires. A process can keep control of a resource by renewing its lease before it expires. A lease is most often used to give
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 05/02/2010 for the course CSE 121 taught by Professor Staff during the Fall '08 term at UCSD.

Page1 / 3

Answers(2) - Name Madhubabu Sandara CSE 586 Assignment 5 Q2...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online