Intro to DynamoDB
Primary keys vs partition keys and building relationships with sort keys in DynamoDB
We explore primary keys in DynamoDB and their relation to partition keys and sort keys using the AWS console to insert items. Sort keys and uniqueness are used to introduce the concept of creating relationships between items which is what will enable us to build out single table designs in the advanced data modeling videos.
Instructor: [00:00] DynamoDB, like many other databases, has the concept of a primary key. To show this, we'll create a new DynamoDB table. I'll name it PrimaryKeyTesting.
[00:10] Where it says primary key, we have two options. We have to specify the partition key, so we'll call this PK for short. We can give it a type, which is a string, a binary or a number and we'll keep it as a string. We have the option to add a sort key as well. Since I have another table with a sort key on it, we'll leave that off for now and just explore partition keys.
[00:28] After our table is created, we can go into items and start inserting items. You'll note that we only have one attribute, PK, because we don't have any other data in this table. There's some nice help text here. It says, "When you read or write an item, the only attributes that are required are those that make up the primary key."
[00:43] We'll get back to what it means to make up the primary key later when we talk about sort keys. For now, our partition key and the primary key are the same. If we insert a partition key of A and a secondary field called data with the value of A is data and save it, we can see that a new attribute popped up and that our key with the partition key of A is here.
[01:02] If we do this a couple more times, we can see that we have three items here now, A with A is data, B with B is data and C with C is data.
[01:10] If we try to insert a value with a PK of A and we save it, we get a conditional request failed 400 code or the conditional check failed exception. This is telling us that the PK is already in the table, so we can't insert it again.
[01:23] We've seen that the primary key is unique. This table that we've created here functions very much like a key value store. There's a key that you already have to have to fetch all the data. You might be used to this pattern from a database like Redis.
[01:35] Where this gets interesting is when we switch to using a partition key and a sort key to make up the primary key. Once we introduced a sort key, both the partition key and the sort key make up the unique value. This allows us to have a partition key of A and a sort key of B, right alongside a partition key of A and a sort key of C.
[01:54] We'll dive deeper into the ramifications of what this means later when we go into advanced data modeling. Suffice it to say for now that DynamoDB has a concept of primary keys of which they can be just the partition key or a combination of the partition key and the sort key, and that the primary key is always a unique value in the table.
[02:11] Note that when we run a query, we have to specify the partition key, but we can leave off the sort key. This fairly innocuous feature is what will enable us to build complex single table adjacency lists based designs that replicate the relationship functionality of large SQL tables.