Monday, October 19, 2015

raid - Scaling databases with cheap SSD hard drives

I hope that many of you are working with high traffic database-driven websites, and chances are that your main scalability issues are in the database. I noticed a couple of things lately:





  1. Most large databases require a team of DBAs in order to scale. They constantly struggle with limitations of hard drives and end up with very expensive solutions (SANs or large RAIDs, frequent maintenance windows for defragging and repartitioning, etc.) The actual annual cost of maintaining such databases is in $100K-$1M range which is too steep for me :)


  2. Finally, we got several companies like Intel, Samsung, FusionIO, etc. that just started selling extremely fast yet affordable SSD hard drives based on SLC Flash technology. These drives are 100 times faster in random read/writes than the best spinning hard drives on the market (up to 50,000 random writes per second). Their seek time is pretty much zero, so the cost of random I/O is the same as sequential I/O, which is awesome for databases. These SSD drives cost around $10-$20 per gigabyte, and they are relatively small (64GB).




So, there seems to be an opportunity to avoid the HUGE costs of scaling databases the traditional way by simply building a big enough RAID 5 array of SSD drives (which would cost only a few thousand dollars). Then we don't care if the database file is fragmented, and we can afford 100 times more disk writes per second without having to spread the database across 100 spindles. .



Is anybody else interested in this? I've been testing a few SSD drives and can share my results. If anybody on this site has already solved their I/O bottleneck with SSDs, I would love to hear your war stories!



PS. I know that there are plenty of expensive solutions out there that help with scalability, for example the time proven RAM-based SANs. I want to be clear that even $50K is too expensive for my project. I have to find a solution that costs no more than $10K and does not take much time to implement.







Dave, NXC, and Burly,



Thanks for your replies! I'd like to clarify that the word "cheap" is very important in my situation. So, I have to use cheap Dell servers ($4K 2950s that have only 8 memory banks). I already have 32GB of RAM installed, so I cannot keep scaling this way. Besides, adding RAM does not save you from disk WRITE bottlenecks, which is my main problem right now.



I used to be concerned with lifetime of SSDs, but after reading about the modern wear leveling algorithms I am pretty sure that these drives will last long enough. My database writes 300GB per day, and projected to go over 1TB per day in 2009. The Enterprise SSDs are designed to handle around 10TB of writes per day over multiple years.



I would disagree with Burly's point that it takes too much labor to migrate from SAS to SSD. My database is a synchronous mirror, so I can upgrade one side of the mirror, then watch it for a few months, and if it blows I can failover to the second server which still has the old good SAS hard drives...

No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...