5 ms·

How to Run a Database on AWS with Better Performance and Lower Cost

44 points by Bella-Xiang 6y ago

CharlesW 6y ago
A less clickbait-y title would be, "How to Run Our Database on AWS at a Reasonable Cost". "Reasonable Cost" comes from the conclusion, and I omitted "Better Performance" since they never compare to alternatives (although they do mention Aurora).
- gkop 6y ago
  For what it’s worth, there’s a good amount of content in the article that I found interesting for my purposes operating Postgres on RDS.
  - CharlesW 6y ago
    Interesting. What changes are you making to future Amazon RDS for PostgreSQL instances as a result?
    - gkop 6y ago
      I bookmarked the article and will consult it next time I’m reviewing instance types for a cluster.
- tabokie 6y ago
  Sorry if the title sounds misleading to you. We are simply trying to give our customers (or potentially other cloud database users) a solution that has best performance with limited resources. Competitive analysis is not the focus of this post.
  - CharlesW 6y ago
    (This advice is offered in the spirit of improving your content marketing efforts.) I understand the desire to "reel in" more readers than a post might otherwise warrant, but in my experience you're better off not promising general advice if you're not providing it. For example, you might say, "How we configure TiDB on AWS to handle XXX transactions per second for XXX/month", or "Squeezing the highest TiDB performance from AWS m5 instances". There are definitely interesting ways to title posts in a way that's supported by the content.
rubiquity 6y ago
Disclosure (I used the right word!): I work at AWS. Opinions are my own. This is a nice article with some fun comparisons and important details around the specifics of operating TiDB and systems like it on AWS. If I were running a replicated database such as TiDB, hypothetically of course, I'd probably opt for an instance type with locally attached storage. EBS volumes are already replicated themselves for durability so if you're running a replicated DB on EBS volumes then you're going to be replicating while you're replicating. Yo dawg. That's going to be some extra latency, even with a majority quorum replication protocol like Raft. Historically if you wanted locally attached SSDs the more expensive storage instance types like i2/i3/i3en were all you had but now there's m6gd, c6gd, and r6gd[0]. Lots of options at all sorts of price points for your workload. The Graviton 2 based m6gd instances with local NVMe SSDs are more cost effective than the m5 instances that the blog post is using, which do not have a local SSD. As the post calls out, if you are going to use EBS then use it for the materialized key-value store portion. Maybe even make a little Step Function to snapshot the EBS volumes to figure out where you can safely trim the Raft log at. It could be nice. 0 - https://aws.amazon.com/about-aws/whats-new/2020/07/announcing-new-amazon-ec2-instances-powered-aws-graviton2-processors/ https://aws.amazon.com/about-aws/whats-new/2020/07/announcin...
- sudeepj 6y ago
  > EBS volumes are already replicated themselves for durability That is only within the same AZ right? Only snapshots are cross-AZ replicated? PS: why, oh why ppl use this hard-to-read gray font color? Is there allergy to the black font color on white background?
  - rubiquity 6y ago
    That’s right. But AZs can be big and network paths can vary. Always monitor.
- deleted 6y ago
  [deleted]
pachico 6y ago
I'm quite surprised, by looking at the post date, they didn't use the new Graviton2 instances. I'm afraid this post is born already obsolete on this matter.
- deleted 6y ago
  [deleted]
jfim 6y ago
The part that's not mentioned is that there's no real latency guarantee on these IOPS. If you're running a database that has to do a few data dependent reads (eg. walking a B tree), then these can add up quickly if latency spikes to dozens of milliseconds (eg. this datadog blog post [0]). [0] https://www.datadoghq.com/blog/aws-ebs-latency-and-iops-the-surprising-truth/ https://www.datadoghq.com/blog/aws-ebs-latency-and-iops-the-...
- tabokie 6y ago
  Author here, thanks for the pointer and I actually did read about it before. You are right that cloud vendors don't really offer those guarantees. But from my experience benchmarking on EBS, under normal pressure they are good enough for latency sensitive tasks. I can even say that stability-wise AWS EBS is far better than equivalents from GCP or Azure. Probably they have being improving things since this post came out in 2013? I'm not sure.
jtdev 6y ago
I’m not sure how this could be cheaper than RDS...? Nor do I see how the complexity of this solution could be justified except in the most performance sensitive situations.
- gregwebs 6y ago
  TiDB is for larger scale data and thus a better comparison would probably be with AWS Aurora. We do see customers saving money by taking on the complexity of operating a database themselves rather than using the AWS offering.

