在很长一段时间里，甲骨文都以其实时应用集群技术(Real Application Cluster，RAC)统治着集群数据库市场。不过现在情况似乎有所改变，数据库集群市场似乎开始出现了分化。
在很长一段时间里，甲骨文都以其实时应用集群技术(Real Application Cluster，RAC)统治着集群数据库市场。不过现在情况似乎有所改变，数据库集群市场似乎开始出现了分化。
人们希望对数据库实施集群技术主要有三个原因。第一个原因是出于性能方面的考虑，因为数据库集群可以让你把进程负荷在多个节点中展开;其二是为了提高数据库的可扩性，让你可以在更大的系统上获得合理的性能;而第三个原因是为了实现高可用性，严格的讲，应该是持续可用性(两者之间的区别在于前者可以保护你免受计划外的中断运行之害，而后者意味着你还可以进行有计划的停机维护管理)。
部分供应商似乎主要将重点放在了可用性上。例如，xkoto公司(该公司为DB2提供集群技术)最初的计划本来是着眼于DB2的性能，不过他们现在的立场已经发生了变化，他们现在认为“性能固然重要，但真正需要解决的问题是持续可用性”。
类似的情况也出现在Sybase身上，Sybase在今年年初时发布了ASE Cluster Edition，对持续可用性的强调程度和性能不相上下，Sybase同时强调其优于甲骨文RAC的特点，包括自动平衡负载和自动故障恢复等降低管理负荷的功能。
不过，也有不少公司仍然将关注的重点放在性能上。IBM在上周举行“信息随需而变”EMEA 大会上就有一个关于网格化(或集群)信息服务器的演讲。实施上，对于数据集成产品而言这是一个相当酷的功能，因为你将可以远离同样的可用性问题，例如如果你有一个并行ETL作业正在运行，而其中某个流中断了，也没什么大不了的，你只需要将其重新分配到另外一个节点就可以了，不需要进行用户链接故障转移。DATAllegro当然也支持网格运算，出于性能方面的考虑也为了实现持续可用性，而Vertica也支持集群技术。
不过，在数据仓库领域最让人玩味的也许就是EXASOL了，它采取了完全不同的办法，为Linux内核构建了一个扩展，称之为EXACluster OS用来支持其数据仓库，就算不能支持上千个节点，也能支持数百个节点(通过内置式负载平衡，目的是在采用低价硬件的情况下优化性能)，同时仍然可以实现持续可用性。
事实上，最后说的那种方法听起来似乎非常合理：我们何不放弃在数据库水平实施集群，而在操作系统实施集群呢?这样做好处良多，你可以通过一个操作就可以引导整个集群，而不需要分别单独地引导各个节点。而且，你可以构建其他相关的功能纳入到操作系统当中(EXASOL正是这样做的)。所以，如果有谁正在考虑如何才能在数据库中利用集群技术的问题的话，不妨考虑采用EXASOL公司的方法。
原创文章，未经许可，严禁转载！
最新评论