Gain insights into DynamoDB, from table creation to security and monitoring. Delve into access control and avoid common mistakes to confidently use this AWS technology.

tarball.tar.gz

region

aws_access_key_id

aws_secret_access_key

output

DynamoDB is a beautiful piece of technology. This course covers it in depth. You will learn what DynamoDB is, what it can do, and how to use it. You will learn about table creation and go into the details of security and monitoring. Additionally, you will learn how to manage access control in DynamoDB and how to monitor the usage. 

After taking this course you will become confident in using DynamoDB and will have the know-how to avoid those rookie mistakes that people make while using this technology. No matter how familiar you are with AWS technologies, this course has something for you. For the beginner, this course gives a nice flavor of AWS technologies. And for advanced practitioners, this course provides a definitive guide to DynamoDB and related technologies.

DynamoDB Deep Dive: NoSQL for Software Engineers

# 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.



Let’s learn about the primary key and range key in detail.


Primary Key and Range Key

Let’s learn about the primary key and range key in detail.

Welcome!

What is DynamoDB?

Creating Tables

Create a Table in DynamoDB

Creating Items

Create Items in a DynamoDB Table

Reading Data

Read Data in a DynamoDB Table

Secondary Index

Secondary Index in a DynamoDB Table

Monitoring

CloudWatch Monitoring for DynamoDB

Access Management

DynamoDB Best Practices

Conclusion

Instagram Stories Feature

Primary Key and Range Key

Need for primary key