---

Amazon DynamoDB Functionality

To Use Amazon DynamoDB you simply:

• Use the AWS Management Console or the Amazon DynamoDB APIs to create a table and specify your required request capacity.
• Use the Amazon DynamoDB APIs to write and retrieve data.
• Monitor the status and performance of your Amazon DynamoDB tables using Amazon CloudWatch in the AWS Management Console .
• Pay for what you use. Your monthly bill is based on the provisioned request capacity of your table and the amount of data stored.

---

Service Highlights

Scalable – Amazon DynamoDB is designed for seamless throughput and storage scaling.

• Provisioned Throughput – When creating a table, simply specify how much request capacity you require. DynamoDB allocates dedicated resources to your table to meet your performance requirements, and automatically partitions data over a sufficient number of servers to meet your request capacity. If your throughput requirements change, simply update your table's request capacity using the AWS Management Console or the Amazon DynamoDB APIs. You are still able to achieve your prior throughput levels while scaling is underway.
• Automated Storage Scaling – There is no limit to the amount of data you can store in a DynamoDB table, and the service automatically allocates more storage, as you store more data using the DynamoDB write APIs.
• Fully Distributed, Shared Nothing Architecture – Amazon DynamoDB scales horizontally and can seamlessly scale a single table over hundreds of servers.

Fast, Predictable Performance – Average service-side latencies for Amazon DynamoDB are typically single-digit milliseconds. The service runs on solid state drives, and is built to maintain consistent, fast latencies at any scale.

Easy Administration – Amazon DynamoDB is a fully managed service – you simply create a database table and let the service handle the rest. You don’t need to worry about hardware or software provisioning, setup and configuration, software patching, operating a reliable, distributed database cluster, or partitioning data over multiple instances as you scale.

Built-in Fault Tolerance – Amazon DynamoDB has built-in fault tolerance, automatically and synchronously replicating your data across multiple Availability Zones in a Region for high availability and to help protect your data against individual machine, or even facility failures.

Flexible – Amazon DynamoDB does not have a fixed schema. Instead, each data item may have a different number of attributes. Multiple data types (strings, numbers, and sets) add richness to the data model.

Strong Consistency, Atomic Counters – Unlike many non-relational databases, Amazon DynamoDB makes development easier by allowing you to use strong consistency on reads to ensure you are always reading the latest values. Amazon DynamoDB supports multiple native data types (numbers, strings, and multi-valued attributes). The service also natively supports Atomic Counters, allowing you to atomically increment or decrement numerical attributes with a single API call.

Cost Effective – Amazon DynamoDB is designed to be extremely cost-efficient for workloads of any scale. You can get started with a free tier that allows more than 40 million database operations per month, and pay low hourly rates only for the resources you consume above that limit. With easy administration and efficient request pricing, DynamoDB, can offer significantly lower total cost of ownership (TCO) for your workload compared to operating a relational or non-relational database on your own.

Secure – Amazon DynamoDB uses proven cryptographic methods to authenticate users and prevent unauthorized data access. It also integrates with AWS Identity and Access Management (IAM) for fine-grained access control for users within your organization.

Integrated Monitoring – Amazon DynamoDB displays key operational metrics for your table in the AWS Management Console. The service also integrates with Amazon CloudWatch so you can see your request throughput and latency for each Amazon DynamoDB table, and easily track your resource consumption.

Elastic MapReduce Integration – Amazon DynamoDB also integrates with Amazon Elastic MapReduce (Amazon EMR). Amazon EMR allows businesses to perform complex analytics of their large datasets using a hosted pay-as-you-go Hadoop framework on AWS. With the launch of Amazon DynamoDB, it is easy for customers to use Amazon EMR to analyze datasets stored in DynamoDB and archive the results in Amazon Simple Storage Service (Amazon S3), while keeping the original dataset in DynamoDB intact. Businesses can also use Amazon EMR to access data in multiple stores (i.e. Amazon DynamoDB, Amazon RDS, and Amazon S3), do complex analysis over this combined dataset, and store the results of this work in Amazon S3.

---

Pricing

---

When Should I Use DynamoDB?

When should I use Amazon DynamoDB vs. a relational database engine?

Today’s web-based applications generate and consume massive amounts of data. For example, an online game might start out with only a few thousand users and a light database workload consisting of 10 writes per second and 50 reads per second. However, if the game becomes successful, it may rapidly grow to millions of users and generate tens (or even hundreds) of thousands of writes and reads per second. It may also create terabytes of data per day. Developing your applications against Amazon DynamoDB enables you to start small and simply dial-up your request capacity for a table as your requirements scale, without incurring downtime or having to write or change a single line of code. Amazon DynamoDB provides a fully managed experience at any scale.

