Partitions

A logical unit

A DynamoDB node is divided into multiple logical units referred to as Partition

Your table data is sharded across multiple partitions hosted across multiple nodes. In effect a node may host shard for multiple tables. Each of thes partition in a node has a fixed maximum capacity in terms of compute, IO and storage. As a result a single partition cannot hog resources and starve (impact) other partitions on the node. AWS ensures that node is sized sufficeintly to cater to the needs of all partitions operating at an optimal level.

Users don’t have to deal with this aspect directly.

DDB Nodes

A single partition hosts a single shard of the table. Each of the partitions for the table is replicated across 3 Availability Zones for high durability and availability. Illustration below depicts a single table with data across 2 partitions; each partition replicated across 3 AZ.

Replication

Each of the partition may be thaught of as Hashtable like data structure that hosts multiple key-value pairs. These key-value pairs belong to a single table shard. The Key is referred to as the Partition key. Value may be a single item or an Item collection. In this illustration value is an item collection. Each item collection may be thought of as a Hashtable like data structure. Items in the collection are identified by an inner key that is referred to as the Sort key or Range key.

Replication

Note: A table MUST be defined with a Partition key and Sort key for a table is optional. More on this topic later.

An item write to the table requires a combination of Partition key and Sort key. DynamoDB on receiving the write request calculates the HASH for the partition key to determine the partition for storing the item. DynamoDB service attempts to uniformly distribute the partition keys across the table partitions.

Replication

The size of each item is restricted to a maximum size of 400 KB. The maximum amount of data stored in the partition is restricted to 10 GB. As the size of the table grows, DynamoDB service adds more partitions to the table. This scale-up process is transparent to the user. With this zero-impact scaling up mechanism your table can grow in size to even Petabytes.