Scan operations are less efficient than other operations in DynamoDB. A Scan operation always scans the entire table or secondary index, then filters out values to provide the desired result, essentially adding the extra step of removing data from the result set.
Avoid using a Scan operation on a large table or index with a filter that removes many results, if possible.
Also, as a table or index grows, the Scan operation slows. For faster response times, design your tables and indexes so that your applications can use query instead of Scan .
For tables, you can also consider using the GetItem and BatchGetItem APIs.
Avoid sudden spikes in read capacity:Note that it is not just the sudden increase in capacity units the scan uses that is a problem. It is also because the scan is likely to consume all of its capacity units from the same partition because the scan requests read items that are next to each other on the partition. If the request to read data had been spread across multiple partitions, then the operation would not have throttled a specific partition.
Because a Scan operation reads an entire page (by default, 1 MB), you can reduce the impact of the scan operation by setting a smaller page size. The Scanoperation provides a Limit parameter that you can use to set the page size for your request. Each Query or Scan request that has a smaller page size uses fewer read operations and creates a “pause” between each request.
Isolate Scan Operations. DynamoDB is designed for easy scalability. As a result, an application can create tables for distinct purposes, possibly even duplicating content across several tables. You want to perform scans on a table that is not taking “mission-critical” traffic. Some applications handle this load by rotating traffic hourly between two tables – one for critical traffic, and one for bookkeeping. Other applications can do this by performing every write on two tables: a “mission-critical” table, and a “shadow” table.
AWS SDK implements exponential backoff algorithm for better flow control. The concept behind exponential backoff is to use progressively longer waits between retries for consecutive error responses. For example, up to 50 milliseconds before the first retry, up to 100 milliseconds before the second, up to 200 milliseconds before third, and so on. However, after a minute, if the request has not succeeded, the problem might be the request size exceeding your provisioned throughput, and not the request rate. Set the maximum number of retries to stop around one minute. If the request is not successful, investigate your provisioned throughput options.