DynamoDB is a managed NoSQL database service provided by Amazon Web Services. As it is managed by Amazon, users do not have to worry about operations such as hardware provisioning, configuration, and scaling. The offering primarily targets key-value and document storage.
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" The managed DynamoDB service was launched by AWS in January of 2012.
As DynamoDB is hosted by AWS and is a NoSQL database, users must query the database through the internet using the DynamoDB 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.
DynamoDB does not natively support views.
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.
Although there are no public implementation details on DynamoDB's internal logging schema, external users can log DynamoDB API operations via AWS CloudTrail. When enabled, AWS CloudTrail logs the DynamoDB API calls made by the user in a JSON format, then stores it in an Amazon S3 bucket.
DynamoDB does not support joins natively as it is a key-value store and not a relational database. However, Amazon's EMR (Elastic MapReduce) service supports joining DynamoDB tables.
DynamoDB uses a Key-Value storage model.
Although DynamoDB was originally not designed for transactions, AWS has subsequently published a [library](https://github.com/awslabs/dynamodb-transactions) 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, which can potentially result in phantom reads.
Although DynamoDB doesn't natively support stored procedures, users can use AWS Lambdas for a similar effect. For example, users can have Lambda functions process incoming DynamoDB stream data and have it be triggered when a specific action is performed on DynamoDB.
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 used storage engines by DynamoDB include the Berkeley Database Transactional Data Store and MySQL.
DynamoDB does not natively support foreign keys as it is not a relational database.
DynamoDB is a schemaless, NoSQL database. Each table requires a primary key to identify its corresponding data item. However, there are no such constraints on non-key attributes. DynamoDB can hold both structured or semi-structured data, such as JSON or XML.
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.](https://en.wikipedia.org/wiki/Consistent_hashing) 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.](https://en.wikipedia.org/wiki/Gossip_protocol) 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.](https://www.allthingsdistributed.com/2007/10/amazons_dynamo.html)
DynamoDB does not natively support compression. However, users can compress large attributes into binary data using compression algorithms like LZO or GZIP. These compression algorithms are available via the AWS SDK.