SSD作为写cache-append write

　　SSD可以作为磁盘的写cache，因为SSD连续写比随机写性能好，比如：1M顺序写比128个8K的随机写要好很多，我们可以将大量随机写合并成为少量顺序写，增加IO的大小，减少IO(擦除)的次数，提高写入性能。这个方法与很多NoSQL产品的append write类似，即不改写数据，只追加数据，需要时做合并处理。

　　基本原理：当dirty block需要写入到数据文件时，并不直接更新原来的数据文件，而是首先进行IO合并，将很多个8K的dirty block合并为一个512KB的写入单元，并采用append write的方式写入到一个cache file中（保存在SSD上），避免了擦除的动作，提高了写入性能。cache file中的数据采用循环的方式顺序写入，当cache file空间不足够时，后台进程会将cache file中的数据写入到真正的数据文件中（保存在磁盘上），这时进行第二次IO合并，将cache file内的数据进行合并，整合成为少量的顺序写入，对于磁盘来说，最终的IO是1M的顺序写入，顺序写入只会影响吞吐量，而磁盘的吞吐量不会成为瓶颈，将IOPS的瓶颈转化为吞吐量的瓶颈，从而提升了整体系统能力。

　　读取数据时，必须首先读取cache file，而cache file中的数据是无序存放的，为了快速检索cache file中的数据，一般会在内存中为cache file建立一个索引，读取数据时会先查询这个索引，如果命中查询cache file，如果没有命中，再读取data file（普通磁盘），所以，这种方法实际不仅仅是写cache，同时也起到了读cache的作用。

　　但是这种方法并不适合日志文件的写cache，虽然日志文件也是append write，但是因为日志文件的IO size比较小，而且必须同步写入，无法做合并处理，所以性能提升有限。

　　SSD作为读cache-flashcache

　　因为大部分数据库都是读多写少的类型，所以SSD作为数据库flashcache是优化方案中最简单的一种，它可以充分利用SSD读性能的优势，又避免了SSD写入的性能问题。实现的方法有很多种，可以在读取数据时，将数据同时写入SSD，也可以在数据被刷出buffer时，写入到SSD。读取数据时，首先在buffer中查询，然后在flashcache中查询，最后读取datafile。

　　SSD作为flashcache与memcache作为数据库外部cache的最大区别在于，SSD掉电后数据是不丢失的，这也引起了另外一个思考，当数据库发生故障重启后，flashcache中的数据是有效还是无效？如果是有效的，那么就必须时刻保证flashcache中数据的一致性，如果是无效的，那么flashcache同样面临一个预热的问题（这与memcache掉电后的问题一样）。目前，据我所知，基本上都认为是无效的，因为要保持flashcache中数据的一致性，非常困难。

　　flashcache作为内存和磁盘之间的二级cache，除了性能的提升以外，从成本的角度看，SSD的价格介于memory和disk之间，作为两者之间的一层cache，可以在性能和价格之间找到平衡。

　　总结

　　随着SSD价格不断降低，容量和性能不断提升，SSD取代磁盘只是个时间问题。