Amazon runs an e-commerce platform for millions of concurrent users, so the underlying services powering the platform must be highly reliable and scalable. Failures in infrastructure would have significant financial consequences and would degrade consumer trust in Amazon's platform. Thus, the motivating purpose behind DynamoDB was a data-store used by these services that could keep up in both availability and scalability such that infrastructure failures would not affect user experience.
The original concept and implementation of DynamoDB was first introduced in 2007 with a paper titled: "Dynamo: Amazon’s Highly Available Key-value Store". As DynamoDB is a proprietary, managed service from AWS, they have not published detailed information regarding the internals of the platform since the original paper.
The managed DynamoDB service was launched by AWS in January of 2012, with pricing being based on throughput rather than storage.
Custom API Command-line / Shell
As DynamoDB is hosted by AWS and is a NoSQL database, users must query the database through the internet using the DynamoDB (RESTful) API or SQL statements.
Users can send SQL statements over the network or use the API endpoints via the AWS Management Console, the AWS CLI, or the AWS SDKs.
Optimistic Concurrency Control (OCC)
Users have the ability to enable Optimistic Locking for DynamoDB using the AWS Java SDK. For example, they can specify a property with the annotation: @DynamoDBVersionAttribute
which is then designated to store the version number used for optimistic locking.
For conflict resolution, DynamoDB employs a "last writer wins" policy.
One of the most interesting things about DynamoDB is its system architecture which is tailored for high availability and scalability. It utilizes many novel distributed systems techniques to deliver the final product. The highlights of these techniques are outlined below:
The system is distributed across multiple nodes for availability, and it employs consistent hashing to partition data across these nodes. Read about consistent hashing on: Wikipedia.
For membership and failure detection, DynamoDB utilizes a gossip-based protocol. This allows DynamoDB to be decentralized and require minimal manual administration. Read about gossip protocol on: Wikipedia.
To handle temporary failures, DynamoDB uses a Sloppy Quorum with hinted handoff. This technique allows DynamoDB to be available and durable despite network partitions and server failures. Read about Sloppy Quorum and hinted handoff here.
Read Uncommitted Read Committed Repeatable Read
Although DynamoDB was originally not designed for transactions, AWS has subsequently published a library that supports them. With the library, DynamoDB has three configurable isolation levels for transactions: Read Uncommitted, Read Committed, and Repeatable Reads.
However, neither DynamoDB nor the library support locking for range queries, thus phantom reads can potentially result in phantom reads.
DynamoDB supports a pluggable local persistence engine that can range from in-memory buffers with persistent backing to purely disk-oriented ones. This allows it to be flexible with an application's access patterns.
Known storage engines used by DynamoDB include the Berkeley Database Transactional Data Store and MySQL.
http://aws.amazon.com/dynamodb/
https://aws.amazon.com/documentation/dynamodb/
Amazon
2012
C++, Go, JavaScript, PHP, Python, Ruby, Swift