DynamoDB Performance Considerations
Start course
3h 3m

This course provides detail on the AWS Database services relevant to the AWS Certified Developer - Associate exam. This includes Amazon RDS, Aurora, DynamoDB, MemoryDB for Redis, and ElastiCache.

Want more? Try a lab playground or do a Lab Challenge!

Learning Objectives

  • Obtain a solid understanding of the following Amazon database services: Amazon RDS, Aurora, DynamoDB, MemoryDB for Redis, and ElastiCache
  • Create an Amazon RDS database
  • Create a DynamoDB database
  • Create an ElastiCache cluster

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.


About the Author
Learning Paths

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.