DynamoDB技术求助：无法仅用rangeKey查询，需规避scan操作

Hey there! No worries at all—DynamoDB has its quirks when you're starting out, so let's figure out how to get you the records you want without resorting to a performance-heavy Scan.

The root of the issue is that DynamoDB's Query operation requires targeting a hash key (either on the main table or a secondary index) to narrow down the partitions it looks at. Since you don't want to use Scan, the solution is to tweak your existing Global Secondary Index (GSI) to fit this use case.

Step-by-Step Fix: #

• Repurpose your Global Secondary Index
  Reconfigure your GSI so that its hash key is your main table's RANGE attribute (the one you want to query directly). You can leave the GSI's range key blank if you don't need sorted results, or set it to another attribute if ordering matters for your use case.
  Make sure the GSI's projection includes all the attributes you need in your results. You can choose ALL to pull every attribute, or specify a subset to reduce storage costs (just don't forget any fields you plan to use!).

• Run a Query against the GSI
  Once the GSI is active, you can execute a Query targeting this index instead of the main table. Since the GSI's hash key is now your original RANGE attribute, you only need to pass the value of that RANGE to get all matching records.
  This is a fully optimized partition lookup—way faster than a Scan, as it only touches the relevant partitions in the GSI.

Example with dynog library: #

If you're using dynog, here's a rough idea of what your code might look like (adjust names to match your table/model):

const queryResults = await dynog.query({
  TableName: 'YourTable',
  IndexName: 'YourReconfiguredGSI', // Name of your adjusted GSI
  KeyConditionExpression: '#rangeKey = :targetValue',
  ExpressionAttributeNames: {
    '#rangeKey': 'RANGE' // Your original range key attribute name
  },
  ExpressionAttributeValues: {
    ':targetValue': 'YourDesiredRangeValue' // The range value you're querying for
  }
});

Important Things to Keep in Mind: #

• Performance: This Query will perform just as well as a standard main-table Query—no full table scan, just efficient partition access.
• Write Overhead: Remember that every write to the main table will also update the GSI, so there's a small extra cost and latency for writes. This is a normal tradeoff for using secondary indexes in DynamoDB.
• Projection Check: Double-check your GSI's projection settings. If you only project a subset of attributes, any missing fields won't show up in your query results.

内容的提问来源于stack exchange，提问作者Shishir Anshuman