These are notes taken during CMSC 818e: Distributed And Cloud-Based Storage Systems. Course webpage and syllabus here.

Day Eight

• Strong consistency means R+W > N (a strict quorum system) - the read and write quorums overlap
• Partial consistency otherwise
  • assumes that applications can tolerate some staleness
• staleness in terms of time and staleness in terms of replicas
  • a read is k-regular if it returns the result of one of the K most recent writes
  • system provides (K, p)-regular semantics if each read is K-regular w/ prob
  • a read is delta-regular if it returns the result of the last write as of up to delta time units ago
  • system provides (delta, p)-regular semantics if each read is delta-regular w/ prob p
• PBS: Probabilistically Bounded Staleness link
• Bolt-on consistency: enforce causal consistency across systems that only support eventual consistency using a shim layer
  • motivated by a need for stronger consistency, lower latency (tolerance for staleness)
  • Write path: client write performed in local store, send to ECDS w/ metadata
  • Read path (causal): Client read satisfied by local store (might result in staleness)
  • Read path (pessimistic): synchronous checking on data, and dependencies, in the ECDS, rather than replying on async resolve process to do this for us (read latency is seriously impacted by this)
• HAT: Highly available transactions
• causal consistency is the strongest consistency you can guarantee in the face of partitions
• differentiate between potential and explicit causality. Potential causality is what we usually think of, and which they do not consider further (because the possible dependency trees would get too bushy)
• Dynamo, Cassandra etc now provide an extra layer that supports causal consistency.