存档

文章标签 ‘ORACLE’

这是我在第一届AskHelloDBA数据库技术论坛上的主题演讲:Exadata那点事,讲述你所不知道的Exadata细节。
我认为不管是否是Exadata的用户,不管是DBA还是架构师,都可以从Exadada的架构中学到很多东西,这也是为什么我一直研究它的原因。
PPT:Exadata那点事
–EOF–

4 22nd, 2012 | Filed under 大话技术
标签: ,

最近参加了OTN China Tour技术嘉年华的活动,并准备了一个关于软硬件结合的主题演讲,介绍了我们在软硬件结合方面提升Oracle数据库性能和可用性的案例,后续我会详细介绍这些案例的架构与设计。
PPT:软硬件结合的数据库解决方案
–EOF–

感谢ACOUG,云和恩墨,Eygle和Kamus。

10 24th, 2011 | Filed under 大话技术

Hardware and Software Engineered to Work Together
自从Oracle收购了SUN,不仅仅得到了MySQL,Java,Solaris等,还得到了SUN的硬件产品,真正成为了一家软硬通杀的服务提供商。这几年,接连推出了基于SUN的硬件产品打造的数据库一体机Exadata X2,中间件一体机Exalogic等等,更是将软硬件结合的思路发挥到了极致。其中最郁闷的非HP莫属,从原来的合作伙伴到竞争对手,Exadata采用SUN的硬件,Oracle抛弃安腾处理器,甚至CEO都跳槽去了Oracle。
最近,Oracle推出了廉价的数据库一体机ODA(Oracle Database Appliance),这个产品同样是软硬件结合战略下的产物,目标是为中低端用户提供廉价,简单,高可用的数据库一体机,并与Exadata形成高低搭配,Exadata与小型机和高端存储竞争,ODA则占领使用PC服务器的中低端市场。
我们来看看这个机器的硬件特点:

Oracle在4U的空间内,搭建了一个两节点的RAC系统。其中内置了两个配置双路X5675CPU+96G内存的服务器,共享20块600G SAS磁盘,4块73G的SSD,内置万兆交换机用于RAC节点互联(Exadata的节点互联是采用Infiniband)。其中SSD用于存放redo log,提升性能。

Oracle的最大特点是软硬件结合,这套系统使用Oracle Linux,Oracle database 11gR2 RAC,以及专门用来配置和管理的Appliance Manager,用来提升管理性和易用性。
使用ODA与用户自己使用PC搭建数据库相比,用户无需购买SAN存储和万兆交换机,就可以实现一套高可用的RAC系统。软硬件一体机的另外一个最大的特点就是配置简单,即插即用,Oracle帮你搞定一切。不过,这个优点在有些用户看来也许是缺点,因为不够灵活,黑盒子不够透明等等。
但是,对于大部分用户而言,简单,易管理,高可用就是最基本的要求,看来ODA还是挺符合这些需求的。当然,价格也是一个重要因素,ODA的目标用户应该都是中小型用户,不差钱的用户通常都会买小型机,高端存储或者Exadata,如果定价合理,相信还是有很大的市场的。
有一点值得注意,ODA将整套系统全部封装在一个盒子里,无形中增加了风险,在异常情况下可能会导致整个系统不可用,比如断电或存储损坏等等。所以,考虑到可用性的问题,一套肯定是不够的,至少要再买一套做DataGuard。不过,这样做代价就有点高了,考虑到ODA肯定比自己买PC服务器贵,可以考虑自己购买PC来做DataGuard,降低使用成本,提升可用性。
–EOF–

9 27th, 2011 | Filed under 大话技术
标签: , ,

最近博客一直没更新,因为忙着翻译一本书,《Expert Oracle Exadata》。

