DynamoDB Performance & Latency - Everything You Need To Know

Introduction

When building applications that require single-digit millisecond performance, your best option is to go with a scalable serverless solution backed by DynamoDB. DynamoDB has very low latency (time taken to complete an operation) in its operations, with delays ranging from 10 to 20 ms under typical conditions.

However, there are instances where DynamoDB may experience higher latency in its workload, causing delayed responses that can slow down your application.

This article will analyze latency benchmarks of DynamoDB operations, look at ways to identify latency, and address methods to reduce latency. Additionally, we will compare the latency of DynamoDB with popular databases.

Metrics and Benchmarks for DynamoDB Operations

Scan

The scan operation is not inherently fast. It has an O(n) computational complexity, and for large tables, it can exceed the provisioned throughput in a single process. Additionally, DynamoDB has a 1MB scan limit. It consumes up to 128 RCU for eventual reads and 256 RCU for strongly consistent reads. If you exceed the throughput, your requests will start throttling.

Filtering

Using the FilterExpression does not reduce the data pulled from your database. Behind the scenes, it fetches all the data first and then applies the Filter Expression. This adds more overhead to your operation as it needs to run complex filtering upon reading, thereby increasing latency.

Global Secondary Indexes

When you create a GSI, DynamoDB creates another underlying table for the required attributes. It creates a separate throughput for the index. All operations made to the index consume its throughput and not the table's. Therefore, it's recommended to set up the RCU/WCU to be greater than that of the table to avoid potential throttling.

If you perform heavy writing on a table, and the index in the table has insufficient write capacity, DynamoDB throttles the request and causes latency.

Global Table Replication

DynamoDB has a global table replication latency of less than one second. To check the latency, you can refer to the ReplicationLatency metric available to you on CloudWatch.

Insert

DynamoDB offers 40,000 WCUs per second (depending on the region), indicating that the table can handle 40,000 writes per second for items of 1KB in size. DynamoDB will throttle the requests when the write throughput exceeds and cause latency. You can increase that if needed.

Transactions

DynamoDB transactions specify that a Transactional Write/Read cannot exceed 4MB or 25 Items (whichever occurs first). DynamoDB utilizes one read and write capacity unit to prepare the data and commit the transaction during the transaction. Therefore, your requests will likely get throttled with added latency if you exceed the throughput.

Join

Integrating DynamoDB with Apache Hive allows you to execute Join queries on DynamoDB. There is no pre-defined average latency; it depends on your operation. Amazon EMR returns to CloudWatch a metric for each Hive Query to denote the times the provisioned throughput exceeded. Additionally, the throughput consumed by DynamoDB (SuccessfulRequestLatency) in the request gets sent to CloudWatch metrics as well. You can use these metrics to evaluate latency.

VPC Endpoints

Within a VPC, DynamoDB still has its ideal latency. Additionally, there is added latency from the Network Throughput. Each VPC Endpoint (used by DynamoDB) supports bandwidth up to 10Gbps per availability zone and has burst rates of 40Gbps. Once the throughput exceeds, throttling and latency get added to the response causing delays.

Troubleshooting High Latency in DynamoDB

It is crucial to determine why your DynamoDB operations have high latency. To troubleshoot and identify high latency in your DynamoDB tables, you can observe the logs generated by CloudWatch.

When DynamoDB executes an operation, it logs a key metric: SuccessfulRequestLatency. This metric provides two pieces of vital information:

1. The elapsed time for a request (Minimum, Maximum, Average, Sum)
2. The number of successful requests (SampleCount)

It is best to check the Average SuccessfulRequestLatency when troubleshooting high latency. Additionally, the most significant indicator of latency issues is when the Average SuccessfulRequestLatency is high.

You can also use the Latency Logger to obtain a more in-depth log to identify the source of the increased latency.

However, it is essential to note that SuccessfulRequestLatency does not consider network latency or client-side activity.

Improving DynamoDB Performance Using Best Practices

After identifying the source of the increased latency in your DynamoDB table, you must fix it to ensure that your application will guarantee single-digit millisecond latency.

You can include these best practices in your table design to ensure that your table has increased performance.

Avoid Table Scans

When you want to query data off of non-key attributes, a go-to approach many may use is running a filter expression on a database scan. However, this causes DynamoDB to search through your entire database table, increasing latency. Plus, filtering gets done after pulling all data. Therefore, you still consume the RCUs for the whole scan.

Use Global Secondary Indexes

DynamoDB encourages using Global Secondary Indexes to speed up queries on non-key attributes. Therefore, when defining your GSI, ensure that you only project non-key attributes that get used. It helps create the lowest possible latency as the scanned attributes in the index are less.

Additionally, ensure that you only define GSIs that are commonly used. Indexes that are left stale will only increase the I/O and storage cost.

Use Shorter Attribute Names

