RAC解决了什么问题?
RAC系统具有的HA、Load Balance、FailOver特性,这些优点自然不必多言。从系统性能的角度考虑,RAC主要是对数据库系统的CPU以及内存资源进行了扩充。
目前主流的集群架构主要有两种,SMP:多处理器结构(Symmetric Multi-Processor)、MPP:海量并行处理结构(Massive Parallel Processing)。常见的传统数据库,DB2集群是MPP架构,Oracle集群是SMP架构。对于DB2集群来说,每个集群节点都是一个独立的作业单元。对于Oracle集群来说,每个集群节点只有CPU和内存是独立的,但IO存储资源却是共享的。这也就是前面说的,RAC虽然号称高可用性。但从本质上来说,RAC集群只是扩展了数据库系统的CPU及内存资源,IO方面依然存在单点故障的可能。
RAC架构虽然在IO方面没有太大的优化,但在增加了内存的情况下,它本身就会减少数据库系统的IO访问量,这也是一种能力的提升。但这种提升是对系统整体而言的,对于单条SQL而言,在单实例或者RAC中执行,性能上并没有大的差别。甚至,在RAC访问中变得慢一些也是正常的。
我们是否需要RAC?
通过上面的分析,RAC对数据库性能而言,在CPU以及内存方面进行了扩充,在IO方面的提升并不是特别明显。当我们在讨论是否需要RAC时,我们需要回答一个问题:我们的系统瓶颈是什么?这里举两个例子以示说明。
一个系统是某零售商ERP系统,由于一些原因,在该ERP生产系统中,一直存在大量拉报表数据的情况,占用了系统很大的IO资源。更加离谱的是,为了让报表拉得更快,还在生产系统加添加了大量的并行。一旦开启报表功能,整个系统瞬间变慢。后来,投入巨大人力物力,将系统改造成了RAC架构,但系统性能依然没有大的提升。很显然,如果系统本身的瓶颈就是IO资源,即使改用RAC架构,对于解决问题也没有帮助,或者说帮助并不明显。在这个案例中,最直接的办法就是把报表功能剥离出去,重新建议一套报表系统,在生产与报表系统之间建立数据同步,从而解决问题。
另一套系统是电商系统,由于业务需要实时计算一些数据,因此在后台开启了10多个实时进程。每个实时进程其实就是一个死循环,以实现对数据的实时处理。在这种情况下,可以简单的理解为仅仅这个实时功能就需要消耗10多个逻辑CPU资源为其提供服务,那么在这种情况下是否可以考虑RAC呢?答案应该是肯定的,可以通过RAC让系统增加更多的资源以满足计算需要。但同时,也存在另一个网络问题。当实时计算存在于某一个节点的时,这也意味着它需要同另一个节点进行巨大的数据交换操作。如果私网的性能不够强大,那必然会出现节点经常重启的故障。甚至在更严重的情况下,拖累整个系统的性能。
理论总是很美好,现实总是很残酷。在上马RAC之前,一定要分析系统的瓶颈所在,对症下药方能从根本上解决问题。
![](http://img.blog.itpub.net/blog/attachment/201605/12/26798543_14630328068Gfs.jpg?x-oss-process=style/bb)
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26798543/viewspace-2098517/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26798543/viewspace-2098517/