关于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磁盘混插，采用数据库flash cache技术，可以达到一个非常理想的性能，代价又不是特别高，我们也在考虑采用MySQL的flash cache架构。但是，如果你采用大型的存储设备，比如EMC和HDS，存储的cache实际上已经起到了一个二级缓存的作用，就没有太多必要使用SSD或者Flash卡了。

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

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

   关于可扩展的数据库架构

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

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

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

   事实上，解决方案都不是孤立存在的，这几种方案经常混合在一起使用，比如Facebook的架构中，就是利用MySQL数据库和memcache，通过Sharding和读写分离等架构，从而使整个网站具备非常高的性能和扩展能力。我们在实际解决问题时，也是如此，从数据库本身的优化，数据库内做分区，数据库拆分，利用memcache作读写分离，多数据库中心架构等等。

   关于Oracle和MySQL

   Oracle更适合集中式数据库架构，而MySQL数据库更适合分布式架构，在两种架构并存的环境下，我们用MySQL完全去替换Oracle是不现实的。

   从公司战略的角度出发，逐步降低对Oracle的依赖，这是一个大的方向和目标，但并不意味着我们需要把所有的应用都迁移到MySQL数据库上，从纯技术的角度分析，这并不合理。

   我对MySQL和Oracle的想法是：分布式架构采用MySQL数据库，保留核心的Oracle数据库，通过数据库拆分等手段，控制Oracle数据库的压力和规模(License)。集中式架构和分布式架构共存，MySQL和Oracle共存，用最适合的技术解决问题。

   关于小型机和存储

   虽然说近些年来PC服务器的性能得到了很大的提高，甚至已经超过了小型机，但是小型机也不是一无是处，在稳定性，管理性和维护性等方面，小型机都要比PC服务器高出不止一个档次。其缺点就是价格昂贵，容易对硬件厂商产生依赖。

   长远来看，我们要控制小型机使用的规模，但并不意味着要替换掉所有的小型机，对于核心应用的Oracle数据库，我认为小型机还是有价值的，起码在可用性方面有保证。对于MySQL数据库，我们大量采用PC服务器，配合数据库拆分和高可用架构，可以充分利用单台PC服务器的处理能力，又保证整个MySQL数据库集群的可用性。

   Oracle和MySQL数据库对于机器的选型也有差异，Oracle选择小型机或者比较高端的PC服务器，比如四路Intel 7500系列，最高可以配置四路六核或八核CPU，在性能上已经超过了我们使用的IBM小型机。MySQL则选择处理能力与IO能力均衡的服务器，通常会配置比较多的本地磁盘，比如双路Intel 5500或者5600系列，本地配置12-16块磁盘，甚至配置SSD或者flash卡。

   对数据库而言，存储设备非常重要，通常情况下，Oracle数据库会选择中高端的存储设备，而MySQL只配置PC服务器上本地磁盘或者低端的磁盘扩展柜。因为Oracle的高可用策略通常都要基于共享的存储设备实现(比如RAC，Veritas VCS等)，所以SAN存储几乎是必须的选择，而MySQL的高可用策略是基于复制的，并不需要共享的存储设备。(当然，Oracle也有data guard的方式，但是DG的切换过程复杂，需要人工干预，作为高可用策略并不适合，更多是作为一种容灾和备份的机制)。

   总的来说，硬件的选择与数据库本身的特性和应用架构有密切关系。从对主机的资源利用率上看，Oracle可以充分利用机器的计算能力，而MySQL对SMP架构的支持比Oracle差很多，单台MySQL数据库可能无法完全利用主机的处理能力，所以MySQL主机配置过多的CPU也是一种资源浪费。

   关于“去I/O/E”的策略(分别代表IBM，Oracle，EMC)，我个人的观点是“合理使用”，而不是为了去而去。不管是数据库的选择还是硬件的选择，我们的目标应该是不依赖于某个厂商，掌握主动权和话语权，这才是最重要的。

   关于NoSQL和Database

   NoSQL现在非常火，我也写了一些鸡毛蒜皮的文章介绍NoSQL，NoSQL的出现并不是为了替代database，而是在某些特定的领域内解决问题，所以每个NoSQL产品都有其鲜明的特点，相比之下，Database经过这么多年的发展，已经发展成为非常成熟的商业产品，而NoSQL现在大部分还处于成长的阶段。

   NoSQL产品的优势在于：扩展性，灵活的数据模型(非关系型)，大规模数据处理等方面，Database的优势在于：通用解决方案，成熟度，运维成本，使用成本等方面。我始终认为他们之间不是替代的关系，而是互补的关系，未来在Alibaba的使用场景中，Database应该还是首选的数据库处理和存储方案，但是在大规模的数据处理和数据仓库计算方面，NoSQL应该可以找到大量的应用场景。

   现在我们做技术方案时，往往面临很多选择，但是选择太多未必是件好事，我们在选择的过程中往往会加入个人的喜好，比如对某个技术的喜好和掌握程度，甚至为了证明某些能力，而选择一些并不熟悉的技术，虽然它非常先进，但可能并不适用。每种技术都有其存在的合理性，但是引入过多技术必然增加成本和风险，比如facebook，他们利用MySQL和memcache就解决了绝大部分的问题，而很火的cassandra，在facebook只是很小的一个应用而已。相比较而言，我们使用的技术要多得多，我建议在选择NoSQL和Database产品时，选择简单和成熟的技术方案，后期开发和运维成本都是需要考虑的。

   关于DBA

   DBA不应该仅仅局限于某个数据库产品，而应该更全面的了解开发架构方面的知识，甚至需要具备开发能力。

   DBA的价值不仅仅在于维护数据库本身，而应该在数据存储方案的选择上做出最专业的判断，这是DBA最大的价值所在。

   现在，我们就在干这些事。未来，就算不用Oracle，我们也不会失业。

   关于技术发展趋势

   我在公司五年多了，最初的数据库就是采用PC服务器，然后我们统一把他们整合到小型机上的集中式数据库，把MySQL换成Oracle，而现在我们又要把小型机换成PC服务器，把集中式Oracle数据库拆分成MySQL数据库集群，这不是简单的轮回，而是技术发展的结果。

   虽然现在的发展趋势是分布式架构，但是说不定过几年又会出现超级计算机，从而又走向集中式的道路。我们要做的是能够看到3年内技术发展的一个方向，适应技术发展的潮流，并不断调整目标，在解决问题的过程中不断优化。问题和技术都是不断发展的，试图设计一个完美的解决方案是不现实的，在一个问题被解决后，一定会有新的问题冒出来。

   选择简单但是不完美的技术解决问题，先做！然后再不断优化。如果不去尝试，我们永远也不知道下一步要做什么，总是停留在对技术方案本身优劣的讨论上，是没有意义的。

   人总是在不断反思，不断否定自我的过程中进步的，技术发展也是一样。

   -EOF-

   本文纯纯粹粹代表我个人对技术一些看法，欢迎拍砖，但谢绝上纲上线，乱扣帽子。

建议继续学习：

1. MySQL数据库在实际应用一些方面的介绍    (阅读：35428)
2. HFile存储格式    (阅读：14537)
3. hbase运维    (阅读：13677)
4. 淘宝图片存储架构    (阅读：9837)
5. SSD的主要缺陷及Wear Leveling技术详解    (阅读：8929)
6. 海量小文件存储    (阅读：7557)
7. Key-Value小数据库tmdb发布：原理和实现    (阅读：7315)
8. 基于SSD的数据库性能优化    (阅读：7412)
9. HBase技术介绍    (阅读：6759)
10. SQL vs NoSQL：数据库并发写入性能比拼    (阅读：6629)