DynamoDB currently has a maximum item size of 400KB. It includes the data as well as the attribute names used. Therefore, even if you still store data in small sizes but have lengthy attribute names, your item size will increase the time taken to fetch the record due to the large size.

Therefore, having shorter attribute names helps increase the performance of your DynamoDB table.

Use Eventually Consistent Reads

It would be best to implement this based on your application use case. Eventually Consistent Reads suggests that a data item fetched may not include the changes made in a recent write operation. However, this write operation occurs milliseconds before you fetch the item. Re-fetching ensures that you are viewing the last updated content of the item.

This approach has lower latency than Strongly Consistent Reads, and it can help improve your application performance.

Use AttributesToGet in Your Operations for Faster Responses

The DynamoDB client allows you to specify the attributes to return for a request when fetching data. Using this will ensure that only the required attributes are used, thus, creating faster retrieval times that reduce overhead on data transport, un/marshaling, thus, increasing performance.

Use BatchWrite When Persisting Group of Data

A BatchWrite allows you to write 16MB of data or 25 items (whichever occurs first) using one API call. This helps vastly reduce the overhead for creating multiple API calls for writing multiple data, thus, increasing your write performance.

Use Global Tables

When you wish to drastically reduce latency, use Global Tables to create replicas of your tables across multiple regions. This way, your data is closer to your customers, thus, improving data transmission time and overall performance.

Incorporating these best practice design ideologies into your DynamoDB tables helps you increase your table performance and reduce latency.

How Does DynamoDB Fare Against Other Databases?

DynamoDB can handle up to 10 trillion requests per day and more than 20 million requests per second. After all, Amazon designed DynamoDB for their web store. So, getting into this performance comparison, I hope you understand the power of DynamoDB. When modeled correctly, DynamoDB is far more powerful than many NoSQL databases out there.

RDS

At its core, AWS RDS is a relational database, while DynamoDB is a non-relational document database. DynamoDB provides faster lookup times as the data is structured in a document-based format. Additionally, DynamoDB does not require a pre-defined schema, which helps scale data easily.

S3

DynamoDB is restricted to a maximum of 400KB per item, while Amazon S3 has a massive limit of 5TB per item. For storing large objects, S3 is the clear winner. However, S3 does not support advanced filtering for objects, and due to this, it is more recommended for blob storage and not as a transactional database.

Redis

DynamoDB alone runs on SSD storage. Redis, on the other hand, works as an in-memory database. Because of this, Redis can achieve micro-second latency while DynamoDB offers single-digit millisecond latency. Ultimately, Redis offers faster reads/writes with reduced latency.

Elasticache

Elasticache can be used as a primary data source when durability is not an issue for you. So if you use DynamoDB to store analytical data or sessions, Elasticache performs better than DynamoDB as Elasticache offers microsecond latency with higher throughput and IOPS, making it the better service for this use case.

Aurora

Amazon Aurora is a relational database, while DynamoDB is a document-based NoSQL database. DynamoDB provides faster reads/writes than Aurora due to its document-based nature, as each operation gets performed on an independent document rather than a set of related tables.

Elasticsearch

You can use FilterExpression to search for data in DynamoDB. But it is inefficient as it scans the table and removes unnecessary data. Additionally, running complex filtering on DynamoDB is counterproductive as well. Elasticsearch offers parallel computing and inverted indexes to run complex search queries near real-time.

MongoDB

MongoDB can handle larger datasets than DynamoDB, but, as with any NoSQL Database, when the payload increases in size, so does the latency. However, DynamoDB scales well even for more comprehensive data sizes and (if modeled correctly) allows you to query extensive records of data in single-digit millisecond latency.

CosmosDB

CosmosDB typically has a latency of around 20ms per request for data querying. And with increasing data and complex queries, the latency tends to be higher. On the other hand, DynamoDB ensures single-digit millisecond latency in its operations, making it superior.

Conclusion

In this article, we took a look at benchmarks and metrics for DynamoDB latency, troubleshooting latency in DynamoDB, and improving DynamoDB performance using best practices. Finally, we analyzed DynamoDB against other database vendors.

I hope this article provides everything you need to know about latency in DynamoDB.

Thank you for reading.

FAQ

What is the best way to monitor DynamoDB performance?

There is no "best way" to monitor DynamoDB performance. It is subjective to your preference. According to my experience, the best way to monitor DynamoDB performance is by analyzing the metrics sent to Amazon CloudWatch. It is easy to get started with as DynamoDB sends the required metrics to CloudWatch. CloudWatch processes this data and presents near-real-time metrics in a readable manner allowing us to monitor DynamoDB performance effectively.

Does DynamoDB have a performance and latency SLA?

No. DynamoDB does not specify latency in its SLA. However, Amazon ensures that DynamoDB will have a typical latency of 10 to 20ms and a single-digit millisecond latency under optimal conditions.