The company wants to migrate the application to Amazon DynamoDB with the following considerations:• Optimize frequent queries• Reduce read latencies• Plan for frequent queries on certain key attributes of the tableWhich solution would help achieve these objectives?
Create global secondary indexes on keys that are frequently queried. Add the necessary attributes into the indexes.
Create local secondary indexes on keys that are frequently queried. DynamoDB will fetch needed attributes from the table.
Create DynamoDB global tables to speed up query responses. Use a scan to fetch data from the table
Create an AWS Auto Scaling policy for the DynamoDB table.
Explanations:
Creating global secondary indexes (GSIs) on frequently queried keys helps optimize query performance by allowing for fast lookups on non-primary key attributes, reducing read latencies. The necessary attributes are included in the index, which avoids the need to access the main table for those queries.
Local secondary indexes (LSIs) are useful when you need to query data with the same partition key but different sort keys. However, this option doesn’t optimize queries based on attributes that can vary independently of the partition key, making it less suited for reducing latency on frequent queries of key attributes across the table.
DynamoDB global tables are designed to provide multi-region replication, which isn’t directly related to optimizing frequent queries or reducing read latencies for a single region. Also, using a scan operation is inefficient compared to querying indexed attributes, as it reads the entire table.
AWS Auto Scaling adjusts read and write capacity based on usage but does not directly address the issue of optimizing frequent queries or reducing read latencies. It helps with throughput management, but not query optimization or latency reduction.
In my experience, the answer is:
Create global secondary indexes on keys that are frequently queried. Add the necessary attributes into the indexes.