最近下载了IBM DB2 purescale的一些白皮书&＃xff0c;仔细地研究了一下&＃xff0c;发现DB2 purescale比Oracle的RAC还要先进。有巨大型数据库应用需求的客户可以考虑采用DB2 purescale&＃xff0c;大家可以下载一本《IBM DB2 purescale实现透明的应用扩展技术手册》来详细了解purescale和RAC的对比。当然在这本书中&＃xff0c;IBM反复强调Purescale来源于mainframe大型机的血统&＃xff0c;刻意列举了一些对于RAC极端不利的场景&＃xff0c;虽然有发生的概率大小问题&＃xff0c;但从根本的实现原理上讲&＃xff0c;Purescale是比RAC先进。

 

Purescale也将高可靠性和应用透明扩展的能力集于一身&＃xff0c;利用share disk的方式扩展集群服务器成员。与Oracle RAC所不同的是&＃xff0c;Purescale采用了PowerHA purescale组件来提供集中化的锁管理和全局缓存&＃xff0c;而Oracle RAC采用的分布式锁管理和分布式缓存。由于分布式管理&＃xff0c;RAC随着集群节点的增多&＃xff0c;在极端情况下&＃xff08;如多个节点同时修改在另外一个节点管理的缓存中的数据时&＃xff09;&＃xff0c;多节点间的的通讯协调复杂性将指数型增长&＃xff0c;IP中断和CPU处理出让更会大大降低处理效率。反观purescale&＃xff0c;全局锁管理和全局缓存&＃xff0c;所有节点都和全局CF&＃xff08;cluster accelerator&＃xff09;单一通讯&＃xff0c;为了获得全局cache数据&＃xff0c;直接用RDMA&＃xff08;remote Direct memory access&＃xff09;内存复制&＃xff0c;避免高成本的进程间通讯。由于采用CF来全局管理锁和缓存&＃xff0c;大大简化了管理&＃xff0c;因此purescale能扩展到128节点&＃xff0c;还保持比较好的性能线性。

 

当然为了要保证CF和各节点的高速通信&＃xff0c;保证在得到CF响应前不需要出让已分配的CPU时间&＃xff0c;purescale采用了Infiniband来互联各节点和CF&＃xff0c;相比RAC采用的普通千兆网络&＃xff0c;硬件成本上升了不少。而且目前purescale只支持Power系统&＃xff08;因为要用到PowerHA Purescale组件&＃xff09;&＃xff0c;即IBM的小型机&＃xff0c;而RAC支持各种Unix、Linux和Windows平台&＃xff0c;这也是purescale的一个局限性。不过好在purescale只定位于高端&＃xff0c;而巨大型数据库应用目前采用Unix平台的相对多&＃xff0c;而IBM的Power平台也是Unix中的No.1选择&＃xff0c;所以这种局限性也不是一个很大的问题。

 

当然除了上述两点&＃xff0c;DB2 Purescale还是有一些缺陷的。因为要采用CF&＃xff0c;而且为了保证高可靠性&＃xff0c;还必须采用两台&＃xff0c;这相比Oracle RAC都是多出来的成本。而且PowerHA应该不是免费的&＃xff0c;随着节点的增多&＃xff0c;费用应该也增加。还有更关键的一点&＃xff0c;由于全局缓存是保存在CF机器上的&＃xff0c;所以全局缓存的最大上限是该机器的全部内存&＃xff0c;而随着节点机器的数量增加&＃xff0c;这个缓存是不增加的&＃xff0c;除非增加CF机器的内存&＃xff0c;所以这也可能成为一个全局的瓶颈。

 

不过Oracle的RAC本来就是模仿DB2 for z/OS的&＃xff0c;只不过当年设计时Infiniband的技术还没出来&＃xff0c;只好在开放式平台上采用分布式架构。DB2 purescale出来后&＃xff0c;如果市场非常认可&＃xff0c;相信Oracle也能很快采用Infiniband搞出集中式架构。不过成本和平台锁定也是Oracle必须考虑的一个问题&＃xff0c;因为RAC已经成为一种主流&＃xff0c;如果由于成本和平台的锁定而曲高和寡&＃xff0c;Oracle RAC未必会很快转向集中架构。让我们拭目以待Oracle的反击。