Primary Key and Range Key

Need for primary key

Have you ever worked with a hash map? A hash map is a key-value store. Now, we do not need to know a lot about the internal workings of hash maps. But the contract it offers is simple:

• get(Key): returns the value for a given Key.
• put(Key, Value): saves the value corresponding to the Key.

To work with a hash map or any key-value store, you need a set of keys. Keys are basically used to identify an individual item in the data. This is the same reason why we need Primary Keys in DynamoDB. The primary key determines where the item will be saved and how it will be retrieved from the memory. Thus, it should be unique.

Options for primary key

As was discussed earlier, we have two options for primary keys.

1. Single key: Partition key
2. Composite key: Partition key and sort key

In the case of the composite key, the combination of the partition key and sort key should be unique.

Need for the range key

Sort key is also known as range key. Ideally, we do not need a range key. It is optional. However, it comes in handy when:

• Our partition key is not unique by itself. In this case, we can use a combination of partition key and range key as the primary key.
• Our access patterns require us to get values in some range. For example, if we have an order table partitioned on the customer_id, we may have an access pattern to get all the orders with less than $400 amount. Now to get this access pattern, if we only rely on the customer_id you will be in trouble. But if we make the amount as the sort key, we can easily get the results.

Examples

Table: Blog
Primary Key: {
    Partition Key: topic,
    Sort Key: author_datetime 
}
Item Examples:
{
    topic : "Marketing",
    author_datetime : "Godin_Seth_2015-12-21T17:42:34Z",
    title : "This is Marketing",
    views : 240000
}

{
    topic : "Productivity",
    author_datetime : "Wodehodge_PG_1976-12-05T17:42:34Z",
    title : "Purple Bear",
    likes : 5670
}

In the example shown above, we can see that the range key is the concatenation of two entities. This is a clever trick for serving more than one access pattern. You can get the following from this model:

• All posts on a given topic, by a given author.
• All posts on a given topic, by a given author, during a given time.
• All posts on a given topic.

We will discuss more access patterns in the upcoming sections.