Database Reference
In-Depth Information
Efficient use of primary keys
As DynamoDB is a NoSQL database and is used with scalable applications, table data
might grow exponentially. This might reduce data read and write throughput (the number
of 1 KB read or write requests per second) if not managed efficiently. This management
starts right from choosing the correct primary key and its parameters. Take a look at the fol-
lowing table:
As soon as the table is created, the table data is partitioned on the hash key attribute. What
this means is that if the table has three partitions, then the first two items will go to the first
partition, the third item will go to the second partition and the last item will go to the third
partition. This partition is based purely on hash logic, which we are not going to discuss
here.
In our library catalogue example, we are always looking for a certain topic, with the as-
sumption that the first thing that comes to our mind when identifying a topic is its title.
That is why we decided to set the
BookTitle
attribute as the hash key. Another reason
why we chose this specific attribute as the hash key is the assumption that most of the scan
operations for the table will include the
BookTitle
attribute.
DynamoDB does not allow duplication of the hash key (provided that the table does not
have a range attribute), so if the primary key is a simple hash key, then we are enforcing
that an entry cannot be made into the previous table with the same topic title. But in a real-
world scenario this is not the case. So we are in need of a range key attribute as well. The
next decision to be taken is what should be made the range attribute. We will assume that
the second attribute that comes to mind when identifying a topic is the name of its author.
