以前一直推崇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組件來提供集中化的鎖管理和全局緩存，而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的反擊。
