A persistent Key-value store. It is proprietary to Amazon Web Services (AWS). As noted in its paper, its novelty is primarily in how it combines existing techniques to target a very different set of guarantees from most databases before it. In particular, where most databases try to prevent write conflicts by making records unavailable for write while another write is in progress, DynamoDB is designed to accept writes under all conditions. It is well-suited to situations where availability and scaling are both paramount, and consistency is relatively unimportant.
Use case
Requirements
- Extreme horizontal scaling and availability requirements
- Must remain almost perfectly available on commodity hardware
- Must be able to efficiently scale by orders of magnitude
- SLA requirements are targeted to the 99.9th percentile
- Key-value only
- Keys are unique
- Values are blobs, ideally < 1MB
- Must always be writeable
- Implies accepting new writes that conflict with still-propagating writes
Non-requirements
- Eventually consistent
- No relations
- No schemas
- No ACID guarantees
- Assumed to operate in a friendly environment
- No encryption
- No RBAC
Design
- Leaderless key-value store
- Uses consistent hashing
- It says that no redistribution is needed during scaling
- But with consistent hashing, you need to redistribute
records…?
- Uses sloppy quorums to ensure availability after permanent failures
- Uses vector clocks to identify version conflicts arising from leaderless writes
- Uses Merkle trees to efficiently uncover data changes in large ranges
- Uses a gossip protocol to discover nodes that have become non-responsive
The Dynamo paper was highly influential for many modern data stores. Riak and Voldemort follow a very similar design. Apache Cassandra was influenced by both DynamoDB and Google Bigtable.