While Amazon DynamoDB tackles the core problems of database scalability, management, performance, and reliability, it is not a relational database and does not support complex relational queries (e.g. joins) or complex transactions. If your workload requires this functionality, or you are looking for compatibility with an existing relational engine, try Amazon Relational Database Service (RDS). You can also run your own relational database on Amazon EC2. While relational database engines provide rich features and functionality, workloads with scaling needs may require you to manage the partitioning and re-partitioning of your data over multiple instances. This can be a complex undertaking. As such, if you anticipate significant scaling requirements for your new application and do not need relational features, Amazon DynamoDB will be a better fit for you.

Please visit the Running Databases on AWS page for more information on the various database alternatives for your applications.

How does Amazon DynamoDB differ from Amazon SimpleDB? Which should I use?

Both services are non-relational databases that remove the work of database administration. Amazon DynamoDB focuses on providing seamless scalability and fast, predictable performance. Amazon DynamoDB automatically manages the spreading of your data and workload over a sufficient number of servers to meet your scaling requirements. There is no limit on the amount of data you can store in an Amazon DynamoDB table and you can grow the request capacity to the level that you need. On the other hand, Amazon SimpleDB is a good fit for lower-scale workloads that require query flexibility. Amazon SimpleDB automatically indexes all item attributes and supports greater query functionality than Amazon DynamoDB. However, a table in Amazon SimpleDB has a size limit of 10 GB and is limited in the request capacity it can achieve. You can manually partition your data over additional SimpleDB tables if you need additional scale. Amazon CTO Werner Vogels' DynamoDB blog post provides additional context on the evolution of non-relational database technology at Amazon.

---

Detailed Description

Data Model – Attributes, Items, and Tables

Amazon DynamoDB organizes data into tables containing items, and each item has one or more attributes.

Attributes

An attribute is a name-value pair. The name must be a string, but the value can be a string, number, string set, or number set. The following are all examples of attributes:

        "ImageID" = 1
        "Title" = "flower"
        "Tags" = "flower", "jasmine", "white"
        "Ratings" = 3, 4, 2
    

Item

A collection of attributes forms an item, and the item is identified by its primary key. An item's attributes are a collection of name-value pairs, in any order. The item attributes can be sparse, unrelated to the attributes of another item in the same table, and are optional (except for the primary key attribute). Unlike traditional databases, the table has no schema other than its reliance on the primary key. Items are stored in a table. To put items into a table, you must designate at least one of the attributes as the primary key. The primary key uniquely identifies an item for a DynamoDB table. In the following diagram, the ImageID is the attribute designated as the primary key:

Notice that the table has a name, "my table", but the item does not have a name. The primary key defines the item; the item with primary key "ImageID"=1.

Tables

Tables contain items, and organize information into discrete areas. All items in the table have the same primary key scheme. You designate the attribute name (or names) to use for the primary key when you create a table, and the table requires each item in the table to have a unique primary key value. The first step in writing data to DynamoDB is to create a table and designate a table name with a primary key. The following is a larger table that also uses the ImageID as the primary key to identify items.

Table: My Images
Primary Key	Other Attributes
ImageID = 1	ImageLocation = https://s3.amazonaws.com/bucket/img_1.jpg	Date = 1260653179	Title = flower	Tags = Flower, Jasmine	Width = 1024	Depth = 768
ImageID = 2	ImageLocation = https://s3.amazonaws.com/bucket/img_2.jpg	Date = 1252617979	Rated = 3, 4, 2	Tags = Work, Seattle, Office	Width = 1024	Depth = 768
ImageID = 3	ImageLocation = https://s3.amazonaws.com/bucket/img_3.jpg	Date = 1285277179	Price = 10.25	Tags = Seattle, Grocery, Store	Author = you	Camera = phone
ImageID = 4	ImageLocation = https://s3.amazonaws.com/bucket/img_4.jpg	Date = 1282598779	Title = Hawaii	Author = Joe	Colors = orange, blue, yellow	Tags = beach, blanket, ball

Access Model and API Overview

Primary Key

DynamoDB requires that each table have a defined primary key that is used for accessing data. The primary key identifies each item uniquely (such as ID =1, ID = 2, ID = 3, etc.). The primary key is the only part of the table that is indexed, and it is also used to hash partition your data across multiple servers. You specify the primary key when you create a table.

In other words, each item is a collection of name/value pairs. When you create a table of items, you designate a name/value pair as the primary key. All items in the table must have a value for the primary key attribute and Amazon DynamoDB ensures that the value for that name is unique. An index is created based on the primary key.

Composite Primary Key for Range Queries

