Best Practices - Mastering DynamoDB - page 145

Local secondary indexes best practices
We have seen what local secondary indexes mean in Chapter 2 , Data Models . Just to re-
vise, they are secondary indexes that you can define on certain attributes, and which can be
used as another range key along with your table hash key. As we have seen, since Dy-
namoDB needs to maintain a complete separate index for these indexes, we have to alloc-
ate more resources to it, which makes it a costly affair. So, it is very important to decide on
the attribute on which you wish to define the secondary index. It is recommended that the
attribute you are not going to query much should not be defined as local secondary index.
Indexing should be done for the tables that do not get heavy writes as maintaining those in-
dexes is quite costly.
Indexes should be put on tables that contains sparse data, and which are infrequently up-
dated. It has been observed that the smaller the index, the better the performance. A sec-
ondary index consists of an index plus projected attributes. So, it is very important that
while creating the index, you should project only required attributes. If a required attribute
is not projected in the index, then DynamoDB fetches that attribute from the table, which
consumes more read capacity units.
We should also keep a watch every time we update or edit the items in an index. If we don't
keep track of the data being written or read, the provisioned throughput capacity would be
at risk. We should also keep in mind the maximum item collection (collective size of all
items and indexes having same hash key) size limit of 10 GB in the case of local secondary
indexes.
Normally, when the item collection size gets exceeded, you get ItemCollectionS-
izeLimitExceededException . The following are some solutions that would help
you avoid getting this exception:
• Purging of unnecessary items from the table: This would also delete the respective
items from the index as well.
• Updating unnecessary items to remove the projected attributes from the index:
This will automatically reduce the size of item collection.
• Backup or moving old data to a new table: It is always a good practice to save his-
torical data in a different table.