In the last video, we showed how to do operations on single items in a DynamoDB table. Now, we're going to talk about how to search the database using two operations called queries and scans.

A DynamoDB query searches the table and loads the results that match a single partition key. On the table that has only a partition key without also having a sort key, this means that a query will only return at most one item. So a query on our Orders table would never return more than one item. On a table with a compound key, like our Ordered Line Items table, then you can write a query to load all the records matching the partition key portion of that. You can also write a query that will limit its results to a single sort key value, or to a range of sort keys. For example, in our Line Items table we could query for the single item with line number 25, or line numbers greater than 9 or less than 36. Sort keys don't have to be numbers, so you can also do this with strings. You could search for sort keys between a certain range of strings, or even strings that begin with a specific value.

When you write a query, you have the option to filter your results on any other column in the table. These filters operate after the data has been narrowed down to a single partition key. This can reduce the amount of data that's sent to your application, but these filters can still be costly in terms of read capacity units. Let's say you query for a partition key that has 10 items with different sort keys. If you use a filter to narrow the result down to a single item, DynamoDB still has to read all 10 items in order to decide which ones match the filter. That means that it's going to take longer than just reading a single item, and it's going to use 10 units of read capacity. If this is something that you do often, you might want to add a secondary index instead. Secondary indexes will be covered later in this series.

If you run a query that returns a few results from the same partition key, then you also have the option of returning the results in ascending or descending order by sort key. You can also limit your results, for example, just returning the top 50 or the bottom 10.

Finally, when you execute a query, you have the choice of whether to make it strongly consistent or eventually consistent. If there's data in the result set that has been modified recently, a strongly consistent query will check all three replicas in the different availability zones and will make sure that it sends back the most recent version of the data. An eventually consistent query won't do that. It will just grab the data from a single zone, which might be slightly out of date compared to the last written version. Eventually consistent queries can be a little faster, and they're cheaper. They use half of the read capacity that strongly consistent queries do.

By contrast, a DynamoDB scan searches the entire table across all the partition keys. A scan is useful when you want to review all of the data in a table. The results of a scan can be filtered by attributes of the data, similar to how filters on queries work. But DynamoDB still has to scan your entire table in order to generate the results. This means that a filtered scan is going to be pretty expensive, because it's going to need enough read capacity to read the entire table. It's also probably going to be pretty slow.

The results of a table scan aren't guaranteed to be returned in a specific order. In practice, partition keys appear to be ordered randomly. Table scans can only operate with eventually consistent behavior. DynamoDB doesn't guarantee that a scan will retrieve the most recent copy of any record in the table. In practice, this probably won't affect you much, and the good news is that it makes scans considerably cheaper than they would be with strongly consistent semantics.

Finally, scans can be run in parallel from multiple threads in the same process, or even on multiple servers. It's easy to write code that summarizes an entire table in parallel running on an entire cluster of machines, similar to what you would do with Amazon Elastic MapReduce. In fact, if you use Elastic MapReduce to summarize data from a DynamoDB table, it will do this kind of parallel scan when it reads the data from DynamoDB.