RAC更适合跑OLTP还是OLAP？

rollingpig

当就可用性而言，用RAC 在高并发时可能还不如Failover, 因为Bug的原因。
而OLTP比OLAP更看重可用性。
至于CPU, 如果一个OLAP系统的瓶颈在CPU, 那么，用RAC从理论上来说的确可以缓解

shahand

巴乔硬整12节点  能不郁闷么  

anlinew

原帖由 rollingpig 于 2008-11-20 09:32 发表
当就可用性而言，用RAC 在高并发时可能还不如Failover, 因为Bug的原因。
而OLTP比OLAP更看重可用性。
至于CPU, 如果一个OLAP系统的瓶颈在CPU, 那么，用RAC从理论上来说的确可以缓解

瓶颈在CPU的OLAP系统，哪儿找啊

cpu的IO处理能力从来都不会成为短板的吧
最多5个核，IO系统就满负荷了

[php]
select /*+ parallel(t 3) */ dr from big t;
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             240.50     59564.00         4.00     119128          8

avg-cpu:  %user   %nice    %sys %iowait   %idle
          27.16    0.00    1.04   12.04   59.76

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             239.50     59584.00         0.00     119168          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          27.67    0.00    1.21   11.93   59.18

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             238.50     59292.00         0.00     118584          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          27.28    0.00    0.89   11.90   59.94

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             237.50     59580.00         0.00     119160          0




select /*+ parallel(t 5) */ dr from big t;
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             248.00     59420.00         0.00     118840          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          14.98    0.00    1.31   11.00   72.71

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             239.50     59164.00         0.00     118328          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          14.97    0.00    1.21   11.02   72.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             246.00     59472.00         0.00     118944          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          15.20    0.00    1.26   10.92   72.62

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             245.50     59708.00         0.00     119416          0




select /*+ parallel(t 10) */ dr from big t;

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             242.50     59520.00        28.00     119040         56

avg-cpu:  %user   %nice    %sys %iowait   %idle
          15.05    0.00    0.92   10.93   73.10

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             239.50     59512.00         0.00     119024          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          15.16    0.00    1.15   11.26   72.42

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             244.50     59864.00         0.00     119728          0

avg-cpu:  %user   %nice    %sys %iowait   %idle
          17.05    0.00    1.55   19.36   62.04

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             238.50     59436.00         0.00     118872          0
[/php]

[ 本帖最后由 anlinew 于 2008-11-20 09:53 编辑 ]

anlinew

原帖由 rollingpig 于 2008-11-20 09:32 发表
当就可用性而言，用RAC 在高并发时可能还不如Failover, 因为Bug的原因。
而OLTP比OLAP更看重可用性。
至于CPU, 如果一个OLAP系统的瓶颈在CPU, 那么，用RAC从理论上来说的确可以缓解

目前RAC可用性还不如传统HA系统，这个我信
但与没有相关措施的单PC server 系统比呢？

因为bug的原因导致RAC可能出现这样那样的问题，那么是否可以通过业务分割等手段避开呢？

blue_prince

这个其实也讨论过多次，在我们这边RAC就是在DW里面使用。我们的DW由于有着太多海量数据的运算，如果使用单机的话，那么单机的配置要求非常高，而且可扩展性也不强，单机只能通过加CPU、内存来扩容。这个从成本上和可扩展性来说单机都没有优势。而使用了RAC以后，可以利用RAC集群强大的并行计算能力将各种运算分布到各个节点上运行，虽然说有CACHE FUSION或者并行跨节点的开销，但是实际使用中效果还是比较良好的。我们有使用普通千兆网卡的内部互联，有使用基于INFINIBAND高速互联的RDS方案，内部互联就从来不是瓶颈。当然RDS的话跨节点并行性能会好很多，千兆网卡我们就尽量不使用跨节点并行，让一个语句尽量在单节点上并行，多条语句可以跨越在不同节点上跑，这样性能从也是不错的。

blue_prince

说一下业务分割吧，这个也是可行的，浙江移动几乎所有的关键系统都运行在RAC上面，他们也都是业务分割了，一个节点就跑一个自己的东西，互不相干，这样可能会好一些，因为跨节点的争用就会少了许多，实际使用我感觉这也是比较成熟可靠的运行方式。虽然这样违背了RAC设计的初衷，RAC更建议通过SERVICE来分离应用，可以做到SERVICE的接管，不过这样其实一个节点就是一个独立的SERVICE，也可以再设置SERVICE，做到一个节点一个SERVICE，其他节点可以接管，这样对用户来说宕一个节点是透明的。

