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?
Thanks
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.
–Scott
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
I think it may be important to clarify that applications never write directly to an index (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html#GSI.Writes) – 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!