我对技术方向的一些反思

9 12th, 2010 | Posted by jacky | Filed under 大话技术

关于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数据库,前者通过数据拆分(Sharding)等手段,解决海量数据处理和弹性扩展的问题,集中式Oracle数据库则用于保存核心数据,提供简单可靠的数据存储和访问服务。合理的使用Oracle和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不应该仅仅局限于某个数据库产品,而应该更全面的了解开发架构方面的知识,甚至需要具备开发能力,比如针对MySQL数据库进行修改和优化,这也将大大提高DBA解决问题的能力。

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

关于技术发展趋势

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

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

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

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

–EOF–

本文仅代表我个人对技术一些看法,欢迎大家拍砖。

标签: , ,
  1. arcwiz
    9 12th, 201023:22

    完整地读了这篇文章,非常钦佩Jacky的视角和对技术方向的把握能力。

  2. jimmy
    9 12th, 201023:41

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

  3. 木匠Charlie
    9 13th, 201004:46

    有想法的思考者.

    鄙人一直号称是Development DBA, 常年磨练数据库应用的设计和开发.
    参考 http://bit.ly/d0nRQ9 – Principles of Application Design and Tuning, 这一段应该是Tom写的.

    我们公司正准备把几个收购了的小公司的MySQL数据库集成到一起,统一到Oracle数据库呢.
    这个跟架构师的决策推荐,IT部门领导的喜好,开发人员的技术根基…等等, 关系也很大.

  4. jacky
    9 13th, 201009:30

    文章之所以称之为反思,就是对我们之前技术路线的一次反思,可以说是有得有失。
    有时候,选择太多并不是件好事,面临问题时,对于解决方案的选择,难免会因人而异,但是最终的目标都是使用最低的代价去解决问题,并不一定是完美的。
    有些事情,想是想不清楚的,必须去做,做了之后才知道对与错,才知道下一步要做什么。

    感谢关注!

  5. 灵猫
    9 13th, 201011:13

    一直都实时关注jacky大师的博客,学到了很多新的思路,同时也有些自己的想法和思路想和jacky大师交流一下。话说那次跟您提过的关于数据库性能模型(那次淘宝数据库技术论坛交流),不知道您有没有印象。没看到写续集了呢,而且我觉得那个可以再扩展一点,就是建立框架的东西。
    这篇文章里面,我最关注的就是您写的MySQL和Oracle的选择和对比问题,非常赞,其实现在我也到了给公司产品线选择DB的问题,很纠结,想和您讨论交流下。我觉得选择MySQL还是Oracle要考虑自身的技术储备,硬件资源还有产品的要求,相关人员的能力基础等,貌似还是很多的。

  6. zhaolinjnu
    9 13th, 201013:30

    我发现我的blog,好久没有更新了,要向张大帅学习。

  7. jacky
    9 13th, 201016:01

    @灵猫
    如果在Oracle和MySQL之间选择,其实还是比较容易的,考虑系统架构,技术的成熟度,后期维护成本,技术人员的能力等等。
    如果有什么问题,可以发邮件给我讨论。

  8. 草根网
    9 13th, 201017:02

    好文,收藏至20ju.com

  9. 灵猫
    9 13th, 201017:42

    jacky大师的速度真是惊人,早上发的,看到您下午就回了,非常敬仰,好的,那我邮件给您讨论,还有我对您之前的几篇文章的自己的一些看法和观点。还有您是不是可以写篇关于这个应用和DB上在功能处理的平衡设计的思路。
    比如:处理业务逻辑,有的用DB来实现,存储过程,自定义函数,复杂的SQL;有的用应用来实现,通过算法,强悍的代码来实现。如何选择哪一种更有利于高可用和高性能呢,虽然Tom的书中是说:能放到DB中去解决就放到DB中去解决。其实我个人还不是很赞同的。

  10. doordie
    9 13th, 201018:24

    其实我挺赞同逻辑如果能到DB中尽量放到DB中,特别是事务处理的时候,而且关键的逻辑可能就要写到存储过程里,让程序员在java里实现可能难度增加又容易有问题

  11. jacky
    9 13th, 201019:18

    @灵猫
    大师谈不上,大家纯粹讨论技术而已。
    关于应用实现是放在DB还是在应用实现,我们现在的做法是尽可能放在应用中实现,而不是通过数据库中的存储过程触发器等等,当然这和我们的应用场景和开发环境有关,并不是说这样就是好的方式。在一些集中式的环境中,放在DB中实现也许更好。
    我会写一写我们为什么要这么做。
    谢谢!

  12. jacky
    9 13th, 201019:19

    @doordie
    我们这里正相反,呵呵。

  13. 图图网
    9 13th, 201020:42

    感觉很有帮助,博主架构方面还是见解独到

  14. sexla
    9 13th, 201021:54

    真是技术问行啊!!

  15. 木匠Charlie
    9 14th, 201002:36

    Transactional database API.

    Modular programing.

    High cohesion, Low coupling.

    My Canadian $0.02 + 税.

  16. 大叔
    9 14th, 201010:23

    数据库是由很多模块构成,往往数据库所有模块都由一家完成。现在希望把它们分开,Parser, Optimizer, Transaction…, 耦合太强了。NoSQL受限也与此。比如Cassandra的Transaction。

  17. ztg
    9 14th, 201011:27

    文中提到小型机在可用性上有些优势,这些体现在小机的硬件设计还是某种unix 系统优势?比如AIX.对小型机了解不够深入。
    小型机“在稳定性,管理性和维护性等方面,小型机都要比PC服务器高出不止一个档次”,能否举例说明。我们也面临选小机还是pc server 部署ORACLE的问题,小机的销售也解释不清楚。
    我个人觉得如果不是24*7*365要求高系统,完全可以不用小型机,根据自己应用特点确定

  18. PHPma
    9 14th, 201023:46

    把经验,经历无私滴分享并写成文章,使读者易于看懂——Bloger不愧是一个低调牛人
    另外推荐你滴同事一篇文章:http://isky000.com/database/core-databas-system-migration-from-oracle-to-mysql
    不得不说,从这两篇文章中收获良多

  19. jacky
    9 15th, 201014:40

    @ztg
    从稳定性来说,小型机是比PC强很多的,因为小型机本来就是为了不间断应用而设计的,所以内部部件基本都采用了冗余设计,这点要比PC好很多,从我们的使用经验中也可以证明,小型机稳定性大大好于PC。而且维护性和管理性也比PC好,比如小型机的可以不停机更换部件,并且有专门的管理界面可以维护主机。
    但是,我们更应该关注的是整个系统的可用性,用架构去弥补单台机器的可用性,就是说如果单台服务器坏掉,系统还可以正常运行,或者影响很小,我们就可以摆脱对高端设备的依赖,现在的分布式系统都是这个方向。
    我们也正在努力摆脱小型机,用PC机去替换小型机,就是将原来集中式的数据库拆分为一个数据库集群,虽然单台PC的可用性不及小型机,但是整个集群的可用性反而更高了。

    选择小型机还是PC,主要看你的应用架构,如果你还是传统的集中式数据库,我建议你选择小型机。如果性能允许,选择比较高端的PC机也是可以的,可以采用一些高可用软件,比如RAC或者Veritas,达到数据库自动切换提高可用性的目的。

  20. orainxiong
    9 15th, 201023:30

    大道至简,jacky的文章总是能化繁为简:)

  21. OurMySQL
    9 27th, 201010:25
    #21
  22. 盐味
    9 30th, 201012:14

    刚刚看到这篇文章,收获颇丰。
    我们最近在积极的测试fusion io,mysql新版本,mysql cluster等等,对”不是简单的轮回,而是技术发展的结果“感触颇深,原来由于io等瓶颈我们不得不进行各种各种样的切分,但是突然发现,如果硬件技术提高了,或者软件发展了,我们恐怕又要转回去,为了业务发展,把某些拆分的东西合起来。

  23. 冬瓜头
    1 6th, 201122:21

    把等当量的爆竹转变为原子弹,这确实是很有挑战性的工作。之前与华为业务软件的一兄弟交流过,当时某系统,也苦于小机和高端存储的成本,想转为分布式,但是未遂,因为商用产品测试的结果都不理想。看来搞分布式系统最终还得自己开发才是出路啊。