【IT168 评论】

　　关于SSD

　　去年，我们曾经使用了一批SSD的PC，用来做数据库的服务器，用来提高数据库服务器的IO能力。但是从目前的使用情况来看，如果将SSD作为主存储，存在一些问题：

　　首先，SSD的稳定性还不够好，我们碰到了一些SSD盘损坏和SSD与机器不兼容的情况发生。

　　第二，SSD的容量盘都比较小，考虑到稳定性的问题，如果做RAID会进一步损失容量，性价比不高。

　　第三，SSD属于NAND类型的flash，写操作不仅会产生“磨损”，而且随着碎片的不断增加，写操作的性能会不断下降。

　　目前看来，SSD并不太适合作为数据库的主存储，写操作并不是SSD的特长，而且作为主存储的代价过高，SSD更加适合作为内存和磁盘之间的一层cache，降低读操作的延迟时间，我们将其称为flash cache。Oracle 11g R2中就提供了这样的功能，Oracle exadata V2配置了flash卡用来做flash cache，可以提供非常高的IOPS。对于MySQL数据库，Google和Facebook都提出了基于MySQL数据库的解决方案。

　　将SSD和Flash卡配置在PC服务器上，与普通SAS或者SATA磁盘混插，采用数据库flashcache技术，可以达到一个非常理想的性能，代价又不是特别高，我们也在考虑采用MySQL的flashcache架构。但是，如果你采用大型的存储设备，比如EMC和HDS，存储的cache实际上已经起到了一个二级缓存的作用，就没有太多必要使用SSD或者Flash卡了。

　　使用SSD还可以解决写操作的响应延迟，比如Oracle数据库的redo，因为每次commit都必须物理写入到磁盘上，所以将redo放在SSD上，可以提高写的响应延迟，但是不必将数据文件放在SSD上，因为他们并不是必须被写入的。这里要注意的是，SSD可能出现随着大量的写操作性能下降的情况。在我们的测试中，SLC的写能力比较稳定，而MLC的写能力会出现下降的情况。

　　SSD一定有光明的未来，取代磁盘只是个时间问题，只是我们还需要等待技术更加成熟，价格更加便宜。

　　关于可扩展的数据库架构

　　数据库分片(Sharding)是最简单实用的方案之一，将一个集中式的数据库拆分为很多小的数据库，从而获取数据库横向扩展的能力。但是，Sharding也带来一些问题：第一，应用可能需要进行大幅度的修改，以适应数据库拆分的变化。我们通过数据库代理软件来解决应用透明访问的问题，比如Amoeba，让数据库对应用透明，从而降低应用修改的复杂程度。第二，Sharding带来了一些应用上的限制，比如join，复杂查询和事务，要想解决这个问题比较困难，但是我们可以选择在适当的应用场景来使用，比如：在我们实际的应用场景中，绝大部分压力来自于商品，订单，交易等这类应用，其特点是：访问简单，数据量大，查询压力大。这类应用往往占到系统85%以上的压力，他们是非常适合做数据库拆分的。还有些应用是不适合做拆分的，比如一些查询复杂，事务要求高的应用，采用集中式数据库是比较合适的。

　　我们通过应用场景的不同，选择不同的方案，既可以降低数据库压力，又可以降低应用的复杂程度。

　　还有一种常见的解决方案，在数据库前端增加一层cache，比如内存数据库，搜索引擎，KVcache等等，属于读写分离架构的一种，通过cache层有效缓解数据库的读压力，提高整个系统的处理能力。在这种架构中，由cache层承载了大量的数据访问，而数据库则退化为一个单纯的数据存储。在我们的系统架构中，就大量使用了memcache作为数据库的外部cache，淘宝也开发了自己的分布式KV cache(Tair)。

　　作为DBA来说，我们也常常使用数据本身的功能去解决问题，比如Partition功能，但是它依然受限于单个database的处理能力，如果我们预期到单一数据库可能产生性能瓶颈时，就需要考虑借助一些应用架构去解决问题，而不是总是局限在数据库本身的功能上。