本书的作者是Kerry Osborne, Randy Johnson和 Tanel Põder,看看三位重量级的作者就知道本书的技术含量非常高,尤其是在Exadata的资料如此匮乏的情况下,本书全面介绍了Exadata的各种技术内幕,绝对是一本非常有价值的好书。
目前,我和Kumas,Kaya一起正在全力翻译这本书,预计几个月后,大家就可以读到这本书的中文译本,敬请期待!
–EOF–
附上本书的目录
1.What Is Exadata?
2.Offloading / Smart Scan
3.Hybrid Columnar Compression
4.Storage Indexes
5.Exadata Smart Flash Cache
6.Exadata Parallel Operations
7.Resource Management
8.Configuring Exadata
9.Recovering Exadata
10.Exadata Wait Events
11.Understanding Exadata Performance Metrics
12.Monitoring Exadata Performance
13.Migrating to Exadata
14.Storage Layout
15.Compute Node Layout
16.Unlearning Some Things We Thought We Knew

9 20th, 2011 | Filed under 大话技术
标签: ,

传统的Oracle的高可用方案必须基于共享存储设备,不管是双机主备模式,还是Oracle RAC,数据库必须放在共享的SAN存储上,通过HA或集群软件实现高可用。Oracle DataGuard是很好的容灾软件,但是作为HA解决方案,功能有很多局限性,比如数据丢失,应用透明切换,只能读无法写(11g)等等,目前都没有非常好的解决方案。
自从固态存储技术出现后,单机的IO能力大幅度提升,比如采用PCIE接口的fusionio卡,单块卡就可以提供数万IOPS的能力,单机的IO能力已经超过了传统的磁盘存储。但是,一直困扰我们的是,如何解决无共享存储环境下Oracle数据库的高可用问题?我们团队设计了一种架构,提供简单可靠的高可用功能。
Oracle+fusionio+DataGuard的高可用解决方案
方案简述:利用fusionio卡的强大的IO能力,取代传统存储设备,双机采用DataGuard复制,将主库的controlfile和redo放在一套共享的存储设备上。当主机发生故障时,利用共享存储上的controlfile和redofile将standby数据库恢复到一致状态。
硬件:DELL R710,48G mem,Fusionio ioDrive 320G(数据文件),6×300G SAS RAID10(归档文件)。
存储:SAN存储,存放主库的controlfile与redofile,与其他数据库共用,性能与空间要求不高。
软件:Veritas Cluster Service,提供HA功能,自定义切换脚本。
切换步骤:
1.关闭standby;
2.指向共享存储上主库的redofile和controlfile;
3.mount standby;
4.recover database;
5.open database。
优点:
1.零数据丢失;
2.简单,可靠;
3.应用透明切换;
4.对存储性能要求不高;
5.适合读多写少应用,提升读性能。
缺点:
1.依然需要共享存储,但是可以与其他系统共用;
2.切换时间依赖standby恢复时间,必须保证standby恢复的进度;
3.共享的redofile可能会成为写入瓶颈,最好使用配置write cache的存储。
改进计划:
1.实现类似switchover的功能,主备互相切换,无需人工干预;
2.本地fusionio空间不足时,可以将部分数据放在共享存储上,实现混合存储。
–EOF–
目前,这个方案已经通过初步验证,进入方案完善阶段。如果有兴趣,可以与我一起探讨,并不断改进。

5 30th, 2011 | Filed under 大话技术
标签: ,