44 points by Bella-Xiang 6y ago

A less clickbait-y title would be, "How to Run Our Database on AWS at a Reasonable Cost". "Reasonable Cost" comes from the conclusion, and I omitted "Better Performance" since they never compare to alternatives (although they do mention Aurora).

gkop 6y ago
For what it’s worth, there’s a good amount of content in the article that I found interesting for my purposes operating Postgres on RDS.
- CharlesW 6y ago
  Interesting. What changes are you making to future Amazon RDS for PostgreSQL instances as a result?
  - gkop 6y ago
    I bookmarked the article and will consult it next time I’m reviewing instance types for a cluster.
tabokie 6y ago
Sorry if the title sounds misleading to you. We are simply trying to give our customers (or potentially other cloud database users) a solution that has best performance with limited resources. Competitive analysis is not the focus of this post.
- CharlesW 6y ago
  (This advice is offered in the spirit of improving your content marketing efforts.) I understand the desire to "reel in" more readers than a post might otherwise warrant, but in my experience you're better off not promising general advice if you're not providing it. For example, you might say, "How we configure TiDB on AWS to handle XXX transactions per second for XXX/month", or "Squeezing the highest TiDB performance from AWS m5 instances". There are definitely interesting ways to title posts in a way that's supported by the content.

rubiquity 6y ago

Disclosure (I used the right word!): I work at AWS. Opinions are my own. This is a nice article with some fun comparisons and important details around the specifics of operating TiDB and systems like it on AWS. If I were running a replicated database such as TiDB, hypothetically of course, I'd probably opt for an instance type with locally attached storage. EBS volumes are already replicated themselves for durability so if you're running a replicated DB on EBS volumes then you're going to be replicating while you're replicating. Yo dawg. That's going to be some extra latency, even with a majority quorum replication protocol like Raft. Historically if you wanted locally attached SSDs the more expensive storage instance types like i2/i3/i3en were all you had but now there's m6gd, c6gd, and r6gd[0]. Lots of options at all sorts of price points for your workload. The Graviton 2 based m6gd instances with local NVMe SSDs are more cost effective than the m5 instances that the blog post is using, which do not have a local SSD. As the post calls out, if you are going to use EBS then use it for the materialized key-value store portion. Maybe even make a little Step Function to snapshot the EBS volumes to figure out where you can safely trim the Raft log at. It could be nice. 0 - https://aws.amazon.com/about-aws/whats-new/2020/07/announcing-new-amazon-ec2-instances-powered-aws-graviton2-processors/ https://aws.amazon.com/about-aws/whats-new/2020/07/announcin...

sudeepj 6y ago
> EBS volumes are already replicated themselves for durability That is only within the same AZ right? Only snapshots are cross-AZ replicated? PS: why, oh why ppl use this hard-to-read gray font color? Is there allergy to the black font color on white background?
- rubiquity 6y ago
  That’s right. But AZs can be big and network paths can vary. Always monitor.
deleted 6y ago
[deleted]

pachico 6y ago

I'm quite surprised, by looking at the post date, they didn't use the new Graviton2 instances. I'm afraid this post is born already obsolete on this matter.

deleted 6y ago
[deleted]

jfim 6y ago

The part that's not mentioned is that there's no real latency guarantee on these IOPS. If you're running a database that has to do a few data dependent reads (eg. walking a B tree), then these can add up quickly if latency spikes to dozens of milliseconds (eg. this datadog blog post [0]). [0] https://www.datadoghq.com/blog/aws-ebs-latency-and-iops-the-surprising-truth/ https://www.datadoghq.com/blog/aws-ebs-latency-and-iops-the-...

tabokie 6y ago
Author here, thanks for the pointer and I actually did read about it before. You are right that cloud vendors don't really offer those guarantees. But from my experience benchmarking on EBS, under normal pressure they are good enough for latency sensitive tasks. I can even say that stability-wise AWS EBS is far better than equivalents from GCP or Azure. Probably they have being improving things since this post came out in 2013? I'm not sure.

jtdev 6y ago

I’m not sure how this could be cheaper than RDS...? Nor do I see how the complexity of this solution could be justified except in the most performance sensitive situations.

gregwebs 6y ago
TiDB is for larger scale data and thus a better comparison would probably be with AWS Aurora. We do see customers saving money by taking on the complexity of operating a database themselves rather than using the AWS offering.