关于DB2 purescale与Oracle RAC的对比
当然也可以说是PK吧，oracle的老大当时放言看不上任何关系数据库，唯独DB2 for z/OS，现在有着z/OS血统的purescale早来了好几年了，使用过的没使用过的使劲发言。发言好的加米啊可是，在此放出100袋大米(就不放苹果了)。
先说了一下我的感觉：个人感觉这个东西对硬件要求太高，以致于平民百姓接触到的比较少。Oracle RAC对我来说只是听说过，没有亲自操练过，应该是很稳定的东西了，purescale某些方面应该是超过RAC的，当然某些方面肯定不足。你在使用purescale或RAC方面如有经验，来吐槽吧，没准IBM的人听我们骂的多了会改进purescale呢，然后干掉RAC，最后大家的工资蹭蹭蹭的。。。。
先说了一下我的感觉：个人感觉这个东西对硬件要求太高，以致于平民百姓接触到的比较少。Oracle RAC对我来说只是听说过，没有亲自操练过，应该是很稳定的东西了，purescale某些方面应该是超过RAC的，当然某些方面肯定不足。你在使用purescale或RAC方面如有经验，来吐槽吧，没准IBM的人听我们骂的多了会改进purescale呢，然后干掉RAC，最后大家的工资蹭蹭蹭的。。。。
33同行回答
1. pureScale目前似乎只能4个节点，其中2个是CF节点，2个才是data node，而rac最好好像可以到128个node
2.pureScale当一个节点当机的时候针对select操作可以有效，但是针对dml语句只能回滚，而rac从12c开始支持dml语句了，也就是说当一个update语句在node1也上的时候突然node1当机，那么这个update事物会transfer到其他的node继续工作，而pureScale目前不能实现
3.pureScale必须用infiniband switch和卡以及必须通过gpfs才能实现，rac都没这些限制，相对于硬件要求rac需要较低
4.pureScale如果2个cf同时坏掉那么等于pureScale就不能用了，而rac如果四个节点就是坏了3个，剩下的一个也能继续使用
5.pureScale和rac都可以做两地双活模式，但对于专线要求较高，一般都是用黑光纤专线
6.从总体上来说rac还是比pureScale成熟很多的，因为从oracle8i开始就有rac了(ops)，发展这么多年了rac也非常成熟了，反之pureScale这两年才出来的新东西，使用的客户也相对较少，应该说任重而道远吧。收起
2.pureScale当一个节点当机的时候针对select操作可以有效，但是针对dml语句只能回滚，而rac从12c开始支持dml语句了，也就是说当一个update语句在node1也上的时候突然node1当机，那么这个update事物会transfer到其他的node继续工作，而pureScale目前不能实现
3.pureScale必须用infiniband switch和卡以及必须通过gpfs才能实现，rac都没这些限制，相对于硬件要求rac需要较低
4.pureScale如果2个cf同时坏掉那么等于pureScale就不能用了，而rac如果四个节点就是坏了3个，剩下的一个也能继续使用
5.pureScale和rac都可以做两地双活模式，但对于专线要求较高，一般都是用黑光纤专线
6.从总体上来说rac还是比pureScale成熟很多的，因为从oracle8i开始就有rac了(ops)，发展这么多年了rac也非常成熟了，反之pureScale这两年才出来的新东西，使用的客户也相对较少，应该说任重而道远吧。收起
回复 10# daolin2005
我不认为集中式的CF彻底解决scale out的问题，分布式锁有分布式锁的问题，但是对于查询操作，其节点可以直接通信无需第三个节点，反观CF机制，所有查询只要本地buffer cache没有而在别的member的buffer cache里面都可能要通过CF。因此在purescale做一个SAP的bank测试的时候，甚至出现了member负荷不高而CF CPU已经很忙无法压下去的情况。因此，在IBM自己的官方优化文档中，也很强调要避免全局锁和page reclaim(其本质和RAC的gc_buffer release/busy）一样
如果大家都用IB，一个用udapl，一个用rds，个人认为purescale也就在dml多的情况下，通信开销小点。udapl的确比rds效率高一点，但是DB2 purescale这种太新的实现抵消了这一点。用purescale的udapl对采用GE和UDP的RAC取胜是没悬念的，但是如果对手是基于RDS的Exadata，就不好说了。
purescale更大的问题在于IBM的purescale比单机版本db2的功能缺失，呵呵。
当然最大的问题在于IBM就是一大傻逼，经常忘记自己也有软件解决方案，时不时大力推什么SAP HANA解决方案。
对于复杂的OLTP，如果索引乱用，数据又不好分区，任何scale out方案都不如scale up来的线性。收起
我不认为集中式的CF彻底解决scale out的问题，分布式锁有分布式锁的问题，但是对于查询操作，其节点可以直接通信无需第三个节点，反观CF机制，所有查询只要本地buffer cache没有而在别的member的buffer cache里面都可能要通过CF。因此在purescale做一个SAP的bank测试的时候，甚至出现了member负荷不高而CF CPU已经很忙无法压下去的情况。因此，在IBM自己的官方优化文档中，也很强调要避免全局锁和page reclaim(其本质和RAC的gc_buffer release/busy）一样
如果大家都用IB，一个用udapl，一个用rds，个人认为purescale也就在dml多的情况下，通信开销小点。udapl的确比rds效率高一点，但是DB2 purescale这种太新的实现抵消了这一点。用purescale的udapl对采用GE和UDP的RAC取胜是没悬念的，但是如果对手是基于RDS的Exadata，就不好说了。
purescale更大的问题在于IBM的purescale比单机版本db2的功能缺失，呵呵。
当然最大的问题在于IBM就是一大傻逼，经常忘记自己也有软件解决方案，时不时大力推什么SAP HANA解决方案。
对于复杂的OLTP，如果索引乱用，数据又不好分区，任何scale out方案都不如scale up来的线性。收起
浏览754