关于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透明的横向扩展性远远优于Rac,在64个节点时候仍然能够达到95%的横向扩展性.达到128个节点完全没压力.
而且Purescale的横向扩展性对应用是透明的,Purescale 无需应用或数据库分区的可伸缩性
支持 RDMA 访问的集中锁定和全局缓冲池可以带来高可伸缩性，而不会让应用集群感知到
数据页面的共享将在实际共享的缓存中通过 延迟最低的RDMA（remote direct memory access）通讯协议来实现
不需要通过应用或数据分区来实现可伸缩性
降低了管理和应用开发成本
RAC 中的分布式锁定会增加开销并降低可伸缩性
Oracle RAC 最佳实践建议
每个页面使用较少的行（避免热页面在不同nodes间 利用上下文频繁切换的RDS协议数据信息 锁信息 同步）
通过数据库分区来避免热页面
通过应用分区来获取一定水平的可伸缩性
所有这些都会造成管理和开发成本巨大增加
有4个节点Poc测试表明, 在4个节点的数据完全没有融合时候大家效率都不错, 但是各个节点之间的数据需要相互同步和更新时RAC性能衰减非常厉害.性能甚至不如2个节点.
2. 对于第三点.
高大上的硬件是性能的有效保证. 为了高性能就必须要有必要的投入.收起
Purescale透明的横向扩展性远远优于Rac,在64个节点时候仍然能够达到95%的横向扩展性.达到128个节点完全没压力.
而且Purescale的横向扩展性对应用是透明的,Purescale 无需应用或数据库分区的可伸缩性
支持 RDMA 访问的集中锁定和全局缓冲池可以带来高可伸缩性，而不会让应用集群感知到
数据页面的共享将在实际共享的缓存中通过 延迟最低的RDMA（remote direct memory access）通讯协议来实现
不需要通过应用或数据分区来实现可伸缩性
降低了管理和应用开发成本
RAC 中的分布式锁定会增加开销并降低可伸缩性
Oracle RAC 最佳实践建议
每个页面使用较少的行（避免热页面在不同nodes间 利用上下文频繁切换的RDS协议数据信息 锁信息 同步）
通过数据库分区来避免热页面
通过应用分区来获取一定水平的可伸缩性
所有这些都会造成管理和开发成本巨大增加
有4个节点Poc测试表明, 在4个节点的数据完全没有融合时候大家效率都不错, 但是各个节点之间的数据需要相互同步和更新时RAC性能衰减非常厉害.性能甚至不如2个节点.
2. 对于第三点.
高大上的硬件是性能的有效保证. 为了高性能就必须要有必要的投入.收起
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这两年才出来的新东西，使用的客户也相对较少，应该说任重而道远吧。收起
赞同你的看法啊，我现在也觉得还是scale up比较实用，如果有几十个CPU的服务器，接口卡也够多和强悍的化，我绝对不会选8C64G的服务器集群，scale out真的也就在hadoop中比较有用，在传统OLTP市场一点都不实用。
回复 daolin2005 我不认为集中式的CF彻底解决scale out的问...回复 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来的线性。收起
purescale在V10.5可以使用非IB网了
浏览2078
浏览2210
浏览2147