AWS Certified Solutions Architect - Professional 2020

Sign Up Free or Log In to participate!

Secondary Index – consideration / benefit table

The 4th row in the last table says of the lesson

If you rarely query but write or update frequently, consider projecting keys only for the global secondary index.

Can you provide a real world example, I can’t get my head around what is happening here and what is being achieved?


2 Answers

Hi Jimjam,

I’m in the process of updating that lecture with some better examples.  For the time-being, here’s a use-case that comes to mind…

Let’s say you have a IoT application that writes status reports from a CNC machine every 2 seconds.  These are used for a dashboard where operators can monitor real-time machine status.  You present the data to the dashboard based on time so you’ve chosen to use a combination of date and time as your primary keys.  However, the program on the machine needs to update its status based on Machine ID and Part ID with timestamp just as an attribute.  An index over Machine ID and Part ID will allow the application on the machine to update its respective record in the table really quick and efficiently.


Diogo Minhava Lopes

I think it may be important to clarify that applications never write directly to an index ( – the application in that case would need to get the primary key from the index and then execute an UpdateItem operation on the main table (Still much better than doing a full scan on the main table first of course). I know this is what you meant, but it may sound a bit confusing 🙂 Please correct me if I’m wrong!

You have created primary key on attribute and want to query of attribute which is not declared as primary key. Instead of doing full table scan (which is sequentially) so declare those new projceted keys for GSI

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?