RAC更适合跑OLTP还是OLAP？

anlinew

原帖由 blue_prince 于 2008-11-20 16:24 发表


如果现有系统跑得好好的，当然就不用操心了。
但是假如现有系统已经出现了性能瓶颈，这时候你需要重新规划选型，而且也具备条件进行测试，这步就可以做了。我们做任何事情都是在有明确目的的前提下去做的。

那么有没有做对比的测试呢，比如做同比投入所能采用的其他架构的测试，并进行对比
比如一台同比投入能采购的单台高性能服务器的架构，又比如既然RAC需要分割才能够达到比较好的效果，而同样分割shared nothing的UDB是不是能更好呢

blue_prince

呵呵，我们都对比过4节点的RAC和4节点的TERADATA相同测试环境的测试，我们主导测试，优化由厂商来想办法。当初相同测试案例下RAC甚至比TERADATA还好，加上成本上的巨大优势，最终确定了我们选择RAC的方案。

anlinew

再一次体会到做甲方或者做项目的好处
问题范围基本可控，可根据项目实际情况选择最优的方案
而做产品就要兼顾不同用户使用情况，新技术、新产品能不用就不用，束手束脚，很是难受

tolywang

当初上RAC 就是因为业务涵盖 OLTP , OLAP ，没有办法才上的 。 也是多用业务分割这样的方式 。  
尝试使用负载均衡

blue_prince

原帖由 battleman 于 2008-11-20 16:32 发表



是啊，不过总感觉ASM不是很成熟，OLTP不敢轻易上啊

ASM是黑盒子，出现单块ASM盘损坏就需要重建整个DISK GROUP，这个非常被动。假如你ASM盘没有冗余的话。其实OLTP上也是可以上的，采用STANDBY，当然STANDBY要能够接管，这样ASM假如宕掉的话，STANDBY也能够接管过来。
实际使用过程中，ASM的管理便利性、性能确实是很不错的，但是也出过问题，弄得非常被动，幸好最终把问题解决了。

anlinew

原帖由 blue_prince 于 2008-11-20 16:40 发表
呵呵，我们都对比过4节点的RAC和4节点的TERADATA相同测试环境的测试，我们主导测试，优化由厂商来想办法。当初相同测试案例下RAC甚至比TERADATA还好，加上成本上的巨大优势，最终确定了我们选择RAC的方案。

我们试过4node的RAC
不做业务分割时性能一塌糊涂。。。。

内部通信差点儿，千兆网卡

几年前的事了。。。

blue_prince

原帖由 anlinew 于 2008-11-20 16:40 发表
再一次体会到做甲方或者做项目的好处
问题范围基本可控，可根据项目实际情况选择最优的方案
而做产品就要兼顾不同用户使用情况，新技术、新产品能不用就不用，束手束脚，很是难受

我们有个优势就是想测试什么东西，基本上跟厂商打个招呼，他们立马就能够把最新的设备送过来进行测试，假如他们能够提供的话。然后我们再根据自己的应用需求以及规划进行测试选型，这个确实有比较大的好处，很锻炼人。

battleman

原帖由 blue_prince 于 2008-11-20 16:45 发表


ASM是黑盒子，出现单块ASM盘损坏就需要重建整个DISK GROUP，这个非常被动。假如你ASM盘没有冗余的话。其实OLTP上也是可以上的，采用STANDBY，当然STANDBY要能够接管，这样ASM假如宕掉的话，STANDBY也能够接管过来。
实际使用过程中，ASM的管理便利性、性能确实是很不错的，但是也出过问题，弄得非常被动，幸好最终把问题解决了。

相对文件系统来说，ASM对OLAP的IO提升应该比较可观吧

blue_prince

原帖由 anlinew 于 2008-11-20 16:47 发表

我们试过4node的RAC
不做业务分割时性能一塌糊涂。。。。

内部通信差点儿，千兆网卡

OLAP？也不至于差这么多吧，不过确实也需要调整应用，当初我们从单机到RAC时调整了一堆的SQL，然后还要把SQL给优化好，这个不是简单的工作。刚开始上RAC时也是经历过很多痛苦的。
调整主要是一个个来进行调整，总会调整好的。

blue_prince

原帖由 battleman 于 2008-11-20 16:48 发表



相对文件系统来说，ASM对OLAP的IO提升应该比较可观吧

ASM其实提供了类似于祼设备的性能，相对文件系统来说也就是少了文件系统缓存和文件系统管理开销这一层。
ASM实际测试和运行中，底层的硬盘IO分布非常均衡，能够充分把磁盘利用起来，而且比祼设备管理方便多了。
总体来说ASM还是非常不错的，这个也是ORACLE以后数据文件存储的方向，我比较赞成使用ASM。