Creating the DynamoDB table using the console

Now that we have signed up for AWS, let's start by creating our first DynamoDB table using the DynamoDB console.

Getting ready

To perform this recipe, you need to have completed the earlier recipe of Signing up to the DynamoDB AWS console.

How to do it…

Let's create our first DynamoDB table. The steps are as follows:

1. Sign in to the AWS Console by providing valid account details, and go to the DynamoDB console, as shown in the previous recipe. You will see the following screen:
   
2. Click on the Create Table button. This will open a popup window where you will need to provide details, such as the Table Name, Primary Key, their data types, and so on. Here, we need to create a table called a product table, which will save the products-related data for all the e-commerce websites.

   Here, we will create a table with the Primary Key Type as the Hash and Range composite keys. We will have the hash key as the product id and range key as the product type. Add the details, as shown in the following screenshot, and click on Continue:

   
3. In the next screen, you need to add Global/Local Secondary Indexes. Here, we would like to query DynamoDB items with their name and manufacturer. So, we create an index, and click on the Add Index to Table button, as shown in the following screenshot. Once done, click on Continue to proceed with the next configuration:
   

   Here, we are also selecting Projected Attributes as All Attributes, as we would like DynamoDB to give us all the attributes back when we query it. Alternatively, if you know exactly what attributes you need to be projected into this secondary index, you can select Specify Attributes, in the Projected Attributes dropdown, and add the specific attributes you want to be projected.

4. Provide Read Capacity Units and Write Capacity Units, depending on the reads and writes load you are expecting. Here, I am providing the value 5 for Read Capacity Units and 5 for Write Capacity Units, as shown in the following screenshot. Click on the Continue button to proceed. A read capacity unit is a strong consistent read per second for items as large as 4 KB, while a write capacity unit is a strong consistent write per second for items as large as 1 KB:
   
5. The next screen will be all about setting up the throughput alarms. Here, you can select the checkbox for when you wish to get alarms in case your throughput reaches capacity. This is an optional configuration, so you may wish to skip it. Click on Continue to move to the next step.
6. The last step is to review the summary. If you are okay with the configurations, then click on Create to actually create the DynamoDB table. If you think that there are some configurations that are missing, then you may wish to go back and change those.
7. The newly created DynamoDB table may take some time to get active; in the meantime, you will see Status as Creating on the screen.
8. Lastly, you will see that the table is created and is in the ACTIVE state:
   

How it works…

In DynamoDB, we don't need to bother about the availability, scalability, and reliability of the table as it is completely owned by Amazon. We just need to create a table and start using it. We can modify the throughput units any time using the same console. This gives us the flexibility to control the reads and writes of the data from DynamoDB. For example, if you think that there is a certain period where you would be expecting more reads/writes, then you can increase the throughput values and vice versa. You can find out how AWS calculates the read and write throughput at

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughputIntro.html.

Choosing a right key is very important in order to balance the load on DynamoDB partitions. The hash key should be chosen in such a way that it has unique values in it so that the data can be distributed across the cluster. The range key should be chosen in such a way that items can be grouped together so that if you have any such queries, they will perform faster. This is why we have chosen the product id as the Hash Key attribute, while the product type as the Range Key attribute.

The same is the case with Global Secondary Indexes. The Global secondary indexes allow us to query items on non-primary key attributes. Here, we may want to query items on their names or group them by the manufacturer.

DynamoDB supports various data types for its attributes, which are as follows:

• Scalar: Number, String, Binary, Boolean, and Null
• Multi-valued: String Set, Number Set, and Binary Set
• Document: List and Map

You can choose which suites you best.

There's more…

Here, you might have noticed that instead of putting the manufacturer's name as a proper name to the range key in the Global Secondary Index, I chose to use its short form as mnfr. The reason for this is that when it comes to key-value pair types of databases, the entries stored in the database are always both keys and values together. So, every time you add an item or an attribute, it will be saved as key=value in the database. So, it's the best practice to use short yet meaningful names for keys and attributes. We will discuss such best practices in Chapter 7, DynamoDB Best Practices.