數據庫集群技術市場分化
甲骨文都以其實時應用集群技術(RealApplicationCluster，RAC)統治著集群數據庫市場。不過現在情況似乎有所改變，數據庫集群市場似乎開始出現了分化。
人們希望對數據庫實施集群技術主要有三個原因。***個原因是出于性能方面的考慮，因為數據庫集群可以讓你把進程負荷在多個節點中展開;其二是為了提高數據庫的可擴性，讓你可以在更大的系統上獲得合理的性能;而第三個原因是為了實現高可用性，嚴格的講，應該是持續可用性(兩者之間的區別在于前者可以保護你免受計劃外的中斷運行之害，而后者意味著你還可以進行有計劃的停機維護管理)。
部分供應商似乎主要將重點放在了可用性上。例如，xkoto公司(該公司為DB2提供集群技術)最初的計劃本來是著眼于DB2的性能，不過他們現在的立場已經發生了變化，他們現在認為“性能固然重要，但真正需要解決的問題是持續可用性”。
類似的情況也出現在Sybase身上，Sybase在今年年初時發布了ASEClusterEdition，對持續可用性的強調程度和性能不相上下，Sybase同時強調其優于甲骨文RAC的特點，包括自動平衡負載和自動故障恢復等降低管理負荷的功能。
不過，也有不少公司仍然將關注的重點放在性能上。IBM在上周舉行“信息隨需而變”EMEA大會上就有一個關于網格化(或集群)信息服務器的演講。實施上，對于數據集成產品而言這是一個相當酷的功能，因為你將可以遠離同樣的可用性問題，例如如果你有一個并行ETL作業正在運行，而其中某個流中斷了，也沒什么大不了的，你只需要將其重新分配到另外一個節點就可以了，不需要進行用戶鏈接故障轉移。DATAllegro當然也支持網格運算，出于性能方面的考慮也為了實現持續可用性，而Vertica也支持集群技術。
不過，在數據倉庫領域最讓人玩味的也許就是EXASOL了，它采取了完全不同的辦法，為Linux內核構建了一個擴展，稱之為EXAClusterOS用來支持其數據倉庫，就算不能支持上千個節點，也能支持數百個節點(通過內置式負載平衡，目的是在采用低價硬件的情況下優化性能)，同時仍然可以實現持續可用性。
事實上，***說的那種方法聽起來似乎非常合理：我們何不放棄在數據庫水平實施集群，而在操作系統實施集群呢?這樣做好處良多，你可以通過一個操作就可以引導整個集群，而不需要分別單獨地引導各個節點。而且，你可以構建其他相關的功能納入到操作系統當中(EXASOL正是這樣做的)。所以，如果有誰正在考慮如何才能在數據庫中利用集群技術的問題的話，不妨考慮采用EXASOL公司的方法。
【編輯推薦】