A composite primary key enables you to specify two attributes in a table that collectively form a unique primary index. All items in the table must have both attributes. One serves as a “hash partition attribute” and the other as a “range attribute.” For example, you might have a “Status Updates” table with a composite primary key composed of “UserID” (hash attribute, used to partition the workload across multiple servers) and a “Time” (range attribute). You could then run a query to fetch either: 1) a particular item uniquely identified by the combination of UserID and Time values; 2) all of the items for a particular hash “bucket” – in this case UserID; or 3) all of the items for a particular UserID within a particular time range. Range queries against “Time” are only supported when the UserID hash bucket is specified.

DynamoDB APIs

• CreateTable – Creates a table and specifies the primary index used for data access.
• UpdateTable – Updates the provisioned throughput values for the given table.
• DeleteTable – Deletes a table.
• DescribeTable – Returns table size, status, and index information.
• PutItem – Creates a new item, or replaces an old item with a new item (including all the attributes). If an item already exists in the specified table with the same primary key, the new item completely replaces the existing item. You can also use conditional operators to replace an item only if its attribute values match certain conditions, or to insert a new item only if that item doesn’t already exist.
• BatchWriteItem – Inserts, replaces, and deletes multiple items across multiple tables in a single request, but not as a single transaction. Supports batches of up to 25 items to Put or Delete, with a maximum total request size of 1 MB.
• UpdateItem – Edits an existing item's attributes. You can also use conditional operators to perform an update only if the item’s attribute values match certain conditions.
• DeleteItem – Deletes a single item in a table by primary key. You can also use conditional operators to perform a delete an item only if the item’s attribute values match certain conditions.
• GetItem – The GetItem operation returns a set of Attributes for an item that matches the primary key. The GetItem operation provides an eventually consistent read by default. If eventually consistent reads are not acceptable for your application, use ConsistentRead.
• BatchGetItem – The BatchGetItem operation returns the attributes for multiple items from multiple tables using their primary keys. A single response has a size limit of 1 MB and returns a maximum of 100 items.
• Query – Gets one or more items based on their primary key and, supports both eventual consistent and strong consistency. This API is used in tables that have a composite hash-range key
• Scan – Gets one or more items and attributes by performing a full scan across the table. The items returned may be limited by your specifying filters against one or more attributes. This API can thus be used to enable ad-hoc querying of a table against attributes which are not the table’s primary key. However, since it is a full table scan without an index, it should not be used for any application query use case that requires predictable performance. The result set of a scan API request will be eventually consistent. You can think of the Scan API as an iterator. Once the aggregate size of items scanned for a given Scan API request exceeds a 1 MB limit, the given request will terminate and fetched results will be returned along with a LastEvaluatedKey (to continue the scan in a subsequent operation).

Amazon Elastic MapReduce Integration

Amazon DynamoDB also integrates with Amazon Elastic MapReduce (Amazon EMR). Amazon EMR allows businesses to perform complex analytics on their large datasets using a hosted pay-as-you-go Hadoop framework on AWS. Some of the ways in which EMR can be used with DynamoDB are as follows:

1. Customers can analyze data stored in DynamoDB using EMR and store the results of the analysis in S3 while leaving the original data in DynamoDB.

   For example, if you’re using Amazon DynamoDB to store customer orders, you could create a new order table every month and using EMR’s multi-table query capability, you could join different tables in DynamoDB to answer questions such as “what orders were placed by a specific customer in the past 3 months?” You can then use EMR to store the results of these questions in S3 for later retrieval while keeping the data in the monthly customer order tables intact in DynamoDB.

2. Customers can back up the data from DynamoDB to S3 using EMR.

   Using our earlier example about customer orders, once you’re no longer actively writing to a monthly order table, you can back up this table to S3 and delete this table from DynamoDB to take advantage of S3's lower storage costs. The data stored in S3 is still easily available for analysis as described below.

3. Customers can also use Amazon EMR to access data in multiple stores (i.e. Amazon DynamoDB, Amazon RDS, and Amazon S3), do complex analysis over this combined dataset, and store the results of this work in Amazon S3.

   For example, if you’re using Amazon DynamoDB to store customer orders, you could create a new order table every month and, at the end of each month, archive orders over 6 months old in Amazon S3 using Amazon EMR. This enables you to archive your rarely accessed orders in Amazon S3 to reduce cost and keep only the frequently accessed orders in DynamoDB. You can use EMR to perform analytics that span your current orders stored in DynamoDB and your archived order tables stored in Amazon S3 to answer queries such as “How many orders for widget X has customer Y placed in the last 48 months?”

Getting Started

To get started with Amazon DynamoDB, you can work through our Getting Started Guide.

---

Intended Usage and Restrictions

Your use of this service is subject to the Amazon Web Services Customer Agreement.