Re:You Are Not Google (2017)
by davidjnelson on Friday April 05, 2019 @12:30AM
(#19579700)
The big innovation of aurora is they decoupled the compute from the storage [1]. Both compute and storage need to auto scale, but compute is the really important one that is hardest. Aurora serverless scales the compute automatically by keeping warm pools of db capacity around [2]. This is great for spiky traffic without degraded performance.
1. https://www.allthingsdistributed.com/files/p1041-verbitski.p... 2. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
Re:You Are Not Google (2017)
by scarface74 on Thursday April 04, 2019 @09:14PM
(#19578739)
No, it’s not just the bandwidth. It’s also the CPU for read and writes in the case of Serverless Aurora.
For regular autoscaling of read replicas. It brings additional servers on line using the same storage array. It isn’t just “one database”.
That’s just it. There isn’t “just one database”.
Re:You Are Not Google (2017)
by davidjnelson on Friday April 05, 2019 @12:05AM
(#19579600)
Cloud spanner seems awesome but has a base price of $740/mo, doesn’t seem to autoscale, and doesn’t support a mysql or postgres interface.
By the way what is autoscaling and why are we autoscaling databases? Im guessing the only resource thst autoscales is the bandwidth? Why can't we all get shared access to a fat pipe in production? I was under the impression that products like Google Cloud Spanner have this figured out. What exactly needs to auto scale? Isn't there just one database server in production?
In dev (which is the use case I'm talking about) you should be able to just reset the vm whenever you want, no?