DynamoDB – Best Practices - DynamoDB Applied Design Patterns - page 219

Uniform workload
For uniform data access within items in your tables, you have to identify the workload pat-
terns on items/tables. Your provisioned throughput is dependent on the primary key plus
pattern of workload on items. At the time of storing data, DynamoDB will divide your
items into more than one partition and will distribute your data based on the hash key ele-
ment. So your throughput will be associated with a table which is also divided among parti-
tions. This throughput will be based on no sharing among all partitions.
To get the quantity of requested throughput, you have to keep your workload spread out
evenly among the hash key values. By distributing the hash key values, you can distribute
the requests across multiple partitions.
Let's take an example. If your table has a single hash key element for your content, and
supposing your hash key element is heavily accessed, the traffic will be concentrated in a
small number of partitions. Here you have only one for example. So from the example, you
can say that your workload will be heavily unbalanced as it is focused on one partition
only, so the operations won't achieve the desired throughput level. To get the desired output
as provisioned throughput, you have to build tables in such a way that the hash key element
has a huge number of distinct values and it should be fairly random, but with some mean-
ing.
This does not mean that you have to access all the hash keys, but when your workload is
accessing more distinctive hash keys be careful that operations will spread across the parti-
tioned space in such a way that it can better utilize your given throughput level. So, there is
a simple phenomenon that utilizes the throughput more accurately as the combined ratio of
hash keys accessed to total hash keys in a table grows. Now the question is: how to decide
on hash keys for the provisioned throughput efficiency? The user ID can be a good ex-
ample of having good efficiency because any application will have lots of users. On the
other hand, for status code, only a few status codes will be available. So based on status
code as the hash key value efficiency may be poor. You have to consider your write opera-
tions among more different hash values when the number of hash key values are very few
in a single table.
For example, let's consider a combined primary hash and range key where the hash key
represents a book ID, in which the topic ID U66 is often heavily exhausted with requests.
To increase write and read performance for throughput for a particular hot hash key, choose
a random number from a fixed set (let's say 1 to 400) of U66.1 , U66.2 through