17. Consistency
• N, R, W
• N = number of replicas
• R = read replicas
18. Consistency
• N, R, W
• N = number of replicas
• R = read replicas
• W = write replicas
19. Consistency
• N, R, W
• N = number of replicas
• R = read replicas
• W = write replicas
• send request, wait for specified number
20. Consistency
• N, R, W
• N = number of replicas
• R = read replicas
• W = write replicas
• send request, wait for specified number
• wait for others in background and perform read-
repair
* began working on this problem last june
* complexity had grown unmanageable
* multiple internal customers
* error domain grows as data size and complexity grow
* every master db is a SPOF (failover is hard to pull off without strong coordination)
* SPOFs lead to expensive hardware
* app-managed hosts is tight coupling
* our application is already tolerant of eventual consistency (actually more tolerant...)
* in addition to scale, we want more flexibility than relational data models give us
keyspace: database
CF: table
column: attribute
SC: collection of attributes
[insert diagrams of ring + tokens]
nodes are arranged on a ring
keys are mapped to the ring and written to the next N machines
partitioners map keys to the ring
[flow chart of how updates happen]
if OPP, rows are ordered
columns are ordered
[diagram of range and slice]
insert to mysql
insert into memcache
replicate to slave
update mysql
insert into memcache fails
replication to slave fails
Launching is shifting from roll back to roll forward
