EC2 Offering "MySQL Cloud"

joshk's picture

Today Amazon announced a provided service for hosting MySQL databases in the cloud: Amazon Relational Database Service. It starts at $0.11/hr, plus $0.10 per GB/month of storage and $0.10 per million I/O requests. The real interesting question is how these will perform. The instances come in many flavors:

  • Small: 1.7 GB memory, 1 virtual core with 1 ECU. $0.11/hr
  • Large: 7.5 GB memory, 2 virtual cores with 2 ECUs each. $0.44/hr
  • Extra Large: 15 GB of memory, 4 virtual cores with 2 ECUs each. $0.88/hr
  • Double Extra Large: 34 GB of memory, 4 virtual cores with 3,25 ECUs each. $1.55/hr
  • Quadruple Extra Large: 68 GB of memory, 8 virtual cores with 3.25 ECUs each. $3.10/hr

That "Quadrupal XL" is pretty big! I'll be investigating this for Pantheon, but anyone else with experience/info, let's figure out how good these things really are!

Login to post comments

I did some digging and found

moshe weitzman's picture
moshe weitzman - Tue, 2009-10-27 23:20

I did some digging and found out that the default engine is InnoDB. You can choose to make tables with MyISAM if you want. Also, Amazon gives you a my.cnf which is tuned for your memory and CPU config. If you want to override config for your managed instance, you can. amazon discourages that, but the API is there.


More info

adub - Wed, 2009-10-28 00:11

There's some more info here, including why it could be better to stick with InnoDB - http://mysqlha.blogspot.com/2009/10/managed-mysql-amazon-rds.html


check the terms of service

alexberkman - Thu, 2009-10-29 15:28

5.16.3 You may store snapshots of Your Amazon RDS Content for later use in Amazon RDS but snapshots cannot be downloaded outside the Services.

I am not entirely sure what they mean by this, but it makes me nervous.


Standard

joshk's picture
joshk - Thu, 2009-10-29 17:15

They're using the same incremental snapshotting service as is used for EBS, which you can't download externally either. A single snapshot (being incremental) wouldn't be very useful anyway.

You can dump and export your data at any time.


There was a request on the

SeanBannister - Fri, 2009-10-30 02:17

There was a request on the AWS forums for Amazon to allow EBS snapshots to be downloaded. It wouldn't be hard for them to implement because they're just stored in S3. Feel free to chime in and offer support for this feature on the AWS forum: http://developer.amazonwebservices.com/connect/thread.jspa?messageID=99079


snapshots

bcmiller0 - Fri, 2009-10-30 01:13

What we do is use mysql replication to another machine (backup server), where we can down the database and then do a snapshot. This gives a true full snap shot of the data easily. we also do periodic dumps/exports and keep point in time files.

But amazon could do a snapshot from a replicated copy of the db server, and that would give you a usable copy the db would start from without complaints or issues on the data due to writes during snapshot.


I/O

chx's picture
chx - Fri, 2009-10-30 13:55

My understanding is that this service is only good if your dataset fits inside the RAM. If not, virtualized I/O will kill you.


We shall see

joshk's picture
joshk - Sat, 2009-10-31 00:05

This is generally the case with MySQL on EC2, but there are a lot of tips/tricks out there for setting the cloud up to improve I/O:

http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs/

Tips like this can improve things a lot, though depending on your application it may still simply be a non-starter. If you have a lot of random/hard queries, you will need the power of SAS or the like (and are better off looking at blended cloud options from Rackspace or Voxel).

I have no way of knowing, but my guess is that Amazon is tracking this, realizing they're losing customers due to poor I/O and optimizing their "relational data service" with customers like us in mind. These aren't conventional ec2 instances with mysql installed. Amazon is doing something different. What, they don't say, so we have to test to see how the speed is.


I haven't had a chance to

SeanBannister - Sat, 2009-10-31 02:32

I haven't had a chance to benchmark but my understanding is on smaller instances, and smaller EBS volumes you have more people sharing the I/O but on a larger instances and larger EBS volumes they can't slice them up as much so you have less shared I/O.