我之前曾经写过一篇Library cache内部机制详解,但是遗留了一些关于11g中mutex的改进的问题,最近因为有些11g的数据库频频发生mutex相关的等待事件,所以我又多这个问题做了一些探讨。
关于Mutex,可以参考ORACLE mutex实现机制这篇文章,mutex是从10g开始引入的,在library cache中有大量的使用,它的主要作用有两个:一是用来替换library cache pin,二是作为更轻量级的latch使用。
在9i中,Library cache lock有null,share,exclusive三种模式,lock的作用是控制进程间的并发访问。Library cache pin有share和exclusive两种模式,pin的作用是保证数据一致性,防止数据在访问时被交换出去。我们先来回顾一下library cache lock和library cache pin在不同场景下的使用方式:
Procedure/function/trigger
访问对象:需要在object handle上获取一个null类型的library cache lock(首先获取share,然后转换为null),然后在data heap上获取share类型的library cache pin,在其所依赖的表上不加任何lock和pin(先申请share类型的lock,申请到之后不再持有任何lock和pin,允许修改procedure所依赖的对象,即允许被打破)。
编译对象:需要在object handle上获取一个exclusive类型的library cache lock,然后在data heap上获取exclusive类型的library cache pin,同时在依赖的对象上获取share类型的library cache lock和pin,保证依赖的对象不能被修改。
当持有对象的library cache pin时,同时会在row cache中对相应的对象加锁,就是row cache lock,阻止可能导致数据字典信息混乱的DDL发生,row cache lock和library cache lock/pin一样,都是为了保证对象的一致性。
Cursor
Cursor execute:在object handle上获取null类型的library cache lock(首先获取share,然后转换为null),然后再data heap上获取share类型的library cache pin,在其所依赖的表上不加任何lock和pin(先申请share类型的lock,申请到之后不再持有任何lock和pin,允许修改cursor所依赖的对象,即允许被打破)。
Cursor hard parse:Cursor硬解析需要在object handle上获取exclusvie类型的library cache lock,然后再data heap上exclusive获取类型的library cache pin,同时在依赖的对象上获取share类型的library cache lock和pin,保证依赖的对象不能被修改。
Null类型的library cache [...]

3 1st, 2011 | Filed under 大话技术
标签:

Fusion-io是基于NAND Flash技术的存储设备,底层存储技术与SSD相同,不同的是,Fusion-io采用PCI-E接口,SSD采用SATA接口。相比较SSD,Fusion-io省略了南桥芯片,RAID控制器等访问路径,所以Fusion-io又把他们的产品称为IO Memory,意思就是可以象内存一样访问,性能比SSD要好很多。
我们目前数据库使用SSD,采用的是硬件RAID5的方案,这个方案的优点是:通过RAID卡提供冗余功能,提升了整体的可靠性。缺点是:RAID会损失部分性能,通过RAID卡屏蔽之后,无法检测到SSD的使用寿命。选择硬件RAID5方案,是在大量测试的基础上,结合我们的实际情况做出的选择,并不一定是最优的方案。
ORACLE使用Fusion-io的方案,需要考虑三个方面的内容:1.数据冗余方案;2.数据存放方案;3.高可用方案。
数据冗余方案:
Fusion-io采用PCI-E接口,无法使用硬件RAID,我们可以使用OS LVM或者ORACLE ASM实现软RAID的功能。
1.External Redundancy (Striping/RAID0)
这个方案相当于RAID0,只是将多块ioDrive(Fusion-io的产品名称)的空间整合为一个统一的DG,不提供任何数据冗余。

2.Normal Redundancy (Mirroring/RAID1)
这个方案相当于RAID10,同时提供了数据冗余与条带,是可靠性比较高的方案。需要注意的是:可以通过ASM failgroup的功能,将两块ioDrive之间做镜像,以防止单块卡出现故障。

3.High Redundancy (Mirroring/RAID10 +1)
这个方案相当于RAID10+1,数据被冗余了三份,进一步提高了可靠性,不过代价有些高。

4.ASM Mirroring with a Read-Preferred Device
这个方案稍微复杂,ioDrive与存储的LUN做RAID10,利用ASM的Preferred mirror read功能,读取时优先读取ioDrive,提高性能的同时,又保证了可靠性。

