RAC是否真的适合作为一种提高效率的方案

xjg

呵呵，居然敢说是骗人的

jining_han

如果有哪家RDBMS最好, 争论就会很少了.  没有一种产品是十全十美的, 所以就要辩证地去看问题,  而且要有发展的眼光.  我这里就"发展"谈些看法.

    如果你的公司从第一天开始就知道自己的规模有多大, 而且资本无限, 那么就到市场上看能不能找到一台马力够的单机,  一次性投资和创建, 把一辈子的事一次做完, 何乐而不为?

   对于从小到大, 从贫到富, 不是永远停滞不前的公司来说,   用RAC 作为起点, 好处就显而易见了(其实10gR2出来后,  应该用GRID, RAC 是奠基石).  一台大的单机到了容量不够时就头痛了,  你必须买一台更大的单机来替换, 越大的单机, DOWNTIME也会越长.  这时RAC的优势就显示出来.  

    省钱省时间, 减少DOWNTIME,  就是效率.

     如果效率用数据库的PERFORMANCE来衡量,  那就很难定夺了,  谁没有BOTTLE NECK呢?  IBM 用无数个GLOBAL VIEW 来融合各节的数据,  本人不太敢恭微.  充其量它也不过是把ORACLE 的 PARTITIONS 放到不同的 NODE 上.   不要仅仅看到RAC带来的OVERHEAD,  还要看到RAC 带来的LOAD BALANCING 和 cross-nodes 平行运算的潜力.  合理的使用是取得效率的最佳途径

rwq_

最初由 jining_han 发布
[B]如果有哪家RDBMS最好, 争论就会很少了.  没有一种产品是十全十美的, 所以就要辩证地去看问题,  而且要有发展的眼光.  我这里就"发展"谈些看法.

    如果你的公司从第一天开始就知道自己的规模有多大, 而且资本无限, 那么就到市场上看能不能找到一台马力够的单机,  一次性投资和创建, 把一辈子的事一次做完, 何乐而不为?

   对于从小到大, 从贫到富, 不是永远停滞不前的公司来说,   用RAC 作为起点, 好处就显而易见了(其实10gR2出来后,  应该用GRID, RAC 是奠基石).  一台大的单机到了容量不够时就头痛了,  你必须买一台更大的单机来替换, 越大的单机, DOWNTIME也会越长.  这时RAC的优势就显示出来.  

    省钱省时间, 减少DOWNTIME,  就是效率.

     如果效率用数据库的PERFORMANCE来衡量,  那就很难定夺了,  谁没有BOTTLE NECK呢?  IBM 用无数个GLOBAL VIEW 来融合各节的数据,  本人不太敢恭微.  充其量它也不过是把ORACLE 的 PARTITIONS 放到不同的 NODE 上.   不要仅仅看到RAC带来的OVERHEAD,  还要看到RAC 带来的LOAD BALANCING 和 cross-nodes 平行运算的潜力.  合理的使用是取得效率的最佳途径 [/B]

RAC从理论上来说，是不错的，他真的带来的LOAD BALANCING 和 cross-nodes 平行运算的潜力吗？也许，顺理想的条件下是可以的，可实际上吗？
你试试把四个、五个、六个以上的节点做成一个RAC试试看。看看性能如何？看看出问题时，处理的难度如何。

yanggq

有钱按有钱的方式花，没钱就别折腾那么多

fanyu_yu

长远看,确实是使用阵列,在不替换原有机器的情况更换,增加新的机器就能够获得更好性能是一个好的方法,但是感觉,这项技术从9i出来到现在10g还不是很成熟,我考虑的是性价比,
不是钱,再有钱总要物有所值的使用,单位的数据集中能力不好,想慢慢集中起来,随之来的风险很大,所以看看有什么好的解决方法,对oracle熟点,就想用它看看有什么方案,就看到rac了,
10g的rac改进不少,但是这东西经过时间的考验还短了点,不敢用,9的方法和10一对比就不想用了.

jining_han

本人觉得能纵向集中就尽量纵向集中.  当纵向达到极限,  我们又回到主题了

还是版主说的好, "有钱按有钱的方式花，没钱就别折腾那么多"  所以MAINFRAME仍然不败啊!