DynamoDB Partition Key Best Practices

Banking Application

Prev Question Next Question

Question

You are developing a banking application that will interact with a DynamoDB table.

The table is going to take in a lot of read and write operations.

Which of the following would be the ideal partition key for the DynamoDB table to ensure ideal performance?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer - A.

The AWS Documentation gives the ideal way to construct partition Keys.

Recommendations for partition keys.

Use high-cardinality attributes.

These attributes have distinct values for each item, like e-mailid, employee_no, customerid, sessionid, orderid, and so on.

Use composite attributes.

Try to combine more than one attribute to form a unique key, if that meets your access pattern.

For example, consider an orders table with customerid+productid+countrycode as the partition key and order_date as the sort key.

Option B is incorrect because CustomerName may be the same.

Option C is incorrect because some customers can have the same location.

Option D is incorrect because Age can be the same for customers.

For more information on choosing the right partition Key, please refer to the below Link-

https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/

When designing a DynamoDB table, the partition key is a crucial factor that affects the table's performance. It determines how data is distributed across partitions, and therefore impacts the scalability and speed of read and write operations.

In this scenario, we want to choose a partition key that can evenly distribute the data across partitions, avoid hot partitions (where a single partition receives a disproportionate amount of traffic), and minimize the number of partitions that need to be accessed for each query.

Option A: CustomerID CustomerID could be a good partition key if it is a unique identifier for each customer and is evenly distributed across the table. If so, it would avoid hot partitions and provide good performance. However, if there are customers with the same ID, this option could lead to hot partitions and poor performance.

Option B: CustomerName Using CustomerName as a partition key is not recommended because it is not guaranteed to be unique and evenly distributed. Names can be duplicated, and some letters may be used more frequently than others, which could lead to uneven distribution of data and hot partitions.

Option C: Location If the application is designed to query data based on a specific location, Location could be a good choice as the partition key. Queries that involve filtering or sorting by location would only need to access a small subset of the partitions, resulting in faster performance. However, if the application needs to retrieve data across multiple locations, this option could lead to hot partitions and poor performance.

Option D: Age Using Age as a partition key is not recommended because it is unlikely to be evenly distributed across the table. There may be age ranges that are overrepresented or underrepresented, leading to uneven distribution of data and hot partitions.

In conclusion, Option A (CustomerID) could be the ideal partition key for the DynamoDB table, provided that CustomerID is a unique identifier that is evenly distributed across the table.