Recently I read in AnandTech a good article on Solid State Devices (SSD). It certainly blew away many misconceptions I had about SSD.
From a professional point of view, my main interest would be how databases are affected by the following characteristics of SSD:
- Both sequential and random reads are fast with a granularity of 4K. In other words, to modify 1 byte, you still have to write 4K.
- Writes require the block to be erased first. A block is typically 512K. That means if there are no erased (also called trimmed) blocks, you need to erase, and it is a s-l-o-w operation.
- You can only erase a block 10,000 times before it stops working.
- Good quality SSD controllers with onboard caches and highly parallel architectures make a big difference.
From this summary, it appears that the SSD is ideal for relatively static data, and we can selectively put certain parts of the database on SSD. Examples include:
- The typical publishing web-site, where articles and messages are rarely edited more than a few times.
- Systems with large amounts of static data, eg. multi-player online games such as the EVE Online case-study.
For transaction processing systems it depends on the usage. Assuming the blocks in a table are updated 10,000 times a day, the data distribution of updates is even across all records, and the table fits into 100 512K blocks, then the lifetime of the SSD for those blocks would be 100 days (this might be acceptable if SSD was sufficiently cheap). And even for data warehouse applications with relatively static data, B-tree index rebalancings will cause the frequent rewrites of indexes.
It also appears that operations characterized by sequential writes such as transaction logging should continue to be placed on hard disks.