Table Plus Dynamodb
Tableplus Dynamodb Global
Tableplus Dynamodb Tutorial

Tables are a foundational element of Amazon DynamoDB. Learn the basics of working with data and tables to build high performance, easily scalable, and cloud-native applications. Nov 29, 2017 DynamoDB global tables are ideal for massively scaled applications with globally dispersed users. In such an environment, users expect very fast application performance. Global tables provide automatic multi-active replication to AWS Regions worldwide.

I’ve become a big proponent of DynamoDB over the past few years. DynamoDB provides many benefits that other databases don’t, such as a flexible pricing model, a stateless connection model that works seamlessly with serverless compute, and consistent response time even as your database scales to enormous size.

When you create a new provisioned table in Amazon DynamoDB, you must specify its provisioned throughput capacity. This is the amount of read and write activity that the table can support. DynamoDB uses this information to reserve sufficient system resources to meet your throughput requirements. DynamoDB will create the itemcount attribute, set its initial value to 0, and finally add 3 to it. The result will be a new itemcount attribute in the item, with a value of 3. If the existing data type is a set, and if the Value is also a set, then the Value is added to the existing set.

Yet data modeling with DynamoDB is tricky for those used to the relational databases that have dominated for the past few decades. There are a number of quirks around data modeling with DynamoDB, but the biggest one is the recommendation from AWS to use a single table for all of your records.

In the Create DynamoDB table screen, do the following: On the Table name box, enter ProductCatalog. For the Primary key, in the Partition key box, enter Id. Set the data type to Number. When the settings are as you want them, choose Create.

In this post, we’ll do a deep dive on the concepts behind single-table design. You’ll learn:

I recently did a live debate on this subject on Twitch with Rick Houlihan and Edin Zulich. Check out the recording here. Rick is more staunchly in the single-table camp, so be sure to watch that as well.

Let’s get started!

What is single-table design

Before we get too far, let’s define single-table design. To do this, we’ll take a quick journey through the history of databases. We’ll look at some basic modeling in relational databases, then see why you need to model differently in DynamoDB. With this, we’ll see the key reason for using single-table design.

At the end of this section, we’ll also do a quick look at some other, smaller benefits of single-table design.

Background on SQL modeling & joins

Let’s start with our good friend, the relational database.

With relational databases, you generally normalize your data by creating a table for each type of entity in your application. For example, if you’re making an e-commerce application, you’ll have one table for Customers and one table for Orders.

Each Order belongs to a certain Customer, and you use foreign keys to refer from a record in one table to a record in another. These foreign keys act as pointers — if I need more information about a Customer that placed a particular Order, I can follow the foreign key reference to retrieve items about the Customer.

To follow these pointers, the SQL language for querying relational databases has a concept of joins. Joins allow you to combine records from two or more tables at read-time.

The problem of missing joins in DynamoDB

While convenient, SQL joins are also expensive. They require scanning large portions of multiple tables in your relational database, comparing different values, and returning a result set.

DynamoDB was built for enormous, high-velocity use cases, such as the Amazon.com shopping cart. These use cases can’t tolerate the inconsistency and slowing performance of joins as a dataset scales.

DynamoDB closely guards against any operations that won’t scale, and there’s not a great way to make relational joins scale. Rather than working to make joins scale better, DynamoDB sidesteps the problem by removing the ability to use joins at all.

But as an application developer, you still need some of the benefits of relational joins. And one of the big benefits of joins is the ability to get multiple, heterogenous items from your database in a single request.

In our example above, we want to get both a Customer record and all Orders for the customer. Many developers apply relational design patterns with DynamoDB even though they don’t have the relational tools like the join operation. This means they put their items into different tables according to their type. However, since there are no joins in DynamoDB, they’ll need to make multiple, serial requests to fetch both the Orders and the Customer record.

This can become a big issue in your application. Network I/O is likely the slowest part of your application, and you’re making multiple network requests in a waterfall fashion, where one request provides data that is used for subsequent requests. As your application scales, this pattern gets slower and slower.

The solution: pre-join your data into item collections

So how do you get fast, consistent performance from DynamoDB without making multiple requests to your database? By pre-joining your data using item collections.

An item collection in DynamoDB refers to all the items in a table or index that share a partition key. In the example below, we have a DynamoDB table that contains actors and the movies in which they have played. The primary key is a composite primary key where the partition key is the actor’s name and the sort key is the movie name.

You can see there are two items for Tom Hanks — Cast Away and Toy Story. Because they have the same partition key of Tom Hanks, they are in the same item collection.

You can use DynamoDB’s Query API operation to read multiple items with the same partition key. Thus, if you need to retrieve multiple heterogenous items in a single request, you organize those items so that they are in the same item collection.

Let’s look at an example from my DynamoDB data modeling talk at AWS re:Invent 2019. This example uses an e-commerce application like we’ve been discussing, which involves Users and Orders. We have an access pattern where we want to fetch the User record and the Order records. To make this possible in a single request, we make sure all Order records live in the same item collection as the User record to which they belong.

Now when we want to fetch the User and Orders, we can do it in a single request without needing a costly join operation:

This is what single-table design is all about — tuning your table so that your access patterns can be handled with as few requests to DynamoDB as possible, ideally one.

And because everything looks better in fancy quotes, let’s say it one more time:

The main reason for using a single table in DynamoDB is to retrieve multiple, heterogenous item types using a single request.

Other benefits of single-table design

While reducing the number of requests for an access pattern is the main reason for using a single-table design with DynamoDB, there are some other benefits as well. I will discuss those briefly.

First, there is some operational overhead with each table you have in DynamoDB. Even though DynamoDB is fully-managed and pretty hands-off compared to a relational database, you still need to configure alarms, monitor metrics, etc. If you have one table with all items in it rather than eight separate tables, you reduce the number of alarms and metrics to watch.

Second, having a single table can save you money as compared to having multiple tables. With each table you have, you need to provision read and write capacity units. Often you will do some back-of-the-envelope math on the traffic you expect, bump it up by X%, and convert it to RCUs and WCUs. If you have one or two entity types in your single table that are accessed much more frequently than the others, you can hide some of the extra capacity for less-frequently accessed items in the buffer for the other items.

While these two benefits are real, they’re pretty marginal. The operations burden on DynamoDB is quite low, and the pricing will only save you a bit of money on the margins. Further, if you are using DynamoDB On-Demand pricing, you won’t save any money by going to a single-table design.

In general, when thinking about single

Tableplus Dynamodb