DB2 purescale vs Oracle RAC

页面导航:首页 > 数据库 > DB2 > DB2 purescale vs Oracle RAC

DB2 purescale vs Oracle RAC

来源: 作者: 时间:2016-01-23 11:15 【

以前一直推崇Oracle的RAC(Real Application Cluster),建议客户的大型数据库应用采用RAC,因为RAC同时解决了这些客户对于性能扩展和高可靠性的要求。Oracle的另外两大竞争对手IBMDB2和微软S

以前一直推崇Oracle的RAC(Real Application Cluster),建议客户的大型数据库应用采用RAC,因为RAC同时解决了这些客户对于性能扩展和高可靠性的要求。Oracle的另外两大竞争对手IBMDB2和微软SQL Server针对高可靠性需求,只有用Cluster,可是浪费了一台机器的处理能力;为了扩展处理能力,一种方式是Scale Up,即采用更大的机器。另一种方式是采用MPP架构,不过为了性能的相对线性扩展,必须非常仔细地设计数据库结构、数据分区以及应用,否则性能有很大影响。没有两全的方式。
最近了IBM DB2 purescale的一些白皮书,仔细地研究了一下,发现DB2 purescale比Oracle的RAC还要先进。有巨大型应用需求的客户可以考虑采用DB2 purescale,大家可以下载一本《IBM DB2 purescale实现透明的应用扩展技术手册》来详细了解purescale和RAC的对比。当然在这本书中,IBM反复强调Purescale来源于mainframe大型机的血统,刻意列举了一些对于RAC极端不利的场景,虽然有发生的概率大小问题,但从根本的实现原理上讲,Purescale是比RAC先进。
Purescale也将高可靠性和应用透明扩展的能力集于一身,利用share disk的方式扩展集群服务器成员。与Oracle RAC所不同的是,Purescale采用了PowerHA purescale来提供集中化的锁管理和全局缓存,而 RAC采用的分布式锁管理和分布式缓存。由于分布式管理,RAC随着集群节点的增多,在极端情况下(如多个节点同时修改在另外一个节点管理的缓存中的数据时),多节点间的的通讯协调复杂性将指数型增长,IP中断和CPU处理出让更会大大降低处理效率。反观purescale,全局锁管理和全局缓存,所有节点都和全局CF(cluster accelerator)单一通讯,为了获得全局cache数据,直接用RDMA(remote Direct memory access)内存复制,避免高成本的进程间通讯。由于采用CF来全局管理锁和缓存,大大简化了管理,因此purescale能扩展到128节点,还保持比较好的性能线性。
当然为了要保证CF和各节点的高速通信,保证在得到CF响应前不需要出让已分配的CPU时间,purescale采用了Infiniband来互联各节点和CF,相比RAC采用的普通千兆网络,硬件成本上升了不少。而且目前purescale只支持Power系统(因为要用到PowerHA Purescale组件),即IBM的小型机,而RAC支持各种Unix、Linux和Windows平台,这也是purescale的一个局限性。不过好在purescale只定位于高端,而巨大型数据库应用目前采用Unix平台的相对多,而IBM的Power平台也是Unix中的No.1选择,所以这种局限性也不是一个很大的问题。
当然除了上述两点, Purescale还是有一些缺陷的。因为要采用CF,而且为了保证高可靠性,还必须采用两台,这相比Oracle RAC都是多出来的成本。而且PowerHA应该不是免费的,随着节点的增多,费用应该也增加。还有更关键的一点,由于全局缓存是保存在CF机器上的,所以全局缓存的最大上限是该机器的全部内存,而随着节点机器的数量增加,这个缓存是不增加的,除非增加CF机器的内存,所以这也可能成为一个全局的瓶颈。
不过Oracle的RAC本来就是模仿DB2 for z/OS的,只不过当年设计时Infiniband的技术还没出来,只好在开放式平台上采用分布式架构。DB2 purescale出来后,如果市场非常认可,相信Oracle也能很快采用Infiniband搞出集中式架构。不过成本和平台锁定也是Oracle必须考虑的一个问题,因为RAC已经成为一种主流,如果由于成本和平台的锁定而曲高和寡,Oracle RAC未必会很快转向集中架构。让我们拭目以待Oracle的反击。

Tags:

相关文章

    文章评论

    最 近 更 新
    热 点 排 行
    Js与CSS工具
    代码转换工具
    
    <