DynamoDB: UpdatedDate as a Sort Key on a GSI?

Viewed 598

As stated in this question, I've assumed that you can't have something like updated date as the sort key of a table, because if you update you will create a duplicate record.

Further, I've always assumed that the same thing applied to a GSI using updated date. But in my scenario I have the updated date as a sort key on a GSI, and no new records are created when I update the original item.

To recap, the attributes and key schema are:

Attributes:

  • Id
  • MySortKey
  • MyComputedField
  • UpdatedDate

Table:

  • PartitionKey: Id
  • SortKey: MySortKey

GSI:

  • PartitionKey: MyComputedField
  • SortKey: UpdatedDate

My question is, am I indirectly affecting the performance of the index by doing this? Or are there any other issues caused by this pattern that I'm not aware of?

1 Answers

Global Secondary Indexes are separate tables under the hood and changed items from the primary table are replicated to it.

As you observed correctly, you can use a changing attribute as the sort key in a GSI without that resulting in duplicates once you write to the base table. Note, that there is no guarantee of uniqueness in the GSI, i.e. you can have more than one item with the same key attributes. In addition to that you can only do eventually consistent reads from GSIs.

GSIs also have their own read and write capacity units that you need to provision and if you change items in the base table that need to be replicated, the operation will consume write capacity units on the GSI. Reads are separate from that. The RCUs on the GSI remain unaffected from the writes to the table. But if you often change items, you may see some inconsistencies for a very brief period of time (that's why only eventually consistent reads are possible).

That means you can use the patterns if you can live with the side effects I mentioned.

Related