Database Reference
In-Depth Information
Choosing a primary key
We have seen the primary key representations of DynamoDB, that is, the hash key and
composite hash and range key. The hash key value decides how the items would get distrib-
uted across multiple nodes and the level parallelism. It's quite possible that some of the
items in a table would be used heavily compared to others. In that case, one particular parti-
tion would be used frequently, and the rest of the partitions would range from unused to
less-used, which is a bad thing considering the performance and throughput of the system.
Now let's discuss some best practices in choosing the right hash key and composite hash
and range key.
It is recommended that you should design your tables such that hash key of the table would
be having the variety of data. It does not mean that your application must access all hash
keys all the time, it means even if your application accesses multiple hash keys together, all
such requests would get distributed across the cluster and there would not be any load on
one particular node. Consider the following table which talks about hash keys, scenarios,
and efficiency.
Table
Hash key
Scenario
Efficiency
Book Book ID
Each book has a unique book ID, and there are a variety of topics in a table
Good
Country Country name Limited number of countries
Bad
Songs Song ID
Each song has a unique song ID, but one particular song is much more popular than others Bad
In the third scenario we have the songs table, which would contain multiple songs with
each song having a unique song ID. But there is a big chance that one or two songs turn out
to be more popular than any other song. This would also result in uneven use of the Dy-
namoDB cluster.
To avoid creating hot partitions in DynamoDB, it is recommended to append a random
number to the hash key. In our example, we saw that the songs table had a few songs that
which were accessed more than others. In order to avoid creating a hot partition, we can ap-
pend a random number to the most popular song IDs and save it as a completely new hash
key. Suppose we have a song with the song ID 123, then it is recommended that we append
random number between certain ranges and distribute the load so that we can have multiple
items, such as 123-0, 123-1, 123-2, and so on.
Search WWH ::




Custom Search