Now all Amazon needs to do is make Aurora HIPAA compliant/offer to sign a BAA and the dump trucks full of money will be backing up in no time. Can I dream?
> Now all Amazon needs to do is make Aurora HIPAA compliant/offer to sign a BAA and the dump trucks full of money will be backing up in no time. Can I dream?
Amazon already signs BAAs that cover EC2 dedicated instances and S3. Or do you mean BAAs that cover Aurora specifically?
FWIW, unless you're already a rather large company with excess capacity in both the engineering and legal teams, I'd recommend skipping AWS entirely and using a company like Aptible (YC S'14) to handle hosting and compliance[0]. It's more or less like using Heroku, except you have all of the compliance requirements (including legal documentation) managed for you. Having tried both approaches myself, I can testify that the latter is by far the preferable alternative (and honestly cheaper in the long run).
[0] Like Heroku, Aptible uses AWS under the hood, so it's not really "skipping" AWS, but you never have to deal with it directly (and that's a good thing).
Relevant: we're evaluating Aurora as a storage mechanism for our software. Currently we're MariaDB.
Quick thoughts: speedy, nice throughput, good read/write speeds generally, but the query optimiser still needs some work.
More detail...
So, it's a pretty nice engine. Scales well, seems fairly bullet proof. You can alter instances and they go up and down in size nicely, reboots are handled gracefully (although it doesn't seem to give estimated timings, which is a mild irritation).
The optimiser seems to get a bit stuck on understanding what indexes to use for queries that involve multiple joins or more complex data structures. My guess is that this is because under it (from what I understand), it's basically DynamoDB with clever bells and whistles (if someone knows more or that that's incorrect, please feel free to jump in). Mostly though, it's quicker for the majority of queries.
Backup management is lovely, caching system seems pretty performant from current benchmarking.
The metrics panel is also pretty sweet for monitoring the things that you're going to care about in DB-land.
I'd say if you're running something sensible sized, and your data is relational but not massively complex, it's a pretty solid solution which I'm sure will only improve over time. That said, there are a few edge cases where you're going to have to do some work on your queries to make sure they still behave in a timely manner. Mostly, if you're using an ORM, this is where I suspect you're going to get some pain.
Any questions on specifics, feel free to fire away and I'll elaborate where I can.
I haven't used it but I did attend the talk on it at the AWS conference when it was announced.
It is not using DynamoDB under the covers. It basically uses a fork of MySQL for the front end and their own storage layer built from scratch on the backend. It does use concepts from the Dynamo white paper for redundantly storing the data to disk which removes the need for MySQL style replication. But it's not using the DynamoDB service currently offered from Amazon.
11 comments
[ 5.8 ms ] story [ 38.4 ms ] threadAmazon already signs BAAs that cover EC2 dedicated instances and S3. Or do you mean BAAs that cover Aurora specifically?
FWIW, unless you're already a rather large company with excess capacity in both the engineering and legal teams, I'd recommend skipping AWS entirely and using a company like Aptible (YC S'14) to handle hosting and compliance[0]. It's more or less like using Heroku, except you have all of the compliance requirements (including legal documentation) managed for you. Having tried both approaches myself, I can testify that the latter is by far the preferable alternative (and honestly cheaper in the long run).
[0] Like Heroku, Aptible uses AWS under the hood, so it's not really "skipping" AWS, but you never have to deal with it directly (and that's a good thing).
Working on Aurora...
Not sure if HN has the logic to be able to detect identical posts and reject or merge automagically.
Quick thoughts: speedy, nice throughput, good read/write speeds generally, but the query optimiser still needs some work.
More detail...
So, it's a pretty nice engine. Scales well, seems fairly bullet proof. You can alter instances and they go up and down in size nicely, reboots are handled gracefully (although it doesn't seem to give estimated timings, which is a mild irritation).
The optimiser seems to get a bit stuck on understanding what indexes to use for queries that involve multiple joins or more complex data structures. My guess is that this is because under it (from what I understand), it's basically DynamoDB with clever bells and whistles (if someone knows more or that that's incorrect, please feel free to jump in). Mostly though, it's quicker for the majority of queries.
Backup management is lovely, caching system seems pretty performant from current benchmarking.
The metrics panel is also pretty sweet for monitoring the things that you're going to care about in DB-land.
I'd say if you're running something sensible sized, and your data is relational but not massively complex, it's a pretty solid solution which I'm sure will only improve over time. That said, there are a few edge cases where you're going to have to do some work on your queries to make sure they still behave in a timely manner. Mostly, if you're using an ORM, this is where I suspect you're going to get some pain.
Any questions on specifics, feel free to fire away and I'll elaborate where I can.
It is not using DynamoDB under the covers. It basically uses a fork of MySQL for the front end and their own storage layer built from scratch on the backend. It does use concepts from the Dynamo white paper for redundantly storing the data to disk which removes the need for MySQL style replication. But it's not using the DynamoDB service currently offered from Amazon.