存档

2010年9月 的存档

关于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–
本文仅代表我个人对技术一些看法,欢迎大家拍砖。

9 12th, 2010 | Filed under 大话技术
标签: , ,

Oracle中普通的表称为堆表(heap table),堆表中的数据是无序存放的,往往在使用一段时间后,数据就变得非常无序。如下图所示,索引中相同的key对应的数据存放在不同的block中,这时,如果要通过索引查询某个key的数据,就需要访问很多不同的block,代价非常高。

Oracle中有一个统计信息clustering factor,它就是用来反映索引中键值在表中的有序程度,clustering factor的值如果接近表的blocks的数量,表明数据在表中的是有序的,而如果这个值接近表的行数,则表明表中的数据是无序存放的。因为clustring factor对于索引查询的影响很大,所以在CBO计算cost时,这个值非常重要。
我们可以通过创建一个单表的hash cluster,将相同键值的数据物理存放在一起,达到提高性能的目的。创建cluster有两个最重要的参数:hashkeys和size,前者表示cluster中有多少个不同的键值,后者表示每个键值需要分配的空间。因为hash cluster的空间是预先分配的,这两个值的正确设置对cluster的性能影响非常大。hashkeys设置过大,会造成空间浪费,而如果设置过小,则会产生大量的hash碰撞,极大影响性能。size也是一样,设置过大会浪费空间,而设置过小,数据超过预先分配的空间时,会通过链接方式存放在溢出段中,影响性能。而这两个值一旦设置,就无法更改,除非重建cluster。
hash cluster简单的说就是通过预先分配空间的方式,将相同key的数据存放在一起,以提高查询性能的一种手段,所以准确的设置hashkeys和size参数是使用hash cluster的关键,使用的前提是key的数量是可以估算的,而且每个key的数据是基本平均的。但是,在实际使用的环境中,数据量的变化往往是不可预知的,这也造成hash cluster的应用场景非常有限。
Index cluster和hash cluster类似,只不过index cluster是通过索引实现数据定位,而且index cluster的空间是动态分配的,但是同样存在正确设置size参数的问题,设置过大过小都会产生性能问题。
个人观点:Oracle cluster更适合相对静态数据的存储,对于OLTP应用来说,cluster在大部分情况下都不太适用,因为我们都无法预估到数据量的变化,根本无法合理设置cluster的参数。
任何技术都要找到合适的应用场景,有利一定有弊,有些技术确实是看上去很美,但是并不实用,而有些方案看上去很土,但是可以解决问题,找到最合适的就好。
–EOF–
如果哪位兄弟有oracle cluster解决实际问题方面的案例,也请和我一起交流。

9 5th, 2010 | Filed under 大话技术

3PAR最终被HP收购,想想HP一直没什么可以拿得出手的存储产品,高端的XP系列其实是HDS的USP,而与3PAR理念接近的EVA,始终没有进入高端行列。不知道HP收购3PAR后,是用来替换XP还是EVA系列。
通过我这几年使用硬件的经验来看,对HP的产品始终不太感冒。产品路线不清晰,小型机性能不佳,存储没有特色,PC服务器故障率高,价格没有优势,服务也很一般,销售换了一茬又一茬。
对于3PAR这个产品,我还是挺有好感的,设计理念很有特色,在实际测试中性能不俗,印象最深刻的是命令行界面非常好用,对于运维人员来说,这点是非常重要的。当初,曾经写过一篇文章介绍3PAR的产品:我看3PAR,有兴趣的可以看看。
随着技术的发展和公司策略的转变,我们对小型机和高端存储的需求已经越来越少了,分布式计算已经成为未来发展的趋势,当然,在传统行业中,这种高端硬件还是很有市场的。
在国外,这种收购的案例非常多,被收购的小公司都有非常鲜明的特点,大公司通过收购来提升自我的竞争力,小公司则在收购中得到收益,鼓励更多人去创新,形成良性循坏。但是在国内,这种案例就非常少见,大公司占有绝对优势,可以轻松的通过模仿等手段,挤垮这些小公司。归根结底,还是创新不够的原因,所以模仿的成本很低,比如微博,团购网等等,几乎都是照搬国外的模式,又没有太多技术门槛,所以就变成了大家一起上的局面。
Alibaba最近也收购了一些公司,但是基本都在电子商务这个领域,我觉得这点公司做的挺好,坚守在自己的领域。最近有人骂腾讯,其实腾讯没做错什么,只是什么都想做,树敌太多。我觉得每个企业都应该有自己的道德底线,不能什么赚钱就做什么,价值观也很重要。
–EOF–
附:《我看3PAR》,发表于2008年4月
最近测试了3par的存储,这个厂商在存储领域算是比较新的。以前看myspace的架构时,才第一次听说了这个产品,目前在国内才刚刚开始做。
这个存储有一些特点:
1.中端存储高端化:3PAR定为于高端存储,但是它的架构有点类似中端存储的架构,有控制器的概念,最多可以有8个控制器(S400最多有4个控制 器,S800可以有8个),控制器之间由一个网状背板连接起来,每个控制器有两个INTEL的CPU负责控制指令,还有一个3PAR自己控制器的ASIC 完成数据移动。普通的中端存储,一个LUN只能属于一个控制器,用户必须将LUN人工分布到两个控制器上,而3PAR每个LUN实际上是由多个控制器并行 处理的。
2.非常有特点的盘盒:3PRA插盘的方式非常独特,和其他存储都完全不同,在4U高度的盘盒中,有10个盘包,每个盘包可以纵向插入4块盘,相当于其他 存储一块盘的位置插入了四块,所以3PAR的盘的密度非常高。当然这也有问题,比如在换盘时,每次需要将整个盘包拔出,或者盘包自身的背板损坏,可能造成 数据丢失等等。不过3PAR已经考虑了这些情况,并有解决方案。
3.虚拟卷管理:第一层:每个盘都被划分为256M的小块(chunklet),由于每个盘盒都和两个控制器相连,所以这些存储块都有两个访问通道。第二 层:将这些存储块,基于RAID类型和存储块的位置组成逻辑盘(LD)。第三层:将一个或多个LD映射成为了一个虚拟卷(VV),并最终以LUN的形式输 出给主机(VLUN)。这样可以将IO分散到系统所有的磁盘,光纤连接和控制器上,而不象某些存储,必须要借助主机的LVM才能实现。如果我们使用文件系 统或者ASM的话,将会很方便。另外一个特点就是管理非常方便,只需要告诉系统我要多大的LUN,其他系统会自动完成。
4.精简配置:也叫做瘦存储(Thin Provisioning),就是将”使用的存储”和”分配的存储”分开了。比如用户规划需要2T的空间,但是目前只需要500G空间,这样存储可以实际 只有500G空间,但是告诉主机我有2T的空间。对主机来说,存储的管理将是透明的,当未来存储扩容后,主机不需要再做任何配置工作。
5.动态优化:当存储扩容时,可以动态的将数据重新分布,更改RAID类型,硬盘类型等等。
6.性能:从测试的结果看,3PAR表现相当不错,iops和相应时间都很理想。测试结果就不写了,免得有做广告的嫌疑。
7.界面:个人觉得3PAR的命令行界面很好用,图形界面没见过,不便评论。

9 4th, 2010 | Filed under IT江湖