Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by cookiecaper on Saturday September 03, 2016 @12:03AM
(#12417652)
We've switched 6 or 7 of our production databases to Aurora now. It is much faster than MySQL/Percona Server. Even highly optimized MySQL installs with FusionIO cards struggled to keep up before we switched to Aurora.
Aurora is expensive, but it's a huge instant speedup and easily worth the cost for anyone with a production application that occasionally hits performance limitations on traditional MySQL.
That said, it is based on MySQL 5.6.10, so we are missing some features like online DDL from 5.6.17. Many bugs from 5.6.10 have been resolved upstream but are still present in Aurora. [0] It's also subject to the usual limitations of RDS (no SUPER, no access to the binary database files, no innobackupex).
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by ralusek on Friday September 02, 2016 @06:16PM
(#12416657)
Cool, although I sure wish they had gone with Postgres. I can't live without the occasional JSONB anymore.
I know MySQL has made some half-hearted attempts to make headway on this front, but it has completely changed the way I model certain parts of my data.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by Scarbutt on Friday September 02, 2016 @06:26PM
(#12416706)
I can't live without the occasional JSONB anymore.
Some can't live without Aurora anymore ;) - they start their projects with MySQL(even thought they prefer Postgresql) to be Aurora compatible, just in case they need it.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by pinouchon on Friday September 02, 2016 @07:45PM
(#12417011)
I'm curious what are the reasons some people "can't live without Aurora anymore". I would love to hear specific benefits of Aurora, regarding performance or other aspects.
The comparisons I could find didn't seem to be very favorable to Aurora (mainly that the claimed 5x improvement does not show up in the benchmarks)
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by brightball on Friday September 02, 2016 @09:14PM
(#12417226)
I moved a 60GB database too it last year that we had setup multi AZ.
We cut our costs by about 40% after the switch and saw about a 20% boost in speed. RAM usage was lower too.
One of the biggest savings is that you don't need multiAZ since your data is stored redundantly. You don't have to worry about failover because the restart time is < 1 minute anyway. The other thing is that I can stop having to keep an eye on disk usage (and paying for unused space) since it just grows as needed automatically.
The man hours alone that we used to put into actively watching and tuning that DB have just vanished as has almost the entire sysadmin burden. That project was already on MySQL too which made it an easy move too.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by ngrilly on Saturday September 03, 2016 @05:59AM
(#12418564)
Aurora being a closed-source fork of MySQL is a real problem in my opinion.
Look at all the comments here about new features and bug fixes introduced upstream but missing in 5.6.10 (online DDL, JSON, etc.).
We already have Oracle's MySQL, MariaDB, WebScaleSQL, MyRocks (Facebook's MySQL with RocksDB and DocStore), Percona Server for MySQL, and now Aurora. Each version has its own features and peculiarities. The ecosystem is too much scattered.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by cookiecaper on Saturday September 03, 2016 @12:00AM
(#12417647)
Aurora is a modified MySQL 5.6.10. It shares several bugs with 5.6.10 that have already been fixed in later versions of MySQL. My understanding is that it mostly remains unchanged other than the massive enhancements Amazon has made to the I/O performance.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by pmontra on Saturday September 03, 2016 @03:33AM
(#12418171)
MySQL compatible means that moving from MySQL to Aurora is transparent to the application, included all the MySQL (InnoDB?) peculiarities, which many regard as bugs?
This could be really important because some applications end up relying on MySQL oddities even with good willed developers.
Re:Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA...
by dhd415 on Saturday September 03, 2016 @06:29PM
(#12421559)
CitusDB is an option for scaling out PostgreSQL workloads, but it's not a direct equivalent to Aurora. That's both good and bad in different ways. E.g., it's good that CitusDB is not a fork of PostgreSQL as Aurora is a fork of MySQL. It's bad that CitusDB as pure software can't offer the same kind of high-performance, auto-replicated storage layer that Aurora does.
Aurora is expensive, but it's a huge instant speedup and easily worth the cost for anyone with a production application that occasionally hits performance limitations on traditional MySQL.
That said, it is based on MySQL 5.6.10, so we are missing some features like online DDL from 5.6.17. Many bugs from 5.6.10 have been resolved upstream but are still present in Aurora. [0] It's also subject to the usual limitations of RDS (no SUPER, no access to the binary database files, no innobackupex).
[0] https://www.percona.com/blog/2015/11/16/amazon-aurora-lookin...
I know MySQL has made some half-hearted attempts to make headway on this front, but it has completely changed the way I model certain parts of my data.
Unless you mean that the other way around, in which case I don't know what key features of Aurora I'm missing (besides price & performance).
Some can't live without Aurora anymore ;) - they start their projects with MySQL(even thought they prefer Postgresql) to be Aurora compatible, just in case they need it.
The comparisons I could find didn't seem to be very favorable to Aurora (mainly that the claimed 5x improvement does not show up in the benchmarks)
We cut our costs by about 40% after the switch and saw about a 20% boost in speed. RAM usage was lower too.
One of the biggest savings is that you don't need multiAZ since your data is stored redundantly. You don't have to worry about failover because the restart time is < 1 minute anyway. The other thing is that I can stop having to keep an eye on disk usage (and paying for unused space) since it just grows as needed automatically.
The man hours alone that we used to put into actively watching and tuning that DB have just vanished as has almost the entire sysadmin burden. That project was already on MySQL too which made it an easy move too.
I wish they'd do something similar for PG too.
Look at all the comments here about new features and bug fixes introduced upstream but missing in 5.6.10 (online DDL, JSON, etc.).
We already have Oracle's MySQL, MariaDB, WebScaleSQL, MyRocks (Facebook's MySQL with RocksDB and DocStore), Percona Server for MySQL, and now Aurora. Each version has its own features and peculiarities. The ecosystem is too much scattered.
Aurora is based on MySQL 5.6.
They had a deep dive into during the last re:invent.
https://www.youtube.com/watch?v=CwWFrZGMDds
Also a good bit of video of Vogels talking about Aurora.
https://www.youtube.com/watch?v=0rPpCnFE-hU&feature=youtu.be...
This could be really important because some applications end up relying on MySQL oddities even with good willed developers.