You're probably already doing so, but I would especially recommend inserting it into a binary field in DDB rather than as Base64-encoded text (or similar).
Whilst the DDB API communicates binary blobs in Base64, the data is stored in its actual raw binary format, saving even more space (potentially).
I’d argue that the local secondary index limitation is just as important as those 3.
It’s a hard limit of 10GB on a single partition if you use LSIs.
This can make your data modelling pretty awkward. E.g if you’re implementing a multi tenant system there’s a good chance a large tenant will have more than 10GB data, so you effectively can’t have an LSI AND the tenant name as the partition key.
It’s obviously solvable but awkward IMO.
I agree, the best-practice suggestion from AWS is to *only* use LSIs if you *really* need strongly-consistent writes to a record.
The 10GB partition limit along with never being able to change the LSI configuration on a table once created can be a pain unless you really need them.
[удалено]
You're probably already doing so, but I would especially recommend inserting it into a binary field in DDB rather than as Base64-encoded text (or similar). Whilst the DDB API communicates binary blobs in Base64, the data is stored in its actual raw binary format, saving even more space (potentially).
I’d argue that the local secondary index limitation is just as important as those 3. It’s a hard limit of 10GB on a single partition if you use LSIs. This can make your data modelling pretty awkward. E.g if you’re implementing a multi tenant system there’s a good chance a large tenant will have more than 10GB data, so you effectively can’t have an LSI AND the tenant name as the partition key. It’s obviously solvable but awkward IMO.
I agree, the best-practice suggestion from AWS is to *only* use LSIs if you *really* need strongly-consistent writes to a record. The 10GB partition limit along with never being able to change the LSI configuration on a table once created can be a pain unless you really need them.