5.方案分析:
上述四个方案中,方案一没有数据冗余,其他三个方案都有数据冗余,方案三代价过于高昂,方案四必须要有FC存储,方案二是最有可能采用的方案,但是RAID10要损失一半的容量,对于价格昂贵的ioDrive来说,代价依然高昂。回头看看方案一,因为本地数据没有冗余,所以必须采用Data Guard来保证系统高可用,如果要求数据100%不丢失,Data Guard必须采用同步模式,网络延迟必须满足日志同步写入的要求,如果系统压力过大,依然存在丢失数据的可能性。看来没有十全十美的方案,必须有所取舍。
数据存放方案:
1.将所有文件都保存在ioDrive上:
如果存储空间许可,这是最简单可靠,也是性能最好的一种方案。
2.将temp文件保存在ioDrive上:
针对一些DSS系统,temp文件可能是性能的瓶颈,比如大量的sort,Hash join可能耗费大量的temp空间,将temp文件放在ioDrive上可能带来性能上的收益。不过,我很少见到类似的需求,这个方案应该很少使用。
3.将redo保存在ioDrive上:
对于ORACLE数据库,redo log必须同步串行(9i串行,10g以后可以并行),对于write-intensive系统,要求redo必须有很低的写入延迟,否则redo可能成为整个系统的瓶颈。所以,可以考虑将redo log放在ioDrive上,提高响应延迟。但是,我个人并不是特别建议这个方案,因为redo log的写入是一种小IO的顺序写入,顺序写入更适合磁盘,并不适合flash存储(可以参考《基于SSD的数据库性能优化》)。如果磁盘可以满足响应延迟需求,建议将redo log放在磁盘上,而不是ioDrive上。
4.将热点数据保存在ioDrive上:
如果整个系统无法全部放在ioDrive上,而用户可以识别出系统的热点数据,那么可以人工将热点数据放在ioDrive上,将其他数据放在磁盘存储上,从而获得比较好的性能。
5.ioDrive作为flashcache:
将ioDrive作为数据库内存和磁盘之间的cache,Flashcache是用户透明的一种解决方案,系统自动将热点数据加载在flashcache中,提升系统性能。ORACLE  11g R2提供了flashcache功能,当block从SGA中被换出时,会被写入到flashcache中,但是在ORACLE的flashcache方案中,只有clean block才会被写入到flashcache中,Dirty block必须写入到磁盘上(DBWR会优先保证dirty block的写出,只有空闲时才会写flashcache),这就是我们所说的write through模式(Facebook的flashcache方案可以采用write back模式,dirty block首先被写入flashcache,然后定期刷新到磁盘上,flashcache同时承担了读cache和写buffer,这个方案性能更好),ORACLE flashcache是纯粹的读cache,可以大幅度提升读的性能,但是无法提升写的性能。ORACLE的方案很安全,就算flashcache损坏,也不会丢失任何数据,但是性能比WB模式要差一些,而且flashcache预热的过程也比较长。另外一点,ORACLE flashcache必须使用ORACLE LINUX,其他操作系统不提供这个功能。
Flashcache提供了一个高性价比的方案,但是同时增加了系统的复杂度,如果是WB模式,可能存在数据丢失的风险,在做方案时,需要做一些权衡。个人建议:如果空间可以满足需要,可以考虑方案一,性能和可靠性都最好。如果热点数据很明确,可以采用方案四,简单可控,性价比高。另外,Facebook的flashcache方案也是一个很好的选择,淘宝在MySQL数据库上广泛采用了这一技术,百度也在MySQL innodb存储引擎上,自主开发了flashcache的功能。不过,我始终认为flashcache是一个过渡方案,技术上并不是特别成熟,如果技术上无法完全把握这项技术,请谨慎使用flashcache。
数据高可用方案:
ORACLE数据库高可用方案有两个:Data Guard和RAC,Data Gurad相对比较简单,但是可用性并不理想。RAC基于共享存储架构,必须有一套SAN存储,RAC使用FusionIO也有两个方案:
1.共享存储+Fusion-io+Flashcache
这个方案采用传统RAC架构,只是在RAC节点上配置ioDrive,用ioDrive作为数据库的flashcache,提升性能。这里要说明一点,为什么ORACLE flashcache不提供WB模式,原因是ORACLE RAC架构必须基于共享存储,如果dirty block写入RAC节点的flashcache,当发生节点crash的时候,将出现数据不一致的情况。
2.Fusion-io+iSCSI+infiniband
这个方案将配置ioDrive的机器作为存储节点,利用iSCSI和ASM技术,将存储节点整合为共享的存储设备,输出给RAC节点使用。

