以前一直推崇Oracle的RAC(Real

Application

Cluster)，建议客户的大型数据库应用采用RAC，因为RAC同时解决了这些客户对于性能扩展和高可靠性的要求。Oracle的另外两大竞争对手IBM

DB2和微软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组件来提供集中化的锁管理和全局缓存，而Oracle

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选择，所以这种局限性也不是一个很大的问题。

当然除了上述两点，DB2

Purescale还是有一些缺陷的。因为要采用CF，而且为了保证高可靠性，还必须采用两台，这相比Oracle

RAC都是多出来的成本。而且PowerHA应该不是免费的，随着节点的增多，费用应该也增加。还有更关键的一点，由于全局缓存是保存在CF机器上的，所以全局缓存的最大上限是该机器的全部内存，而随着节点机器的数量增加，这个缓存是不增加的，除非增加CF机器的内存，所以这也可能成为一个全局的瓶颈。

不过Oracle的RAC本来就是模仿DB2 for

z/OS的，只不过当年设计时Infiniband的技术还没出来，只好在开放式平台上采用分布式架构。DB2

purescale出来后，如果市场非常认可，相信Oracle也能很快采用Infiniband搞出集中式架构。不过成本和平台锁定也是Oracle必须考虑的一个问题，因为RAC已经成为一种主流，如果由于成本和平台的锁定而曲高和寡，Oracle

RAC未必会很快转向集中架构。让我们拭目以待Oracle的反击。

参考

1：《IBM DB2 purescale实现透明的应用扩展技术手册》

2：《Technical comparison of Oracle real

appliation cluster 11g vs. IBM DB2 V9 for Linux, Unix and

Windows 》