Amazon DocumentDB (with MongoDB compatibility) is a scalable, highly durable, and fully managed database service for operating mission-critical MongoDB workloads. We recently announced support for AWS Graviton2 instances for Amazon DocumentDB. AWS Graviton2 processors are custom built by AWS using 64-bit Arm Neoverse cores and feature always-on, fully encrypted DDR4 memory and 50% faster per-core encryption performance. These performance improvements make AWS Graviton2 R6g database instances a great choice for database workloads.
Benefits of moving to AWS Graviton2
There are several reasons why you may consider moving to AWS Graviton2 instances for Amazon DocumentDB:
AWS Graviton2 instances provide up to 30% price/performance improvement for Amazon DocumentDB depending on database size and workload characteristics vs. Intel-based instances
r6g AWS Graviton2 instances are 5% less expensive than their r5 counterparts, and t4g.medium AWS Graviton2 instances are 3% less expensive than t3.medium instances
You don’t need to change your application when migrating from Intel to AWS Graviton2 instances on Amazon DocumentDB
All features that work with Amazon DocumentDB Intel-based instance types such as the t3, r4, and r5 series continue to work with AWS Graviton2-based instance types such as t4g and r6g.
Move from Intel-based r4 or r5 instances to AWS Graviton2 instances
Migrating to AWS Graviton2 instances can be done using the AWS Management Console, AWS Command Line Interface (AWS CLI), or the AWS SDK to upgrade your Intel-based instance types to AWS Graviton2 instance types.
On the Amazon DocumentDB console, choose your cluster, navigate to the instance that you want update, and choose Modify.
For Instance class¸ choose your new instance class.
Choose whether you want to apply this change immediately, or in the next maintenance window. For the purposes of this post, we select Apply immediately.
Choose Modify instance.
You can also use the AWS CLI to upgrade your instances. To do so, use the modify-db-instance API call and modify your instance type:
Benchmark used and specific benchmark configuration
For the purposes of this blog we will benchmark the r5 instance types against the r6g (Graviton) instance types. We used Socialite which is a social data reference architecture created by MongoDB with source code available on GitHub. Part of the implementation consists of a benchmarking harness allowing for various server configurations and transactional patterns to be measured. The included schema supports users, status updates, and the following operational activities:
read-timeline – Gather the most recent content for a user’s social network
scroll-timeline – Gather older content for a user’s social network
friends-of-friends-query – Gather the complete list of a user’s followers using queries
friends-of-friends-agg – Gather the complete list of a user’s followers using aggregations
unfollow – Set a user to follow another user
send-content – Post a status update for a user
get-followers – Gather the complete list of a user’s followers
get-follower-count – Determine the number of a user’s followers
follow – Set a user to stop following another user
To test performance across various instance types, we used the following test configurations:
Data – 100,000 users, 100 messages per user, 200 max follows (database size of 4.5 GB)
Infrastructure – Three-instance Amazon DocumentDB clusters with a benchmark client in the same Availability Zone as the primary instance
Session duration – 10, with concurrency 8 for 2xl instances and 32 for 8xl instances
Transaction percentages – follow = 2%, unfollow = 1%, read-timeline = 50%, scroll-timeline = 41%, send-content = 4%, friends-of-friends-query = 1%, and friends-of-friends-agg = 1%
We ran the benchmark against three instance types: 2xl, 8xl, and 16xl. On each instance type, we limited the number of transactions per second (tps) in order to measure and compare CPU utilization and the p99 latency of each transaction type.
Running the benchmark on r6g.2xl and r5.2xl instances
On the 2xl instance types, we gated the transactional throughput at 70 tps. At that throughput we measured CPU at 60% on the AWS Graviton2 instance vs. 80% on Intel for an 25% improvement. Our overall transactional p99 latency was 43.7% lower on AWS Graviton2, with each specific transaction p99 latency shown in the following two graphs. We present the data using two graphs so the short-running operation bars are readable.
Running the benchmark on r6g.8xl and r5.8xl instances
On the 8xl instance types, we gated the transactional throughput at 300 tps. At that throughput we measured CPU at 65% on the AWS Graviton2 instance vs. 88% on Intel for an 26.1% improvement. Our overall transactional p99 latency was 25.4% lower on AWS Graviton2, with each specific transaction p99 latency shown in the following two graphs.
Running the benchmark on r6g.16xl and r5.16xl instances
On the 16xl instance types, we gated the transactional throughput at 600 tps. At that throughput we measured CPU at 71% on the AWS Graviton2 instance vs. 93% on Intel for an 23.7% improvement. Our overall transactional p99 latency was 46.2% lower on AWS Graviton2, with each specific transaction p99 latency shown in the following two graphs.
In this post we demonstrated that AWS Graviton2 instances provide better performance for a lower price than older generations of hardware. You can now provision new AWS Graviton2 instances or migrate existing instances to AWS Graviton2 instances for both v3.6 and v4.0 of Amazon DocumentDB. To learn more about Regional availability, refer to Managing Instance Classes.
About the Authors
Meet Bhagdev is a Senior Product Manager at Amazon Web Services. Meet is passionate about all things data and spends his time working with customers to understand their requirements and building delightful experiences. Prior to his time at AWS, Meet worked on Azure databases at Microsoft.
Tim Callaghan is a Principal DocumentDB Specialist Solutions Architect at AWS. He enjoys working with customers looking to modernize existing data-driven applications and build new ones. Prior to joining AWS he has been both a consumer of Relational and NoSQL databases for over 30 years.
Read MoreAWS Database Blog