事实上,很早之前我就做过类似的方案:ORACLE RAC廉价数据仓库解决方案,大致的原理一致,只是存储节点变成了ioDrive。但是,我们在做这个方案时,发现在千兆以太网上运行iSCSI,延迟时间根本无法满足需求。如果存储节点换成ioDrive,存储节点可以提供强大的IOPS能力,但是网络延迟将会成为整个系统的瓶颈。后来,ORACLE Exadata出现了,内部互连采用infiniband技术,这给了我们一个启发,我们同样可以利用infiniband的低延迟特性,来实现这个方案。
Infiniband与以太网不同,采用SRP(SCSI RDMA protocol)协议,是IB SAN的一种协议 ,其主要作用是把iSCSI协议的命令和数据通过RDMA的方式跑到Infiniband网络上,可以认为是iSCSI协议的一种增强和扩展,iSER代表iSCSI Extensions for Remote DMA。下图清晰的展示了各种协议与底层物理链路之间的关系。
ORACLE Exadata的最大优势在于,将OLTP和DSS融合在一套系统之内,Exadata有一些特性,其中smart [...]

2 20th, 2011 | Filed under 大话技术
标签: , , ,

数据仓库环境,ORACLE RAC,100T数据,每日归档那个量5T(对于不需要产生备份的数据,已经采用了nologging方式,以减少归档数量),如何制定备份和恢复方案?
方案一:DataGuard
DataGuard是性价比最高的备份和容灾方案,但是当归档超过一定规模之后,DG的恢复就成为了瓶颈,每天产生的归档无法及时恢复完,我们也尝试过很多调优的方法,包括并行恢复,都无法解决,恢复的瓶颈不在存储的吞吐量,而在于standby的恢复方式,因为恢复的过程就是应用归档文件,RAC各个节点产生的归档必须在一个节点恢复,这个过程必须是遵循一定顺序的,大大限制了恢复的并发速度。
方案二:传统RMAN备份
采用传统RMAN备份,采用大吞吐量的虚拟带库设备,一周全备一次,每天备归档日志。很多时候,我们在做备份方案时,只考虑了备份,却没有考虑恢复。这个方案最大的问题就在于:恢复的代价非常高,一旦数据库出现问题,恢复可能需要数天之久,这是无法接受的。另外,还要额外购买备份设备。
方案三:存储镜像
数据库采用noarchivelog模式,采用ASM镜像两套存储。这个方案并不是备份方案,只是为了解决存储的单点问题而提出的,相当于对不同的存储做RAID 1。这个方案最大的问题是无法解决数据库逻辑错误,比如误删除数据。因为主库和备库通过存储镜像来实现,无法实现异地备份和容灾。
方案四:存储级别复制
采用存储级别的复制,各存储厂家都有解决方案,比如EMC SRDF等。Veritas也有类似的解决方案,比如卷复制(VERITAS Volume Replicator)。这种方案的基本原理都是通过捕获底层存储的IO,并通过网络同步到备份系统上。如果采用存储厂商的方案,那么主备库就必须使用同一家公司的产品,而且,能否承受每天4.5T的数据变化量,我们并没有验证过。另外,软件license费用不菲。
有人说:能用钱解决的问题不是问题。可是,问题是没钱!Alibaba虽然不缺钱,但是我们的目标就是花小钱办大事。我个人也不推荐使用存储厂商的解决方案,这不仅仅是钱的问题,而是这种方案基本上就是个黑盒,我们还是喜欢更简单开放的解决方案。
既然ORACLE DG是性价比最高的备份和容灾方案,我们还是想通过DG来解决这个问题。DG的好处在于可以随时打开备份,验证有效,standby延迟恢复还可以解决逻辑错误,防范ORACLE软件bug可能带来的损失。解决方案的核心就是要解决DG恢复速度慢的问题。
方案五:ORACLE DG+块级别增量备份/恢复+归档
从10g开始,ORACLE提供了一个功能:块改变跟踪(block change tracking),通过bitmap记录block的变化,通过这个块改变跟踪文件,就知道哪个block发生了变化,大大提高了增量备份的效率。具体方案为:首先为数据库建立一个0级备份(standby),然后将1级备份应用到0级备份上,相当于恢复的过程,这个恢复比应用归档日志要快很多,为什么?因为备份都是变化的block,只要将旧的block覆盖就可以了,所以不存在日志恢复过程中的顺序问题,所以恢复的并行度可以很大,可以充分发挥出设备的吞吐能力。另外,当一个block被重复变更多次时,增量备份只需要备份最新的block,恢复也只要覆盖旧的block即可,定期增量备份实际可以减少备份需要的空间使用量。而redo文件中记录了block变化的记录,所以应用redo恢复时需要多次变更该块,必须保留所有的归档文件才可以恢复成功。当然,应用1级备份之后,standby并不能打开,因为block并不是一致状态的(因为增量备份会持续很长的时间,在这个过程中,备份的block的时间点是不一致的),所以要利用归档文件将standby推到一致的状态才可以打开。
我们目前的方案:建立standby数据库,每周做一次增量备份,首先应用增量备份,然后应用归档日志文件将数据库推到一致状态,可以打开数据库,验证备份有效,归档日志文件循环备份到磁带库,整个过程通过脚本实现自动化。这个方案采用增量备份+archivelog恢复standby,可以打开standby验证备份有效,出现故障时可以直接standby switchover,大大节省了恢复的时间。而且,这个方案都是基于现有硬件基础,基本上没有采购额外的硬件设备和软件license,花小钱办大事。
我的技术理念:做解决方案就是搭积木,用简单的技术去解决问题,并不一定要发明新的东西,最佳实践也是很有价值的。
–EOF–
后记:这个问题,我曾经在OOW上问过ORACLE的技术专家,他们也没有很好的解决方案,建议我们买两套Exadata来解决(我并没有搞清楚为什么Exadata恢复归档的速度会变快,是设备本身的能力提高了,还是ORACLE恢复的方式发生了变化),或者放弃数据库级别的备份,由应用程序写多份数据来解决。所以说,ORACLE也没有考虑到如此大数据量环境的备份问题,ORACLE可以考虑推广我们的解决方案。

