DB2 purescale vs Oracle RAC

Previously, Oracle's Real Application Cluster (RAC) has always been promoted. We recommend that you use RAC for large database applications, because RAC also addresses the performance expansion and high reliability requirements of these customers. The other two competitors of Oracle, IBMDB2 and Microsoft SQL Server, only use Cluster to meet high reliability requirements, which wastes the processing capability of one machine. To expand the processing capability, one way is to Scale Up, that is, to use a larger machine. Another method is to adopt the MPP architecture. However, to achieve relatively linear performance expansion, you must carefully design the database structure, data partitions, and applications. Otherwise, the performance will be greatly affected. There are no two methods.
I recently downloaded some IBM DB2 purescale White Papers and carefully studied them. I found that DB2 purescale is more advanced than Oracle RAC. If you have large database application requirements, you can consider using DB2 purescale. You can download an IBM DB2 purescale technology manual for transparent application scaling to learn more about the comparison between purescale and RAC. Of course, in this book, IBM repeatedly emphasizes that Purescale is derived from the mainframe lineage and deliberately lists some extremely unfavorable scenarios for RAC, although there is a probability size problem, however, in terms of its fundamental implementation principle, Purescale is more advanced than RAC.
Purescale also integrates high reliability and transparent application scalability, and expands Cluster Server members by means of share disk. Unlike Oracle RAC, Purescale uses the PowerHA purescale component to provide centralized lock management and global cache, while Oracle RAC uses Distributed Lock Management and distributed cache. Due to Distributed Management, RAC increases with the number of cluster nodes. In extreme cases (for example, when multiple nodes modify data in the cache managed by another node at the same time ), the complexity of communication and coordination between multiple nodes will increase exponentially, and IP interruption and CPU transfer will greatly reduce the processing efficiency. In contrast to purescale, global lock management and global cache, all nodes communicate with the global CF (cluster accelerator). To obtain global cache data, you can directly use RDMA (remote Direct memory access) memory for replication, avoid high-cost inter-process communication. Because the use of CF to globally manage locks and caches greatly simplifies management, purescale can be expanded to 128 nodes, while maintaining better performance linearity.
Of course, to ensure high-speed communication between CF and each node and ensure that the allocated CPU time does not need to be transferred before obtaining the CF response, purescale uses Infiniband to interconnect nodes and CF, compared with the common gigabit network used by RAC, the hardware cost has increased a lot. Currently, purescale only supports Power Systems (because the PowerHA Purescale component is used), that is, IBM minicomputers. RAC supports various Unix, Linux, and Windows platforms, which is also a limitation of purescale. Fortunately, purescale is only positioned at the high end, while many large database applications currently use Unix platforms, while IBM's Power platform is also the No. 1 choice in Unix, therefore, this limitation is not a big problem.
Of course, apart from the above two points, DB2 Purescale still has some defects. Because CF is used, and two more servers are required to ensure high reliability, this is an extra cost compared with Oracle RAC. In addition, PowerHA should not be free of charge. As the number of nodes increases, the cost should also increase. More importantly, because the global cache is stored on the CF machine, the maximum global cache capacity is the total memory of the machine. As the number of nodes increases, this cache does not increase unless the memory of the CF machine is increased, which may also become a global bottleneck.
However, Oracle RAC was originally designed to imitate DB2 for z/OS, but the Infiniband Technology had not yet come out, so it had to adopt a distributed architecture on an open platform. After the release of DB2 purescale, we believe that Oracle will soon adopt Infiniband to build a centralized architecture if it is well recognized by the market. However, cost and platform locking are also a problem that must be considered by Oracle. Because RAC has become a mainstream issue, Oracle RAC may not be quickly switched to a centralized architecture due to the high cost and locking of the platform. Let's wait and see Oracle's counterattack.