anlinew

原帖由 blue_prince 于 2008-11-20 09:58 发表
这个其实也讨论过多次，在我们这边RAC就是在DW里面使用。我们的DW由于有着太多海量数据的运算，如果使用单机的话，那么单机的配置要求非常高，而且可扩展性也不强，单机只能通过加CPU、内存来扩容。这个从成本上和可扩展性来说单机都没有优势。而使用了RAC以后，可以利用RAC集群强大的并行计算能力将各种运算分布到各个节点上运行，虽然说有CACHE FUSION或者并行跨节点的开销，但是实际使用中效果还是比较良好的。我们有使用普通千兆网卡的内部互联，有使用基于INFINIBAND高速互联的RDS方案，内部互联就从来不是瓶颈。当然RDS的话跨节点并行性能会好很多，千兆网卡我们就尽量不使用跨节点并行，让一个语句尽量在单节点上并行，多条语句可以跨越在不同节点上跑，这样性能从也是不错的。

以你的经验来看对12个node的RAC所能达到的计算性能与用其投入的一半或1/3所能买到的高性能node的计算性能相比情况会如何？

blue_prince

OLAP里面的确IO是主要的瓶颈，但是单机的话你要扩展IO能力，除了主机的CPU、内存配置要高以外，你可能要装很多很多的HBA卡来提升IO能力，因为HBA卡也有瓶颈。像HP和ORACLE联合创造单机的DW记录，后端接了1000台HP MSA 1000存储，为了处理这么多存储的IO能力，那么主机上需要配置非常多的HBA卡才能达到效果。当然为了测试创造纪录这个你想怎么整都可以怎么整，但是实际使用你总得考虑成本吧，这些可是用钱堆起来的。
RAC的话我可以弄一大批PC SERVER堆积起来，现在PC SERVER的处理能力非常强劲，已经不逊色于P550，P570之类的小型机了，但是成本都是低得多。而且PC SERVER的配件也比小型机便宜得多，我可以在PC SERVER上配置足够的CPU、内存、HBA卡来提升运算能力和IO处理能力，这样无论从水平扩展和垂直扩展的角度来说都是比单机更适合。

anlinew

原帖由 blue_prince 于 2008-11-20 10:03 发表
说一下业务分割吧，这个也是可行的，浙江移动几乎所有的关键系统都运行在RAC上面，他们也都是业务分割了，一个节点就跑一个自己的东西，互不相干，这样可能会好一些，因为跨节点的争用就会少了许多，实际使用我感觉这也是比较成熟可靠的运行方式。虽然这样违背了RAC设计的初衷，RAC更建议通过SERVICE来分离应用，可以做到SERVICE的接管，不过这样其实一个节点就是一个独立的SERVICE，也可以再设置SERVICE，做到一个节点一个SERVICE，其他节点可以接管，这样对用户来说宕一个节点是透明的。

重OLTP的系统业务水平分割相对就简单一些，所以RAC的效果也就好一些，其扩展性也能高度利用起来，加个node，几乎就能得到一个node的性能提升，所以上RAC就更合适一些
而OLAP可能需要研究如何垂直分割更合适也谢

blue_prince

原帖由 anlinew 于 2008-11-20 10:08 发表

以你的经验来看对12个node的RAC所能达到的计算性能与用其投入的一半或1/3所能买到的高性能node的计算性能相比情况会如何？

当然会有很大的提升了，我们用来是使用4节点的RAC，这个之前也讨论过。我们扩容不仅仅是扩节点，也扩存储，呵呵，要不虽然主机处理能力提升了，存储跟不上可不行了。
我们就是因为业务的发展导致原来4节点RAC已经无法满足业务运算的需求了，才会规划上12节点的RAC。上12节点的RAC我们是根据现有的运算情况，以及公司的业务发展目标预估到的数据量和运算需求而上的。
选型一定要从成本、现有数据量和运算需求、未来数据量和业务增长需求来算，而这些都要根据过去系统运算的积累数据来估算，一般来说这个估算也是比较准确的。