Oracle在面向数据仓库的解决方案中,采用的是RAC架构,它的全称是Real Application Clusters,即“真正应用集群”。下面,我们从几个角度分别来看看RAC的特点。
从逻辑结构上看,与DB2的“Share-Nothing”不同的是,RAC采用的是“Share-Disk”技术,集群中每个节点上的实例(Instance)都访问同一个数据库。这样的结构在扩展性方面会有很多问题,例如随着节点的增多,节点间的通信、协调的复杂程度就呈几何级数上升,管理难度非常大。
从易用性的角度看,RAC的补丁安装非常复杂;另外,RAC的实施比较复杂,涉及网络、存储设备、操作系统、集群软件、数据库产品等,一旦出了问题,定位问题非常困难。
从稳定性的角度看,RAC的稳定性也有很大的问题。例如在双节点的RAC环境中,Oracle的运维人员有时候发现两个节点中一个正常运行、而另一个被锁死的情况;也会出现因RAC上线导致数据库系统的性能急剧下降;甚至RAC由双机运行变成单机运行,双机完全成为摆设的情况也屡见不鲜。
从扩展性的角度看,RAC可以增加节点提升集群的处理能力。但是所有的节点(包括新增节点)访问同一个共享磁盘集群,这意味着所有的查询都要访问相同的底层存储设备,从而会受到I/O瓶颈的限制。
下面,我们给出DB2数据仓库与Oracle数据仓库的对比总结,如下表所示:
DB2与Oracle数据仓库技术对比总结
比较内容 |
DB2 |
Oracle |
采用的架构名称 |
DPF |
RAC |
架构特性 |
真正的 MPP |
数据库层的SMP集群+共享磁盘的MPP存储层 |
易用性 |
安装、维护简单,无需调整应用 |
安装、配置复杂,维护难度大,需要经常进行调整 |
稳定性 |
简单、稳定 |
复杂、稳定性差 |
扩展性 |
极易扩展,不存在瓶颈 |
扩展性无法突破I/O瓶颈 |
总结 |
专为数据仓库设计的架构 |
为OLTP系统设计的架构,不适合数据仓库 |
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论