1 27th, 2011 | Filed under 大话技术
标签:

数据库HA的最基本要求是:1.应用透明切换;2.切换速度快;3.保证数据完整一致。ORACLE数据库的HA方案都要基于共享存储,即shared storage架构,不管是RAC还是Active-Standy方式。Data Guard更多是作为备份和容灾的方案,由于standby数据库在恢复的过程无法打开读写,Standby必须经过switch over之后才可以读写,即便11g提供了Active standby功能,DG并不是特别适合做HA方案,主要原因是:1.需要人工干预,应用不透明;2.切换速度慢,Standby必须经过切换才能读写;3.可能数据丢失,如果采用LGWR同步传输日志,可以保证数据不丢失,但是可能会影响性能。
MySQL在这方面比ORACLE要灵活许多,因为是类似逻辑复制的方式,复制的过程中数据库不仅可读写,而且还可以采用双向复制的模式,通过DB Proxy,可以提供非常灵活的HA方案,见下图:

于是,我们想到让ORACLE借鉴MySQL的方案,采用逻辑复制的方法,通过DB Proxy实现应用透明切换,方案的核心就是ORACLE日志解析与数据同步。采用这种方案的优点:1.应用透明切换;2.切换速度快;3.切换时可能会丢失部分数据。这种方案虽然无法完全保证数据一致性,但是只要日志文件不丢失,数据可以达到最终一致的状态(MySQL也是如此)。对于那些对于一致性要求不高的应用,只要将同步时延控制在一定的范围内,这个方案可以提供很好的灵活性,而且DG依然可以作为备份和容灾的角色存在。
这个方案的最大意义在于:ORACLE数据的HA不再依赖共享存储,存储设备通常都非常昂贵,而目前PC+SSD就可以提供非常高的处理能力,唯一的软肋就是可用性无法保证,如果这个方案可以实现,就可以用PC+SSD取代小型机+存储,真是很令人期待。
当然还需要解决很多问题:1.实时解析日志,减少时延;2.同步变更字段,减少网络传输;3.并行应用,提高应用速度。目前,我们正在努力解决,很快可以看到曙光。敢想敢为,就没有不可能!
–EOF–

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

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