数据库集群方案比较与选择

评价两种技术

共享磁盘集群是和DEC的OpenVMS集群一起成长起来的，OpenVMS使用共享磁盘硬件，这样在集群里的任何VAX机都能访问任何磁盘块。DEC自己的Rdb数据库，后来被Oracle采用，而Oracle的OPS，最初也是为OpenVMS集群编写的，所以我们可以理解为何OPS基于共享磁盘。

共享磁盘设计里，真正困难的任务，特别是对于数据库来说的困难是，不管哪个节点正在写哪个磁盘，都要确保集群里所有的计算机有完全一致的、全部共享磁盘的映像。解决这一难题的办法是共享的锁定管理部件，这个部件可以保证在一个时间内，只能有一个节点写入特定磁盘块，而每节点的本地磁盘缓冲不保留过期数据的拷贝。

共享磁盘技术的优势在于，一旦锁定管理器开始工具，它就可以提供一个与非集群系统类似的编程环境。

所以，根据Hal Berenson的观点（DEC向数据库加入集群功能时，他是Rdb产品的开发主管），在市场上推出共享磁盘数据库要比编写一个“不共享”系统要快许多。

Berenson说：“对于 Rdb，我们采用了与VMS集群相同的技术。加入集群的最简单方法不是对数据库系统进行大的修改。我们在数据库系统里使用相同的缓冲系统，相同的I/O机制，和相同的锁定架构。如此扩展之后，不管你在哪个节点上运行，你可以确保多个实例彼此不会互相干扰。”

伸缩性被证明是共享磁盘设计的长远问题。“我们在Rdb里发现的问题是，我们永远得不到足够低的流量，能够线性地扩充集群的规模” Berenson 说，“你可以把规模扩大到3到4个节点，但是超过这个界限之后，系统性就无法再继续增长。”

后来微软聘请了Berenson ，帮助他们修正SQL Server 7.0的发行版， 他这时开始力推“不共享”设计。

IBM著名的工程师，IBM“不共享”数据库的首席设计师　Gilles Fecteau认为，与现代的数据库系统一样，对于使用行级锁的数据库，高级别的锁定管理器流量是个特别突出的问题。

Fecteau 说：“如果拥有一个使用行级锁的OLTP [在线交易处理]系统，那么必须检测所有者是谁。这会生成大量的小消息。共享磁盘拥有的小消息是“不共享”系统的小消息的100倍。”

与共享磁盘设计相比，“不共享” 设计，比如IBM的 DB2 EEE, Informix 的 Extended Parallel Server 和微软的 SQL Server 2000，并不四处传递锁定或者磁盘块。他们实现了一种函数传递（function shipping）技术，这种技术把查询划分成查询片断，每个子查询被发送到拥有要查询的数据集的节点上。

每个节点接着访问所有必需的本地磁盘块，把查询结果通过线路发送回去－这就象集簇数据库使用的存储过程。结果是，“不共享”的会话要比共享磁盘设计少许多。

“不共享” 数据库还能更好地利用磁盘缓存，因为在本地缓存和本地磁盘资源之间，有一对一的对应关系。如果某个磁盘块正好处于某个集群节点的缓存里，那么可以一直从缓存里取得这个磁盘块。

在使用共享磁盘的时候，如果一个节点需要一个磁盘块，而这个磁盘块又恰好在另一个节点的磁盘缓存里，那么第一个节点一般来说，必须从磁盘上再次读取这个磁盘块 (OPS 对这种情况做了些优化，所以不常出现这种情况。)

向高带宽网络进行的迁移，比如100MB、1GB甚至为期不远的10GB网络，以及向低延迟网络的迁移，比如Intel的VI架构，使得获取远程数据非常便宜，不管数据在远端的何处。如果数据在缓存里的话，访问速度甚至比访问本地硬盘的速度还要快。