6 ms·

> which is relevant since he was using AWS Of course, in that case, one is so limited by Amazon's specific hardware choices, if not by virtualization [1]. The

by mmt 8y ago

> which is relevant since he was using AWS Of course, in that case, one is so limited by Amazon's specific hardware choices, if not by virtualization [1]. The OC didn't specify AWS but did mention MySQL, instead of Postgres, which further limits ones ability to implement basic performance optimizations, like separating data and index I/O [2]. > it’s much cheaper and easier to autoscale app servers than database servers based on load Yet I'm still not convinced this is true if the "load" is actually I/O-bound rather than CPU-bound [3]. It may be easier to scale (especially autoscale), but, with cloud providers, that doesn't necessarily mean cheaper. In practice, distributed computing never scales as good as linearly, and people tend not to even measure for diminishing returns or how Amdahl's Law affects them. > It could also be conceivable cheaper if you’re doing non time sensitive online analytics processing instead of something that requires a real time response. I believe GCP has instituted single-instance pricing that's essentially pay-what-you-use in terms of number of cores, so that's even possible with a database server on that provider, but, again, only if the issue is CPU, which I maintain it generally isn't. > Also, when scaling up a database, there is more of a potential for wasting money because of idle capacity when the resources aren’t needed. I recall this sort of thing being the original argument for virtualization, when it first came out, but it only held water if one was grossly over-paying for the resources to begin with (which most "enterprise" shops certainly were, and still are). To me, it's an argument for why, beyond modest size, buying cloud infrastructure is just over-paying. > paying for extra read and write capacity gets expensive > Serverless Aurora that auto scales but it would also get really expensive fast Par for the course for any cloud services, in that they may seem convenient or "auto scale" but the price premium is tremendous, especially at scale. How do they compare with paying for that capacity over EBS? [1] Yes, I know they now have "bare metal" instances, or is it still only instance (singular)? [2] Not that it matters much if one is limited to 10Gb/s or even 40Gb/s (if you can get it) EBS volumes. [3] Which the OC's sort very likely would be but the OP's join would not. To that extent, perhaps the OC's whole premise is a red herring, because I doubt anyone is suggesting not offloading to the app an ORDER BY that's just the last step before presentation to the user.

scarface74 8y ago
in that they may seem convenient or "auto scale" but the price premium is tremendous, especially at scale. How do they compare with paying for that capacity over EBS? Like a lot of things dealing with autoscaling - lambda, Fargate (serverless Docker), serverless Aurora - autoscaling saves money when your demand is really spikey and even then you have to do a cost comparison. For Linux instances, you get per second (or minute?) billing so the cost of bringing instances up and down isn't that expensive. For Windows instances, you are always billed by the hour. * [2] Not that it matters much if one is limited to 10Gb/s or even 40Gb/s (if you can get it) EBS volumes. * The fastest throughput that I am aware of with EBS is 500MB/sec without doing RAID (https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-ebs-provisioned-iops-ssd--io1--volumes-now-support-32-000-iops-and-500-mbs-per-volume/ https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-eb...) Of course instance storage is faster (https://gist.github.com/ktheory/3c3616fca42a3716346b https://gist.github.com/ktheory/3c3616fca42a3716346b), but is that a thing people do for databases?
- mmt 8y ago
  > autoscaling saves money when your demand is really spikey Indeed. I've found the spikiness ratio (if that coined term makes sense) to be 2x-10x for AWS in general, and I was wondering if you (or anyone else) had a sense of how much that increased for these more premium services. > and even then you have to do a cost comparison. I have rarely seen this done, and, when I've talked to people attempting it, the common complaint is that AWS doesn't make it easy. > The fastest throughput that I am aware of with EBS is 500MB/sec without doing RAID Yes, per volume. I was, perhaps, too terse in my footnote. I was referring to the maximum throughput per EC2 node. Considering 40Gb/s would be saturated by about 10 of these, that's not very much. Real hardware can handle quite a bit more than 10 such SSDs attached. > Of course instance storage is faster (https://gist.github.com/ktheory/3c3616fca42a3716346b https://gist.github.com/ktheory/3c3616fca42a3716346b), but is that a thing people do for databases? I would hope so, but probably not in general practice, as it would require too much specialized knowledge. The main problems are that it's ephemeral and very limited in quantity. The impact of the former is reduced by the latter, of course.
  - 8y ago

by mmt 8y ago

scarface74 8y ago

in that they may seem convenient or "auto scale" but the price premium is tremendous, especially at scale. How do they compare with paying for that capacity over EBS? Like a lot of things dealing with autoscaling - lambda, Fargate (serverless Docker), serverless Aurora - autoscaling saves money when your demand is really spikey and even then you have to do a cost comparison. For Linux instances, you get per second (or minute?) billing so the cost of bringing instances up and down isn't that expensive. For Windows instances, you are always billed by the hour. * [2] Not that it matters much if one is limited to 10Gb/s or even 40Gb/s (if you can get it) EBS volumes. * The fastest throughput that I am aware of with EBS is 500MB/sec without doing RAID (https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-ebs-provisioned-iops-ssd--io1--volumes-now-support-32-000-iops-and-500-mbs-per-volume/ https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-eb...) Of course instance storage is faster (https://gist.github.com/ktheory/3c3616fca42a3716346b https://gist.github.com/ktheory/3c3616fca42a3716346b), but is that a thing people do for databases?

mmt 8y ago
> autoscaling saves money when your demand is really spikey Indeed. I've found the spikiness ratio (if that coined term makes sense) to be 2x-10x for AWS in general, and I was wondering if you (or anyone else) had a sense of how much that increased for these more premium services. > and even then you have to do a cost comparison. I have rarely seen this done, and, when I've talked to people attempting it, the common complaint is that AWS doesn't make it easy. > The fastest throughput that I am aware of with EBS is 500MB/sec without doing RAID Yes, per volume. I was, perhaps, too terse in my footnote. I was referring to the maximum throughput per EC2 node. Considering 40Gb/s would be saturated by about 10 of these, that's not very much. Real hardware can handle quite a bit more than 10 such SSDs attached. > Of course instance storage is faster (https://gist.github.com/ktheory/3c3616fca42a3716346b https://gist.github.com/ktheory/3c3616fca42a3716346b), but is that a thing people do for databases? I would hope so, but probably not in general practice, as it would require too much specialized knowledge. The main problems are that it's ephemeral and very limited in quantity. The impact of the former is reduced by the latter, of course.
- 8y ago