
Design Considerations for High-Throughput Cloud-Native RDBMS [pdf] - yarapavan
http://allthingsdistributed.com/files/p1041-verbitski.pdf
======
stevev
One of the biggest reasons why we left Aurora for an rds solution was that
basic ddl operations like table alters would fail to work on db sizes greater
than 2TB. Such operations required double the amount of disk storage for
copying. We were forced to solutions like github Ghost or Percona if we wanted
to stick with Aurora. After thoroughly testing these solutions, it would take
close to a month to perform such an operation on large tables. An rds solution
only took a few days. I recommend a pure rds solution for db sizes greater
than 1tb.

~~~
willvarfar
This has always frustrated me.

The big reason that DDL is slow is because these systems haven't tried to make
it fast.

This is, of course, a contary opinion so hear me out before judging me ;)

My thinking is thus:

There are lots of virtual storage engines in the mysql world such as
'federated' and 'spider' and 'union' and such. These actually abstract away
more than one data-source, and often the engine is smart enough to support
when the data sources don't have identical schema.

These virtual storage engines demonstrate that a layer of abstraction can cope
with casting queries across more than one non-identical tables.

So, either built in or as a storage engine abstraction, databases _could_
support DDL changes by putting rows with each version of the schema into
actually different tables, and casting queries across them etc transparently.

Another approach is that taken by the postgres engine, where each row has a
version and some DDL such as add column with default null can be done
instantly. (With a bit more thought, even defaults could have been coped with
instantly; its a shame they weren't.)

So, blame the DB designers!

~~~
ddorian43
From a high level things look doable, but going deep in the c/c++, they're
not.

~~~
willvarfar
I poke around in mysql storage engine code, among other things, and its
entirely doable. It just needs to be a goal. Wish it was on my day job list of
things I can work on. I hope someone else has an itch that needs scratching.

------
ignoramous
The Aurora team at Amazon subsequently published _Amazon Aurora: On Avoiding
Distributed Consensus for I /Os, Commits, and Membership Changes_

[https://dl.acm.org/citation.cfm?id=3196937](https://dl.acm.org/citation.cfm?id=3196937)

~~~
Artemis2
There is also a series of posts regarding the design of Aurora on the AWS
blog, although about everything is described in the original paper:

[https://aws.amazon.com/blogs/database/amazon-aurora-under-
th...](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-
quorum-and-correlated-failure/)

[https://aws.amazon.com/blogs/database/amazon-aurora-under-
th...](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-
quorum-reads-and-mutating-state/)

[https://aws.amazon.com/blogs/database/amazon-aurora-under-
th...](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-
reducing-costs-using-quorum-sets/)

[https://aws.amazon.com/blogs/database/amazon-aurora-under-
th...](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-
quorum-membership/)

------
tirumaraiselvan
No mention of connection pooling? Does Aurora handle 1000s of concurrent
connection considering it is cloud-native?

~~~
wgjordan
Yes, Aurora has connection pooling that allows it to scale to thousands of
concurrent connections:

> Amazon Aurora for MySQL comes with internal server connection pooling and
> thread multiplexing, which helps reduce contention and improve scalability
> when dealing with thousands of concurrent connections. You can configure
> each Aurora DB instance to allow up to 16,000 concurrent connections.

[https://aws.amazon.com/blogs/database/planning-and-
optimizin...](https://aws.amazon.com/blogs/database/planning-and-optimizing-
amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/)

~~~
etaioinshrdlu
I had an issue where Aurora MySQL would refuse connections above 1000 even
though Max Connections was configured several times higher.

Most of the connections were idle too.

Any pooling they are doing is not very effective.

The product is pretty disappointing.

------
hdpq
curious, why is this paper just now making the front page of this site? it's
been published several years ago.

~~~
kondro
Probably renewed interest caused by the Mongo/DocumentDB drama.

