Separating the storage layer from the database and query layer seems to be the future of databases - there's no reason for every database to re-implement the storage and replication layer just to provide a different query language or data model. This is also what makes FoundationDB so attractive for me. Are there any other large projects doing this?
> But here in the paper, it compares Aurora to a MySQL synchronous mirroring setup, which is really unfair, IMO. Why the active primary has to replicate everything over the wire to the active standby? Doesn't MySQL's replication support Statement-Based Replication?<p>The comparison in the paper is against the synchronous-mirroring pattern underlying RDS Multi-AZ [1], which is the existing fully-managed, high-availability MySQL solution Amazon offers, so the direct comparison is appropriate for existing RDS Multi-AZ users considering a migration to Aurora.<p>[1] <a href="https://aws.amazon.com/blogs/database/amazon-rds-under-the-hood-multi-az/" rel="nofollow">https://aws.amazon.com/blogs/database/amazon-rds-under-the-h...</a>
One of the neat things about aurora is there is a very small slave lag between the primary and read replicas. If you only have a single thread doing replication then you can easily have a situation where a multi-cpu master can get ahead of a slave only using a single thread. Lazily materializing the pages gives aurora 'parallel replication' for free. I think Mysql supports parallel replication now but I think it is limited if transactions conflict [<a href="https://mariadb.com/kb/en/library/parallel-replication/" rel="nofollow">https://mariadb.com/kb/en/library/parallel-replication/</a>].<p>Another thing I noticed with Aurora is the incremental cost of storage for Aurora is extremely cheap compared to the cost of storage in EBS or the cost of storage if you used instance storage in EC2. The Aurora storage is 0.1/GB but this is replicated 6 times which is more than EBS and EBS costs the same 0.1/GB. This also might be why no-one is going to build a similar system to Aurora. It will be hard to sell something like Aurora to cloud users because the storage costs are going to more than what EC2 charges.
Funny how the CQRS circle closes: it is an architectural design that overhauls some concepts of database design (the redo log, views) into the application layer (for some, to the extreme of reducing the database to a simple log.) And now this same separation is appearing in a DBMS design :)
I'm wondering how aurora would behave with queries mixing read and write.<p>For example, with something like "INSERT INTO my_table(field1, field2, field3, ...) SELECT f1, f2, f3... from root_table WHERE ...", I'm wondering how it will spread the load across nodes.
Everything is faster when you move your data to ebs \s.<p>Though google has done this for all databases (at least their internal ones) (even bigtable). And some companies say they can do it for nvme & ram.<p>You just need real-good networking and some type of asic and removing kernel from the path.