Let's try running some queries and scans in the AWS console.

We're here at the orders table looking at the items tab. We ignored it earlier, but at the top of this page, we can see that this view is doing a scan of the orders table. It must be a scan because there's data visible from many different partition keys. A scan is the only way to do that. A query has to be limited to a single partition key.

We can see the first 100 items on the screen and we can click the little arrow to scroll to the next 100 items. Right now our table only has 120 items, so we can tell when we have scrolled to the end. The data's not sorted in any obvious order, but DynamoDB knows when we've hit the end. The drop-downs at the top are what indicate that this is doing a scan of the entire table. To the right of the word scan, there's a box that lets us select which index we are scanning. Our table doesn't have any indexes except the primary key so the only thing we can do right now is to scan the whole table. Scans can be filtered which allow us to specify conditions for which rows should be included in the result. Let's say we only want to see orders being shipped to Massachusettes. We could click add filter, and then specify that the field shipping state must equal MA for Massachusettes. If we click start search, then after a moment Amazon will show us the orders that are being shipped to Massachusettes.

As we just discussed, these filters can be very expensive to execute. When you scan the full table, DynamoDB has to read every single record and determine if it meets the criteria for the filter. For a large table this can be very slow. Filters are more useful when you have already narrowed down the data to a relatively small subset, like in a query.

Now let's take a look at queries. We can construct a query here in the console by switching the drop-down on the left from scan to query. The options for a query are different than they were for a scan. In a query, you need to first specify the indexed field value to base the query around. We only have one index, our primary key. So our only option is to query for a single order ID. Let's query for order 672102. We can enter that order ID number into the text box here. And when we click start search we will quickly see the one order with that ID. Because we're using a query and not a filter, DynamoDB can find this record very quickly and uses only one read capacity unit for the one record that was returned.

If queries can only return one record, then why have all these other options like filters and sorts? Well, these are useful when you have a composite primary key. Let's switch over to our order line items table. Just to refresh, this table has a composite primary key where each record is uniquely identified by the combination of its order number and line number. The order number is the partition key or top level of the hierarchy and the line number within each order is the sort key. If we perform a query on the table you can see that we can query by both the partition key and the sort key.

Let's try it now. Let's look for the record with order ID 672102 and line number 3. If we enter those criteria and click start search, we quickly get back a result set with exactly one item, just like we expected. But we don't need to specify both a partition key and a sort key. As long as we narrow down the results to one partition key we can leave out the sort key. Let's take that out and click start search. Now we see nine items returned. In fact, they're sorted by line number. We could switch this to reverse order by changing the sort to descending.

This is also where a filter can come in handy. Let's say we want to find the unshipped items in this order. We could add a filter looking for records where status is unshipped. After we click start search we'll get the results. And we see that there are only two items that haven't been shipped. These kind of filters are not as slow or expensive as a filter on an entire table scan. The database performs this query by loading the 9 records with the partition key that matches 672102. And then filter in the results that are sent back to us. This will take nine read/compute units, but that's still a lot less than a full table scan.

Now because the partition key and sort key represent a hierarchy within your table, we can't query on the sort key alone. Let's see what happens if we remove the filter and remove the order ID and then try and send a query for all the records with line number 3. If we set up a query this way and then click start search, DynamoDB won't allow it because we haven't narrowed down our query to a single partition key.

Now that we've seen how to do basic queries and scans using the web console, the next video will discuss how to do these operations using the API.