Any disadvantages with using a sort key with low cardinality?

user_1661745 0
Viewed 369

For my table, I have the attributes:

  1. ItemId
  2. ProductName

Only ItemId + ProductName is unique. However ItemId has very high cardinality and is virtually unique, just not guaranteed. ProductName has very low cardinality (~5 different values). Client will always pass in ItemId + ProductName to get the item.

Approach 1
Originally I was thinking of setting (simple) primary key's partition key to ItemId + ProductName (string concat).

Approach 2
However, since primary key cannot be changed after table is created, I'm thinking of keeping the sort key as a placeholder. So setting (composite) primary key's partition key to ItemId and sort key to ProductName.

The benefit is in case I want to add things to the sort key in the future (like version number), I can do it without migrating table. Though right now I don't see what I would add.

But are there any downsides (such as performance) with Approach 2 as-is (sort key being low cardinality), compared to Approach 1?

amazon-dynamodb amazon-web-services
2 Answers

If you are using on-demand pricing, then this should have no effect on price/performance.

If not, then there can be - in general - some differences: https://blog.yugabyte.com/11-things-you-wish-you-knew-before-starting-with-dynamodb/

Over-provisioning to handle hot partitions.

In DynamoDB, the total provisioned IOPS is evenly divided across all the partitions. Therefore, it is extremely important to choose a partition key that will evenly distribute reads and writes across these partitions. If a table ends up having a few hot partitions that need more IOPS, total throughput provisioned has to be high enough so that ALL partitions are provisioned with the throughput needed at the hottest partition. This can lead to dramatic cost increases and frustrated engineers.

In your particular case it should not have any effect either.

user_28549080

It's difficult to say without knowing how much volume you expect...

Generally, you want a partition key with high cardinality. The sort key cardinality generally doesn't matter.

However, if you anticipate a small number of the itemId getting the most traffic, then you might run into issues with "hot partitions"; although the risk is greatly reduced now-a-days.

Furthermore, hot partitions are only a problem if you DDB table ends up partitioned in the first place. DDB partitions your data when storage gets above 10GB* or when RCU/WCU required is more than 3000/1000 respectively.

*10GB isn't even guaranteed, a DDB table w/o local secondary indexes can have a partition larger than 10GB.

user_29331770
Related