Hacker News new | past | comments | ask | show | jobs | submit login

Just a quick datapoint for you on EC2 vs SSD... we tried restoring a 30GB pgsql database to a Large EC2 with RAID0'd EBS stores for testing purposes. It took ~4 days.

I tried doing the same thing on a Macbook Pro i7/SSD and it took ~1 hour.

EBS disk performance is reliable, but miserable.




EBS disk performance is reliable, but miserable.

EBS performance is unreliable and miserable. There, fixed that for you.

However, EBS also has a couple things going for it. Namely: easy snapshots, fast/seamless provisioning (need another 1T?), mobility (need that volume on another instance?) and quite a fair price point when you take all that into account.


easy snapshots, fast/seamless provisioning (need another 1T?)

All of which are doable with LVM.


Sure, within the boundaries of your disk array. Assuming a non-trivial size you'll need 1-2 fulltime people to run and scale that array, plus a nice chunk of investment into hardware.

EBS is just a mouse-click.


If you are so unconcerned with your storage that you're just mouse clicking around EBS setups, you don't' need 1-2 full-time people to run an array.


Sounds like you've never dealt with storage at scale.

It's far from "rack and forget" once you've grow beyond 2 racks.


I think you read the opposite of what I was trying to say.

I have dealt with storage 'at scale' enough to require a full team of storage people.

Some guy clicking buttons on the Amazon website is usually not a very effective way of dealing with storage 'at scale'.


Yes, sorry for reading you backwards.

However I maintain that EBS has it's place in a wide range of applications where raw I/O performance isn't the main concern (e.g. archival).


EBS disk performance is unacceptable for high scalability applications.

There I said it!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: