DynamoDB: Basics

Sasidhar Sekar
Oct 29, 2018 · 3 min read

As the buzz around DynamoDB is getting louder and louder, more teams are looking at this with more curiosity. This post is meant to be the first in a series aimed at exploring DynamoDB in more detail.

But, before heading over to any of the more intensive topics, it is important to get accustomed to the terminologies used within the DynamoDB world. Below is a graphical representation of a DynamoDB table.

DynamoDB Table: Partition View

As can be seen in the above image:

  • Every DynamoDB Table is divided in to one or more Partitions
  • Each Partition contains a subset of the table data, in addition to any Local Secondary Indexes* created on that Partition data
  • Global Secondary Indexes are stored and maintained separately from the Partitions and they index the entire table (not specific to any one Partition)

* DynamoDB internals are not visible to public. So, the internal partition structure shown above is only an illustration intended to explain the observed behaviour

A more detailed image, showing the view within a Partition, can be found below.

DynamoDB: Attribute View (credit: http://codedevstuff.blogspot.com/2016/08/install-local-instance-of-aws-dynamodb.html)

As per the above image:

  • Each Table consists of a number of Items
  • Each Item can contain one or more Attributes
  • Every Item must contain at least one Attribute, which will be its Partition Key
  • For every CRUD operation on the table, the operation must specify the Item’s Partition Key
  • In addition to the Partition Key, a Table definition can assign any Attribute as its Sort Key
  • Read operations on the Table can specify Sort Key, for more advanced queries (“contains”, “begins with” etc.,)
  • A group of Items in table is called an Item Collection

DynamoDB is a Hosted Service. Amazon hosts all the infrastructure required to run an instance of DynamoDB for its clients. In return, the clients have to pay for the following:

  • Every read request
  • Every write request
  • Every byte of storage used

The currency for these requests are RCU (Read Capacity Units) and WCU (Write Capacity Units). In general, a DynamoDB table needs to have a certain RCU/WCU provisioned* at the time of creation (can be modified anytime later too) and the table can serve as many reads/writes as needed as long as the provisioned RCU/WCU is not exhausted.

* This is only if you are using the “Provisioned Capacity Mode”. Since Nov 2018, Amazon has introduced “On-demand Capacity Mode” for unpredictable workloads. The differentiation is out of the scope of this story. Please refer to post #3 of this series, if you are interested in learning more about the difference between “Provisioned” and “On-Demand” Capacity modes.

Thanks to Kirk Kirkconnell for pointing this out

Now, a number of these terminologies and the overall table structure itself might seem very familiar to Cassandra users. Teams, that already use Cassandra might wonder, “Why DynamoDB then?”

This will be explained in greater detail in Part 2 of this series — “Why migrate to DynamoDB from Cassandra?”

Expedia Group Technology

Stories from the Expedia Group Technology teams

Sasidhar Sekar

Written by

Expedia Group Technology

Stories from the Expedia Group Technology teams

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade