Question 302 - DBS-C01 discussion

The correct answer is D. Create one table for each game. Use the player identifier as the partition key. Use the event time as the sort key.

The explanation is as follows:

The ItemCollectionSizeLimitExceededException error occurs when an item collection exceeds the 10 GB limit1. An item collection is a group of items that have the same partition key value but different sort key values2. In this case, the item collection is based on the game name, which has only three possible values. This means that all events for each game are stored in the same item collection, which can easily exceed the 10 GB limit given the high volume and size of events.

To avoid this error, a database specialist should recommend a design change that distributes the events across more partitions and reduces the size of each item collection. Option D achieves this by creating one table for each game, and using the player identifier as the partition key. This way, each event is stored in a separate partition based on the player identifier, and sorted by the event time. This design also supports efficient queries by game, player, and time range.

Option A is incorrect because it still uses a single table for all events, which can cause hot partitions and throttling due to uneven access patterns across games. Also, using the player identifier as the partition key can result in many small partitions that are underutilized and waste provisioned capacity. Adding a global secondary index with the game name as the partition key and the event time as the sort key does not solve the problem of item collection size limit, because global secondary indexes have their own item collections that are subject to the same limit3.

Option B is incorrect because it creates two tables with redundant data and increases storage costs. Also, using the game name as the partition key in both tables does not solve the problem of item collection size limit, as explained above.

Option C is incorrect because it still uses a single table for all events, which can cause hot partitions and throttling due to uneven access patterns across games. Also, replacing the sort key with a compound value consisting of the player identifier collated with the event time does not reduce the size of each item collection, because each event still has a unique sort key value. Adding a local secondary index with the player identifier as the sort key does not solve the problem of item collection size limit, because local secondary indexes share the same item collections as their base table4.