When creating your DynamoDB table, consider its primary use. Are you going to be writing lots of data?

The size of each records matters a lot when it comes to performance. Or perhaps right operations will occur infrequently while reading the data will be a constant ongoing operation? Do you have records that need to be related to records in other tables or perhaps one of your attributes is binary data such as a picture or cryptographic material? The reason why you need to understand your data is because DynamoDB can be fine-tuned to your specific needs. This saves you from unnecessary database costs and allows you to get the most performance out of your table. For example, I just mentioned binary data and table relationships. In both of these cases, DynamoDB is not the optimal solution; Amazon RDS is. In regards to data size, if you're working with JSON documents larger than 4 KB, this will impact your read and write capacity units, essentially doubling the performance demands of your table. Actually, let's dive deeper into these so-called capacity units. Provided that you create your DynamoDB table using provision capacity, you'll be able to manage your read/write capacity units. This may not be true if you use on-demand or auto-scaling capacity modes.

Regardless of your capacity mode, it's important to understand read/write capacity units. Read/write Capacity Units or RCUs represents the number of strongly consistent reads per second, or eventually consistent reads per second for an item up to 4 KB in size. When you perform a Query or Scan operation, the number of RCUs consumed depends on the size of the items being returned, the number of items, and the type of read consistency that you choose. So, data items larger than 4 KB will need additional capacity units. By the way, you can see your average item size for your table in the DynamoDB console. Write Capacity Units or WCUs represents the number of write requests per second for an item up to 1KB in size. When you perform a put item or update item operation, the number of WCUs consumed depend on the size of the items being written and the type of write request, whether a PUT or an UPDATE. So, very similar to the read operation, just smaller in size. By specifying the appropriate number of RCUs and WCUs for a table, you can control the performance and scalability of your DynamoDB table. The RCU and WCU values can be adjusted at any time to meet the changing performance and capacity requirements for your application. In DynamoDB, the Query and Scan operation serve two different purposes.

A query is used to retrieve one or more items from a table or a secondary index by specifying the partition key and the sort key if you have one. The Query operation returns the item that matches the specified partition key value and the optional sort key value. If you provide a filter expression, only the items that match the filter will be returned. The Query operation is efficient because it uses the partition and sort keys to identify the specific items to return and because it returns only the items you're interested in, typically just one such as a user profile or account rather than an entire table or index. On the other hand, the Scan operation reads every item in the table or index and returns all of the data attributes for the item that match the filter expression. The Scan operation is not as efficient as the query because it reads the entire table and possibly returns a large amount of data rather than just the items you're interested in. Use the scan only when you can't use the Query operations because the require filter expression can't be defined using the partition and sort keys. In summary, if you know the partition key and sort key values of the items you want to retrieve, use the Query operation. If you need to search the entire table or index to find items that match a filter expression, then use the Scan operation.

Just a quick word on indexing. While DynamoDB indexing is beyond the scope of this course, I'll quickly mention your options here in case you want to learn more about them in the Cloud Academy library. A Global Secondary Index or GSI is an index with a partition key and a sort key that can be different from those on the base table. You can create multiple of these on a single table with each index having a unique partition key value. An LSI or Local Secondary Index is an index with the same partition key as your table but a different sort key. Both LSI and GSI will help improve performance and scalability of your application. That said, it's still wise to plan ahead and know which data items should be indexed ahead of time.