CODEWITHSUNDEEP
amazon-web-servicesamazon-dynamodb
Rookie
Rookie

Reputation: 929

DynamoDB - Do I need multiple GSIs?

I have a single-table design for my app. However, I have certain rows in the table that have important information that I plan to use to query different kinds of data. Let me explain. My app handles alarms triggered by users. When an alarm gets triggered I record a lot of info about that alert. My goals is to create GSIs so I can retrieve and sort all the info about that alarm that was triggered. Let me give you an example of a row in my table.

PK SK GSI1PK GSI1SK GSI2PK GSI2SK GSI3PK GSI3SK GSI4PK GSI4SK GSI5PK GSI5SK OtherProperties
ShipmentReceived AL#TR#2020-08-19T23:37:41.513Z AL#TR 2020-08-19T23:37:41.513Z AL#TR#LO Building1#WingA#Floor1#OfficeB#2020-08-19T23:37:41.513Z [email protected] 2020-08-19T23:37:41.513Z 1234567 2020-08-19T23:37:41.513Z AL#TR#HOW PC#KS Other values go in other columns

NOTE: AL#TR means: "Alarm Triggered" and AL#TR#LO means "Alarm triggered from location". AL#TR#HOW indicates how the alarm was triggered. 1234567 is a "device ID" used to trigger the alarm.

This kind of structure allows me to query for all sorts of interesting data. for example:

I am reading the DynamoDB documentation and I see that it says that it is not recommended to use indexes on items that are not queried often. A lot of these GSIs will not be queried often at all. Just very sporadically.

My question is, am I doing this wrong by creating 5 different GSIs? in this case? Is there a better way to model this data? I thought about this, maybe I can insert multiple rows with related information instead of having everything in one row, but I do not know if that is a better approach. Any other ideas?

Upvotes: 1

Views: 533

Answers (1)

CraigLAWS
CraigLAWS

Reputation: 54

I'm on the DynamoDB team in Seattle, and this response is from one of my colleagues:

"Anytime you need to group or sort the same entities differently, you need to make a new GSI for that access pattern. When you have multiple entity types stored in the same table you can reuse the GSI (aka GSI overloading) for those access patterns on different entities. But in your case, all of the access patterns are about grouping and sorting alarm entities so each would need a different GSI.

"However, GSIs exist to speed up or make cheaper read requests with the trade-off being a higher write expense (to keep the GSIs updated). This makes sense in access patterns that have a high read:write ratio and where the response must come back quickly. But for read access patterns that are done infrequently and for which there isn't a low-latency requirement, it might be cheaper to simply do a Scan operation compared to the cost of having a GSI. For example, for a batch job that runs once a day or once a week it might be cheaper to scan the table once a day or once a week."

Upvotes: 3

Related Questions