Home > Net >  DynamoDB TTL fix strategy - set to wrong type (String and not Number)
DynamoDB TTL fix strategy - set to wrong type (String and not Number)

Time:06-20

We just realized that we have set TTL type on the DynamoDB table as String and not as a Number. The TTL field is named "ttl" unfortunately.

"ttl" was set to expire records that are older than 365 days.

This table has grown and is very very big... 26GB.

  1. what is the quickest way to change the type of the "ttl" from String to Number?

Few thoughts that we had:

A. Change code so that when a "new record" is saved we set its "ttl" field to Number. This works if you try it through the console! In this case, we would write a "clean up" job to go through previous records and fix the "type" to Number.

B. Create a new field "ttl_expiry" of type Number. So when "new record" is saved we set "ttl_expiry" and NOT the original "ttl" column. In this case, we would write a "clean up" job to go through previous records and "convert from string to number and copy" into "ttl_expiry" field.

  1. what other strategies can we use to fix this TTL issue?

Is there a quick batch update we can do?

Ah yes, and we are using java :-)

Any help/suggestions would be appreciated.

CodePudding user response:

Either way, you'd have to update all records in the table, which means you need to read and update them. That's going to be comparatively pricy and can't really be optimized if you're doing it online.

For DynamoDB it also doesn't really matter which of the options you're taking, it will only care about attributes that are called ttl and have the type Number (If you change the attribute name, it will look for that).

I'd be more worried about Java, it tends to be fussy with data types in the sense that it cares more about them than let's say Python. Option B may be more appropriate in this case and allows you to read "old" records without issues.

Shorter attribute names help you save on storage cost, so having ttl is probably preferable, but given the modest size of the data that's not going to be a significant number.

Bottom line: Either way can work, with Java the mechanical sympathy is probably higher with B), if you're optimizing for ongoing cost, go for A).

  • Related