Database Reference
In-Depth Information
Using indexes sparingly
It is not advisable to create an index for an attribute (it might be a key attribute as well as
non-key attributes projected) that is frequently updated and rarely used in queries. Frequent
updating of table items will update its associated index items as well. Due to this, we might
suffer very high I/O cost. On the other hand, projecting (or creating an index for) rarely
used attributes will make us incur a high level of storage cost. So, the index has to be cre-
ated only for attributes used in queries.
In reality, most of our applications frequently add or update items into the DynamoDB
table. Does that mean we cannot (efficiently) use an index for this kind of a table? There is
a solution. This kind of application that frequently captures items (for example, social net-
working sites) is commonly called a data capture application. In the case of data capture
applications, we are not supposed to create an index directly for this table. Instead we need
to copy this data to another table (repeatedly over a period of time) and create an index for
this newly created table. However, there is one restriction here: the read operation might
not return the latest data available. For example, if the data copy operation happens every
hour (the period is set to an hour) and if the last copy operation occurred at 2 p.m., the read
operation performed at 2:59 p.m. will not return the items updated on the DynamoDB
table. Even though this strategy doesn't return the latest data, this is suitable for applica-
tions where data consistency is tolerable for a period of time.
