Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness • Hacker News Board

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#21

Post by cookiecaper » Sat, Sep 03, 2016, 4:07 AM UTC

s0l1dsnak3123 wrote: post #5

ralusek wrote: post #2

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.

I second this. I'd switch over from RDS to Aurora in a heartbeat if AWS built a postgres frontend for it.

Aurora is part of RDS. It's just a different DB instance type.

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#22

Post by pmontra » Sat, Sep 03, 2016, 7:33 AM UTC

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 Awareness

#23

Post by ksec » Sat, Sep 03, 2016, 7:54 AM UTC

Any Equivalent for Postgre?

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#24

Post by malloryerik » Sat, Sep 03, 2016, 7:58 AM UTC

Do you think that Aurora is a reason to start a new project with MySQL instead of Postgres? (Aurora starts at r3.large instances.)

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#25

Post by ngrilly » Sat, Sep 03, 2016, 9:53 AM UTC

malloryerik wrote: post #24

Do you think that Aurora is a reason to start a new project with MySQL instead of Postgres? (Aurora starts at r3.large instances.)

I'm not sure. compose.com, among others, offers PostgreSQL hosting with auto-scaling. But I ignore if they can match Aurora with 64 TB databases.

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#26

Post by ngrilly » Sat, Sep 03, 2016, 9:59 AM UTC

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 Awareness

#27

Post by dgllghr » Sat, Sep 03, 2016, 1:50 PM UTC

n00b101 wrote: post #4

Does this support column-oriented database designs?

No, but Redshift does.

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#28

Post by zmanian » Sat, Sep 03, 2016, 3:36 PM UTC

I remember Ed Kemmet saying that NUMA optimizations are patent encumbered and presumably licensed. Probably part of the reason this is closed source.

Re: Amazon Aurora: Parallel Read Ahead, Faster Indexing, NUMA Awareness

#29

Post by dhd415 » Sat, Sep 03, 2016, 10:29 PM UTC

ksec wrote: post #23

Any Equivalent for Postgre?

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.