Rethinking Dynamo: Amazon’s Highly Available Key-value Store --An Offense Shih-Chi Chen Hongyu Gao

Dynamo’s goal: To provide a large scale key-value storage with desired levels of availability and performance, and to be able to handle server failures, data center failures and network partitions.

One sentence summary Dynamo is a project with a good goal, but questionable design and incomplete experiments.

Assumption issues The environment is assumed to be non- hostile – dangerous assumption As a commercial system that requires extreme reliability, always be prepared for the case when some of the servers are compromised

Performance issues Consistent hash based data partitioning and replication The assignment of the servers is random Fail to assign servers with “good” performance to each client

Performance issues 99.9% percentile write latency without buffering (fig. 4 and fig. 5). Why are latency different?

Interface issues get() and put() operations No delete() ?! What kind of storage system is that …

Interface issues Rely on the application to resolve the inconsistency Increase the burden on the application developers Don’t push your fault to others!

Interface issues The so-called “main advantage” – the knob (R,W,N) How are the application developers suppose to know the best value of R,W and N?

Scalability issues Typical configuration deployed for majority of the services: 30 nodes Do some scalability test, even with synthetic applications!

Availability issues What does it mean by “highly available”? Without thorough experiment, a system cannot be claimed as “highly available” Amazon S3 outage example – too many authentication paralyzes the server

Others Will the information of changing membership be lost? How can you reconcile the membership information. How can you present the shopping cart information before they are reconciled? Wouldn’t customers get angry over wrong shopping list configuration?

The end Thanks!