4 ms·

On average, the price of NAND flash memory drops 40 percent per year. This is good news for databases. Flash drives have much better random access performance

On average, the price of NAND flash memory drops 40 percent per year. This is good news for databases. Flash drives have much better random access performance than magnetic drives. With the price of these flash drives dropping, it will soon be cost-effective to replace an entire database with flash for the IOPS increase. Right now people are using flash for extra cache, but soon we'll be able to fit the whole database in flash for a reasonable $/IOPS. It will extend the life of single-instance databases significantly, and mean everyone can wait that much longer before distributing the database.

ghshephard 16y ago
Isn't the rule "If you touch it more than once a day, move it to flash, if you touch it more than once an hour, move it to RAM?" That is, for data which is touched daily, it's already less expensive to use flash than magnetic drives. The problem with Hard Drives is that in order to get the IOPs, we always end up buying a _ton_ of drives, plus the chassis to support those drives, plus the licenses to support the amount of storage represented by those drives, etc, etc, ...
- Periodic 16y ago
  I haven't done the cost analysis lately, but what this does is bring more IOPS in at a lower price point. The cost of RAM is not static, the more you have the more expensive it gets because you need better motherboards and specialized chassis to handle it and really manage all those buses. SSDs bring in an intermediate point between magnetic disks and RAM so that you can get some more IOPS in at that lower price point. Of course, if you need all you can get you should always go for just RAM, but you can get a significant improvement with a modest investment through SSDs. The best example would be the large data set (say 100GB with a random access pattern or 100GB of working set) with enough requests that it starting to strain the RAID system you have. At this point your medium is saturated so latency is going up and up. Getting 128 GB of RAM is expensive, but swapping those drives out for a few 100GB SSDs is not hard and may alleviate the DB bottle-neck until something else becomes the bottle-neck and you need to change that anyway. Switching to RAM wouldn't have bought you anything more than the SSDs because in both cases you are getting acceptable performance up to the next bottleneck. I'd like to think that SSDs will get us to the point that we don't have to worry about disk latency and can just toss data on there without having the database always be the bottleneck.
nphase 16y ago
I recently replaced the SAS drives in all of my database servers with SSDs. Watching IO wait on my usage graphs drop while db latency fell to near-0ms was such an incredibly gratifying feeling. Worth every penny. If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1] [1] http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/ http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-m...
- joevandyk 16y ago
  I wonder if Amazon's EBS will support SSD anytime soon. That would rock.
  - fredoliveira 16y ago
    It's quite impractical for them to "support" SSD. The way (I assume) their infrastructure works would basically mean that the speedup you get from SSD would be nullified by the rest of the IO needs imposed by their stack. That is, if they were to simply move one service (in this case, EBS) to SSD. The only way I see this happening is if they start adding servers with SSD, where all services running on those servers support SSD too. This would basically mean a separate cluster, fully based on SSD. I don't see this happening soon.
    - lyime 16y ago
      They don't have to move to support EBS with SSD and mix and match. They could have RDS instances with SSD only option and EBS based on SSD. They can charge significant amount for those options, some might even pay for it.
hyuen 16y ago
While SSDs are wonderful for random reads, writes are still very expensive due to their large erase blocks. In a small write (typical OLTP workload), the entire block has to be rewritten --typically 128kB-- even if the modified data is much smaller. That's why it is very important to make the application aware of this fact, or use a log-structured filesystem on top of it. I believe that for most web applications the ratio is 80% reads, 20% writes, that's why no one has noticed this behavior. Another even more concerning issue is the wear-out, SSD cells can't take more than ~10000 rewrites. While there is firmware taking care of invalidating those blocks, eventually we can expect data loss if not backed up properly. I think SSDs are great, as long as we understand their limits... For my laptop I have one and I love it, but I would be seriously doubtful about the safety of my information in some database using purely SSDs.
- pmjordan 16y ago
  For servers, you'd typically choose SLC Flash rather than the cheaper MLC. The memory cells survive about an order of magnitude more flash cycles and are also slightly faster. Also, I hope you're not assuming that your data is safe on the only component with critical moving parts in a modern computer...

ghshephard 16y ago

Isn't the rule "If you touch it more than once a day, move it to flash, if you touch it more than once an hour, move it to RAM?" That is, for data which is touched daily, it's already less expensive to use flash than magnetic drives. The problem with Hard Drives is that in order to get the IOPs, we always end up buying a _ton_ of drives, plus the chassis to support those drives, plus the licenses to support the amount of storage represented by those drives, etc, etc, ...

Periodic 16y ago
I haven't done the cost analysis lately, but what this does is bring more IOPS in at a lower price point. The cost of RAM is not static, the more you have the more expensive it gets because you need better motherboards and specialized chassis to handle it and really manage all those buses. SSDs bring in an intermediate point between magnetic disks and RAM so that you can get some more IOPS in at that lower price point. Of course, if you need all you can get you should always go for just RAM, but you can get a significant improvement with a modest investment through SSDs. The best example would be the large data set (say 100GB with a random access pattern or 100GB of working set) with enough requests that it starting to strain the RAID system you have. At this point your medium is saturated so latency is going up and up. Getting 128 GB of RAM is expensive, but swapping those drives out for a few 100GB SSDs is not hard and may alleviate the DB bottle-neck until something else becomes the bottle-neck and you need to change that anyway. Switching to RAM wouldn't have bought you anything more than the SSDs because in both cases you are getting acceptable performance up to the next bottleneck. I'd like to think that SSDs will get us to the point that we don't have to worry about disk latency and can just toss data on there without having the database always be the bottleneck.

nphase 16y ago

I recently replaced the SAS drives in all of my database servers with SSDs. Watching IO wait on my usage graphs drop while db latency fell to near-0ms was such an incredibly gratifying feeling. Worth every penny. If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1] [1] http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/ http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-m...

joevandyk 16y ago
I wonder if Amazon's EBS will support SSD anytime soon. That would rock.
- fredoliveira 16y ago
  It's quite impractical for them to "support" SSD. The way (I assume) their infrastructure works would basically mean that the speedup you get from SSD would be nullified by the rest of the IO needs imposed by their stack. That is, if they were to simply move one service (in this case, EBS) to SSD. The only way I see this happening is if they start adding servers with SSD, where all services running on those servers support SSD too. This would basically mean a separate cluster, fully based on SSD. I don't see this happening soon.
  - lyime 16y ago
    They don't have to move to support EBS with SSD and mix and match. They could have RDS instances with SSD only option and EBS based on SSD. They can charge significant amount for those options, some might even pay for it.

hyuen 16y ago

While SSDs are wonderful for random reads, writes are still very expensive due to their large erase blocks. In a small write (typical OLTP workload), the entire block has to be rewritten --typically 128kB-- even if the modified data is much smaller. That's why it is very important to make the application aware of this fact, or use a log-structured filesystem on top of it. I believe that for most web applications the ratio is 80% reads, 20% writes, that's why no one has noticed this behavior. Another even more concerning issue is the wear-out, SSD cells can't take more than ~10000 rewrites. While there is firmware taking care of invalidating those blocks, eventually we can expect data loss if not backed up properly. I think SSDs are great, as long as we understand their limits... For my laptop I have one and I love it, but I would be seriously doubtful about the safety of my information in some database using purely SSDs.

pmjordan 16y ago
For servers, you'd typically choose SLC Flash rather than the cheaper MLC. The memory cells survive about an order of magnitude more flash cycles and are also slightly faster. Also, I hope you're not assuming that your data is safe on the only component with critical moving parts in a modern computer...