The key difference is that the primary index has to exist while the secondary indexes are optional. What is the difference between primary index and secondary index in DynamoDB? You can provision a sparse index which uses deletedAt as a sort key and issue queries where sort key exists
Metadata table and you want to be able to find all softly deleted items. In such case, GSI can be an inverted table index - category will become GSI's partition key and productId will become a sortkey Table of products where partition key is productId and sort key is category but you also want to be able to find all products within one category. 
Table of users where partition key is uuid and sort key is createdAt but you also want to have an ability to find a user by email -> Add GSI with Partition Key email. Global/Local secondary indexes are useful if you need to query for some data fast, and that query pattern is not possible using table's main index. Frequently Asked Questions What are the GSI/LSI use cases? defining connections between cities or friendships between users. Inverted Indexes are helpful in bidirectional many-to-many relationships, e.g. Inverted Index is a GSI that is basically a primary key but inversed - table's hash key becomes inverted index's sort key and table's sort key becomes inverted index's hash key. Sparse Indexes are great replacement for queries with FilterExpressions that include a contains operator. To create a sparse index, make sure that only items that should be in that index have a sort key value of that index present. only rows that have an attribute deletedAt defined. This technique is useful to quickly query for a set of items that have a specific attribute value, e.g. Sparse Index is a special type of GSI that allows you to index only a subset of the collection by indexing an attribute that is not present on all the items. They cost x2 more, they might have a little bit bigger latency and you cannot use them on GSIs but they are reflecting the most accurate state of the database. However, if you want to get the most up-to-date data, you can use "Strongly Consistent Reads". It means that query results might sometimes not be consistent and you should be aware of that when creating your application. They are eventually consistent - if you're writing an item to a table, it is asynchronously propagated to the rest of GSIs. Moreover, if you create GSI on the attribute already defined in a collection of items, the index will also be backfilled with that data. You can add and delete them whenever you want. GSIs can be altered after the table has been created. Each of the GSIs is billed independently, and throttling is also separated as a consequence. They don't share throughput with the base table. Global Secondary Indexes don't have to be unique! Two items can have the same partition and sortkey pair on a GSI. Don't have that 10GB of data per Hash/Partition Key limit like LSIs have. Most of the time, you'll find yourself using GSIs over LSIs because they enable much more flexible query access patterns. They don't have to share the same hash key, and they can also be created on a table with a simple key schema. Global Secondary Keys are much more flexible and don't have LSI limitations. They have to be specified at table creation - you can't add or remove them after provisioning the table. Unlike GSIs, they share throughput with base table - if you query for data using LSI, the usage will be calculated against capacity of the underlying table and its base index. 
Limit you to only 10GB of data per Hash/Partition Key.That also means that they can be created only on tables with composite primary key. Local Secondary Indexes use the same hash key as the primary index but allow you to use a different sort key. There are also a few flavors of "indexes": Generally speaking, they allow much more flexible query access patterns.
Secondary Indexes, unlike primary keys, are not required, and they don't have to be unique. They allow you to quickly query and lookup items based on not only the primary index attributes, but also attributes of your choice. What makes DynamoDB so much more than just a simple Key-Value store is the secondary indexes.
0 kommentar(er)
