数据库集群技术分析和比较

 

一、引言

 

数据库是用来保存计算的最终结果的，所以是整个信息系统的最重要组成部分。在许多人看来，当前的数据库技术已经可以说是非常地成熟了。然而，在满足不断增长的联机事务处理应用方面，当前的数据库技术其实还存在不少急迫需要解决的技术问题。

 

对于所有的数据库而言，除了记录正确的处理结果之外，它们都面临着四方面的挑战：如何提高处理速度，数据可用性、数据安全性和数据集可扩性，也就是说，如何使当前的数据库具有这四方面的可伸缩性，使客户能同时得到更高的处理速度、更高的数据可用性、更高的数据安全性和更大的数据集，而不是提升了其中的部分指标，却损坏了其余的指标或者其余的指标没有改进。随着IT应用的深入和有线，无线网络的快速增长，联机事务处理业务对以上四方面提出了更高的要求。

 

将多个数据库联在一起组成数据库集群来达到上述目标应该说是一个很自然的想法。理想的数据库集群应该可以做到以下几点：

 

◆      在需要更高数据库处理速度的时候，我们只需简单增加数据库服务器就可以了。这样可以大大减小硬件投资的风险，而且大大提高现有服务的质量。

 

◆     在任何时刻需要有多个随时可用的实时同步数据服务。为了防灾，最好有多个异地的同步数据服务。这不光会大大增加数据可用性，还会有意想不到的更高数据库处理速度的效益。

 

◆       除了密码保护之外，我们最好能控制企业内部对数据库的非法访问。

 

◆     数据集的可扩性可能是最简单的要求了。但是，用增加数据库服务器的办法来扩大数据集对数据可用性会产生负面影响。如果没有数据冗余，那么每增加一台服务器，整个系统的可用性就会成倍地降低。最好的结果是我们能任意增大数据集而没有对可用性的负面影响。

 

上述最后一条揭示了我们将面临的技术困难--除了异常简单的应用之外，有关数据库集群的技术都是非常困难和复杂的。更具挑战性的是，实际的应用要求上述几方面的指标能同时提升，而不是某一指标提升了，另外的指标却下降了。然而，所有的技术都是有副作用的，这就是当前数据库集群技术面临的重大困难。

 

客观地比较各种数据库技术是很困难的，比较各种数据库集群技术可见会更困难。本文试图对当前主要的数据库集群用到的具体技术进行分析，目的是评价每种技术的优缺点，并且按它们各自的设计目的和使用效益评分, 最后得出每种数据库集群的一个综合评价值。从而建立一个客观评价数据库集群技术的评价体系。 我们希望能用这个评价标准来评价现有的和今后将出现的数据库集群技术, 并且理清一些很容易混淆的概念。

 

为了使得这个研究更具实用价值， 我们还包括了两项和具体技术没有直接关系的评价：集群管理难易度和应用的透明度。

 

评分标准：每一项技术都用从0（不支持）分到1（支持最好）分给出评分，减分是按四分法来做， 所有的效益都大致分为四个梯度，按大约的比例减分。

 

 

二、数据库集群技术的分类

 

数据库集群用到的技术很自然地围绕着上述四方面的挑战而展开的。所以我们也围绕着这四个挑战来展开讨论，每个大指标又将分成几个子指标，每个子指标则对应一种为实现大指标而采用的特定技术。评价标准将给当前六大类数据库集群技术打分。欢迎读者来信对我们的评分标准提出质疑。

 

在开始讨论之前，值得指出的是，我们讨论的六大类数据库集群技术分属两类体系结构：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。

 

 

 

 

 

图 1. 共享磁盘或非共享磁盘的基于数据库引擎的集群技术

 

 

图 2. 基于数据库网关（中间件）的集群技术(不共享磁盘)

 

 

基于数据库引擎的集群技术要求数据库引擎本身具有集群功能（一般只有企业版的数据库才具有这种功能），而基于数据库网关（中间件）的集群技术则对数据库没有集群能力的要求。所以标准版或企业版都可以用。

 

在本文中，我们将评估下列数据库集群技术：

 

  Oracle’s Real Application Cluster (我们将称之为RAC).

  Microsoft SQL Cluster Server (我们将称之为MSCS).

.IBM’s DB2 UDB High Availability Cluster (我们将称之为UDB)

 Sybase ASE High Availability Cluster (我们将称之为ASE)

 MySQL High Availability Cluster (我们将称之为MySQL CS).

Parallel Computers Technology Inc.’s ICX-UDS middleware 我们将称之为ICX).

 

除了ICX，所有其它的集群技术都是基于数据库引擎的。所以ICX可以支持任何当前流行的数据库。

 

至于其他相关技术，如RAID（廉价冗余磁盘阵列）、磁盘镜像硬件（EMC的TimeFinder系列）、文件复制工具（如DoubleTake, Veritas and Legato），我们也将做简单评价和打分。我们会用DM来代表磁盘镜像 (Data Mirror)， FM 代表文件镜像（File Mirror）.

 

本文只限于讨论上述六类数据库集群系统和上述相关技术。如果有什么重要技术遗漏的话，欢迎读者和作者联系讨论。

 

三、数据库集群技术

1)提高数据库处理速度的技术

 

目前有四种提高数据库处理速度的办法：

 

◆    提高磁盘速度：这包括RAID和其他磁盘文件分段的处理。主要的思想是提高磁盘的并发度（多个物理磁盘存放同一个文件）。尽管实现方法各不相同，但是它们最后的目的都是提供一个逻辑数据库的存储映象。我们要评价的六个系统都能有效地利用这些技术。由于ICX已经有最大的磁盘冗余度，RAID 磁盘系统的设置应该侧重于速度，而不是数据冗余。这样磁盘利用的效益就会提高。

 

◆       分散数据的存放：主要思想是利用多个物理服务器来存放数据集的不同部分（一个数据库表格分散到多个服务器或者每个服务器分管几个内容不同的表格）。这些办法不但可以扩展数据集（数据集的可扩性），而且使得不同的服务器进行并行计算成为可能。例如，对于ORACLE的RAC来讲，由于它是共享磁盘的体系结构，你只需要简单地增加一个服务器节点，RAC就能自动地将这节点加入到它的集群服务中去。RAC会自动地将数据分配到这节点上，并且会将接下来的数据库访问自动分布到合适的物理服务器上，而不用修改应用程序。对于UDB来讲，因为它是非共享磁盘的体系结构，因此就必须手工修改数据的分区，MSCS和ASE也是同样的情况。MySQL也需要手工分区，并且是这几种数据库中支持分区的自动化程度最低的，也就是说，应用程序需要自己负责数据库的分布式访问。不管数据存放是如何实现的，分布式存放数据的缺点是对数据库的可用性有负面影响。任何一台服务器的损坏都会影响整个系统的可用性。但是，这是迄今为止各大数据库厂商能提供的业界最好的数据库集群技术了。ICX是一种基于中间件的数据库集群技术，它对客户端和数据库服务器都是透明的。因此，ICX可以用来集群几个数据库集群（一个逻辑数据库），也可以用于集群几个物理数据库服务器（来增强一个分管关键数据的物理服务器）。

 

◆       对称多处理器系统：此技术的思想是利用多处理机硬件技术来提高数据库的处理速度。但是，除了ICX，所有其它的数据库集群技术只支持单一的可修改的逻辑数据库。绝大部分的数据库事务处理是磁盘密集型的，纯计算负荷很小的，对称多处器技术在数据库上的应用的实际收益是很有限的。这也说明了为什么实际应用中最多只用了四个CPU的原因。所有的基于数据库引擎的集群都支持这个技术，ICX对SMP技术是中性的，因为它能把多个数据库服务器集合在一起构成一个集群，也能将多个现存的数据库集群集合在一起，构成集群的集群。

 

◆      交易处理负载均衡：此技术的思想是在保持数据集内容同步的前提下，将只读操作分布到多个独立的服务器上运行。因为绝大多数的数据库操作是浏览和查询,，如果我们能拥有多个内容同步的数据库服务器，交易负载均衡就具有最大的潜力（可以远远大于上面叙述的最多达四个处理器的对称多处理器系统）来提高数据库的处理速度，同时会具有非常高的数据可用性（真正达到5个9，即99.999%）。所有基于数据库引擎的集群系统都只支持一个逻辑数据库映象和一个逻辑或物理的备份。这个备份的主要目的是预防数据灾难。因此，备份里的数据只能通过复制机制来更新，应用程序是不能直接更新它的。利用备份数据进行交易负载均衡只适用于一些非常有限的应用，例如报表统计、数据挖掘以及其它非关键业务的应用。只有ICX能够做到同步复制多个数据库服务器从而达到在保持数据一直性前提下的真正的负载平衡。

 

上述所有技术在实际部署系统的时候可以混合使用以达到最佳效果。

 

2）提高数据库可用性的技术

 

根据物理法则，提高冗余度是提高数据库可用性的唯一途径。

 

提高数据库冗余度大致有四种方法：

 

◆       硬件级的冗余：主要思想是让多处理机同时执行同样的任务用以屏蔽瞬时和永久的硬件错误。有两种具体的实现方法：。冗余处理机的造价昂贵，效益很低。实际应用日渐减少。基于数据库的集群系统都是用多个独立的数据库服务器来实现一个逻辑数据库，在任意瞬间，每台处理器运行的都是不同的任务。这种系统可以屏蔽单个或多个服务器的损坏，但是因为没有处理的冗余度，每次恢复的时间比较长，它们需要把被损坏的服务进程在不同的服务器上从新建立起来。ICX让多个独立的数据库服务器作同样的处理。发现处理器问题时的切换不需要重建进程的状态，所以故障屏蔽是极快的。

 

◆       通讯链路级的冗余：冗余的通讯链路可以屏蔽瞬时和永久的通讯链路级的错误。基于数据库引擎的集群系统有两种结构：共享磁盘和独立磁盘。RAC, MSCS 和 MySQL CS可以认为是共享磁盘的集群系统。UDB和ASE 是独立磁盘的集群系统。共享磁盘集群系统对网络系统的要求很高，所以通讯的冗余度最小。独立磁盘集群系统可以把磁盘系统独立管理，通讯冗余度较高。 ICX的通讯链路级的冗余度最高，因为它使用的是多个独立的数据库服务器和独立的磁盘系统。 ICX也可以用于共享磁盘系统。 但是冗余度会相应降低。

 

◆       软件级的冗余：由于现代操作系统和数据库引擎的高度并发性，由竞争条件、死锁、以及时间相关引发的错误占据了非正常停机服务的绝大多数原因。采用多个冗余的运行数据库进程能屏蔽瞬时和永久的软件错误。基于数据库引擎的集群系统都用多个处理器来实现一个逻辑数据库，它们只能提供部分软件冗余，因为每一瞬间每个处理器执行的都是不同的任务。只有ICX可以提供最大程度的软件级冗余。

 

◆      数据冗余：有两类冗余数据集。

 

被动更新数据集：所有目前的数据复制技术(同步或异步)，例如磁盘镜像（EMC的TimeFinder系列）、数据库文件复制（如DoubleTake, Veritas and Legato）以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。通常，为了实现复制功能，需要消耗掉主服务器5%（异步）到30%（同步）的处理能力。被动更新的数据一般只用于灾难恢复.被动更新数据集还有两个致命的问题：一旦主处理机故障造成数据损坏，被动更新的数据集也会被破坏。另外，和主动更新系统相比，被动更新系统对数据网络的带宽要求更高。这是因为它缺少交易的信息，很多数据复制是盲目的。

 

主动更新数据集：这种数据集需要一台（或多台）独立的备份数据库服务器来管理，由于这种数据集及时可用，它可以有多种用途，例如报表生成，数据挖掘，灾难恢复甚至低质量负载均衡。 同样地，这里也有同步和异步两种技术。

 

◆      异步主动复制数据集：这种技术是先把事务处理交给主服务器来完成，然后这些事务处理再被串行地交给备份服务器以执行同样的操作来保证数据的一致性。这种技术生成的数据集和主数据集有一个时间差，所以仅适用于灾难恢复、数据挖掘、报表统计以及有限的在线应用。所有的商用数据库都支持异步主动复制技术。这种办法的难度在于复制队列的管理上，这个队列是用来屏蔽主服务器和备份服务器之间的速度差异的。因为主服务器可以尽可能地利用所有软硬件的并发性来处理并发的事务，而备份服务器只能串行地复制，在高负荷事务处理的情况下，复制队列经常可能溢出。因为没有任何办法来控制事务处理请求的速度，在高负荷事务处理的情况下，复制队列只能经常性地重建。因为所有现代数据库系统都支持热备份和LOG SHIPPING。通过精心策划，应该可以实现不关闭主服务器而重建队列。ICX也支持异步主动复制. ICX的复制队列的重建是通过ICX的自动数据同步软件来完成的，所以不需要人工操作。

 

◆      同步主动复制数据集：这种技术要求所有的并发事务处理在所有的数据库服务器上同时完成。一个直接的好处就是没有了队列的管理问题，同时也可以通过负载均衡实现更高的性能和更高的可用性。这种技术也有两种完全不同的实现方法：完全串行化和动态串行化。完全串行化的事务处理来自于主数据库的事务处理引擎，RAC, UDB, MSCS (SQL Server 2005) 和 ASE是用完全串行化并结合两阶段提交协议来实现的，这种设计的目标就是为了获得一份可用于快速灾难恢复的数据集。这种系统有两个关键的问题。第一，两阶段提交协议是一种“ALL OR NOTHING”的协议。仔细研究两阶段提交协议后就能发现，为了获取这备份数据集，事务处理的可用性会降低一半。第二，完全串行化的做法又引进了主-从数据库服务器速度不匹配的问题。强制同步造成整个系统的速度被降低到完全串行化的水平。相反，ICX-UDS采用了动态串行复制引擎。这设计可以充分利用多个独立数据库的处理能力。ICX避免了使用两阶段提交协议，因此一个事务处理只有在集群中的所有服务器全都同时崩溃的情况下才会回滚。

 

为了防灾，必须使用远程网络。 所以我们在这里讨论远程数据复制的办法。这里大概有四种办法。

 

◆       动态远程异步复制：这种办法是指主服务器通过远程网串行地把交易复制到备份服务器上。由于主-副之间的速度不匹配，队列管理的问题就很突出。 由于远程网的速度一般都比较慢，队列溢出的概率大大增加。所有的集群系统都支持这种复制办法，只是队列管理的办法不同而已。DM，FM和RAID都不能支持这种办法。RAID只能在局域网内工作。

 

◆      动态远程同步复制.：这种办法是指主服务器通过远程网并行地把交易复制备份服务器上。只有ICX 具有这种能力。

 

◆      静态远程异步复制.：这种办法是指通过远程网把数据串行地复制（不通过数据库服务器）到异地。DM和FM支持这种复制办法。因为串行处理和队列管理的关系，这对于处理量大的系统不适用。但是这种复制办法对应用是透明的，所有集群系统都可采用.

 

◆     静态远程同步复制.：这种办法也是指通过远程网把数据串行地复制（不通过数据库服务器）到异地。不同的是，这里没有队列管理。取代队列管理的是发送端的一个新的协议：每次发送都要等接受端确认复制成功。否则回滚。DM和FM都支持这种复制办法。这种办法只能在短距离范围内工作， 大约5 英里光纤的样子。如果超出这个距离范围的话，显然事务处理回滚的概率就会很高。但是这种复制办法对应用是透明的，所有集群系统都可采用。

 

 

3）提高数据库安全和数据集可扩展的技术

 

 在提高数据库安全性和数据集可扩性这两方面，可以创新的空间是很小的。数据库最常见的安全办法是口令保护，要么是分布式的，要么是集中式的。在数据库前面增加防火墙会增加额外的延迟，因此，尽管许多安全侵犯事件是来自于公司内部，但是数据库防火墙还是很少被采用。如果数据库集群技术是基于中间件技术实现的，就有可能在不增加额外延迟的情况下 ，在数据经过的路径上实现防火墙功能。ICX完全实现了这种思想。

 

数据库数据集的可扩性只能通过将数据分布到多个独立的物理服务器上来实现。为了弥补可用性的损失，ICX能被用来提高整个逻辑数据库或者部分重要服务器的处理速度，可用性和安全性。

 

四、数据库集群管理

 

共享磁盘的集群系统，比如RAC, MSCS, 它们的管理比较方便，其中RAC的服务更多。但是，由于它们都要求应用程序对集群不透明，而且配置，修改也比较麻烦，所以我们给它打0.75分。UDB, ASE, MySQL CS 用的都是非共享磁盘，所以管理更麻烦，因此它们只得了0.5分。

 

和其他系统相比，ICX 的集群配置和管理来得很简单。但是，由于每台数据库服务器都有自己的一些系统相关的特有数据，比如进程号,记录行号,时间戳,等等，在对数据库引擎和数据进行底层修复的时候需要用到这些数据。所以这些任务需要直接到每台数据库处理器上去作，比较麻烦。为此，ICX也只得0.75分.

 

相比较下，RAID, DM和 FM 都很简单，对集群全是透明的，因此它们都得满分.

 

五、应用透明度

 

这里RAID, DM 和 FM 也都得满分，因为它们所应用程序是完全透明的。

 

因为在错误回复和分区方面对应用程序不透明，因此基于数据库引擎的RAC, MSCS, UDB, ASE和 MySQL CS)在这方面都只得了 0.75分。

 

ICX 用的是完全独立的多台数据库处理器。因为每台服务器都有和自己系统相关的信息，如系统标识、进程号、记录行号和锁标识等，如果在业务逻辑里使用这些信息就会出现问题，因为每台都有自己不同的标识号。基于数据库引擎的集群技术一般通过一个集群代理来屏蔽这些不同的信息。ICX没有预设数据库引擎，用户需要在这方面做个案评估。

 

既然使用系统信息将某一应用绑定到了特定的服务器上，这种做法使得自动的错误回复变得几乎不可能进行。所以说，一般而言，在工程上，这样的做法是很不合理的，绝大多数应用程序是不会存在这样的问题的。

 

即使真的有应用程序在业务逻辑里使用了系统信息，那还是有两种情况：

a)      可以从客户端程序里检索到系统信息的使用，但是这些系统信息在数据库表格里不是作为索引关键字使用的。这种应用仍然可以使用ICX的集群技术。

b)      另外的就是不能使用ICX集群技术了，除非去除使用系统有关的信息。

 

正是因为考虑到了应用程序可能使用了底层的系统信息，导致对集群的不透明性，因此ICX透明性方面才得了0.75分。

 

六、ICX数据库集群中间件以及它的应用

 

ICX的全称是ICX-UDS DB Scaler。它是专门为能同时取得数据库高处理速度，高可用性和高安全性而设计的。由于它不受象其它数据库厂商那样的基于数据库引擎的集群技术的限制，ICX作为一种中间件，可以支持任意一种数据库。

 

ICX的关键之处是它采用了类似通常的代理服务器的方法。这种方法把ICX放置在关键的网络路径上，这样ICX就能监听到所有进出数据库系统的流量。因此，它就能够以非常小的代价来提供非常关键的服务。这种方法有许多先天的优点，当然这些优点只能在解决了许多重要的技术难点以后才能体现出来。

 

ICX典型的部署是同时驱动多个（几乎）一样的数据库服务器（和数据集）。

 

图 3 带自动负载均衡和复制功能的最典型的ICX部署

 

 

图 3 显示了ICX的一个最典型的部署，同时驱动两个数据库服务器的数据库集群。下面是一些前提条件：

 

◆     所有服务器运行同一版本的数据库系统。

 

◆       所有的服务器具有完全一样的数据集，登陆信息，权限信息等。

 

◆       ICX网关要接管原来赋予给主数据库的IP地址和端口号，所有的数据库服务器将重新获得新的IP地址和端口号

 

当前的ICX版本ICX-UDS Scaler 3.0可以最多同时挂接16个数据库（理论上可以挂更多，但是从工程实际来说，挂接16个数据库已经足够了）。

 

在这种结构里，ICX网关将自动过滤出无状态（不影响直接数据修改）的查询访问，并将它们负载均衡到所有服务器上。在这里，网关就象一个在线的“编译器”，它将所有对数据库的更新操作（和带状态的查询操作）发送到所有数据库上执行，而将无状态的查询操作只发送到其中某一数据库服务器上。这样，客户在数据库处理速度，可用性和安全性（如果设置了防火墙功能的话）等方面同时得到提高。

 

只要无状态查询能被简单地过滤出来，这种配置适合于大多数一般的应用。

 

对于那些统计报表和数据挖掘类的应用，用户可以通过将数据操作分成复制和只读两种类型去取得更快的处理速度。图 4示意了这样一种配置。

  

 

 图 4. ICX 网关和负载均衡器配置示意图

 

需要注意的是：这种配置需要额外的ODBC/JDBC连接，对应用程序的只读查询需要重新定向。

 

如果用户能在应用程序的源代码稍作改动，就可以取的更高的处理速度。使用图3和图4同样的配置，和ICX内建的控制机制，除了自动过滤只读操作来进行负载均衡之外，用户还能指定更多的只读操作来负载均衡。

 

灾难预防只要增加一台或者几台远程服务器就能做到了。

 

ICX 网关的容错可以通过一台或多台备份网关来达到。在同一网端上， ICX网关有自动IP地址接管的功能。 不同网端的ICX网端容错可以用DNS服务器来控制.

 

加载一个非同步的数据库可以造出一个不影响主服务机群的近似于实时的数据源。

 

ICX管理员最复杂的任务大概就是数据集的再同步了（resynchronization）。这牵涉到使用ICX的 Power Resync 工具。一旦定义好后， 管理员只需要经常察看保证没有意外就可以了。

 

七、数据库集群系统的比较

 

 

这里，我们将解释每一项评分的理由，图5是基于各种技术的数据库集群技术的综合评分比较。

 

从表中可见，MySQL CS之所以少了0.5分是因为它缺少数据自动分区的工具。

 

DM，FM和TLM会给系统的处理速度带来负面的影响，所以得的是负分。 

 

基于数据库引擎的集群系统不能高效地处理负载均衡，同时它们的软硬件冗余度也低，所以它们的得分就相应地比较低。相对来说，独立磁盘的集群系统冗余较高，所以它们的得分排名第二。

 

最后一行代表数据分割（DP/Data Partition）后又有了可用性的补偿。

 

处理速度

◆      磁盘技术.：所有集群系统都能很好地应用磁盘技术，因此它们得了满分。但是由于DM，FM会对磁盘系统带来传输速度的负面影响，因此它们得负分。

◆      数据分割.：所有基于数据库引擎的集群系统得了满分，唯有 MySQL CS 得0.75，是因为它缺少了自动数据分割的工具。ICX能使用所有的分区机制，因此也得了满分。其它的得零分，因为它们对这技术没有任何支持。

◆      SMP.：ICX和所有基于数据库引擎的集群系统得满分，其他零分。

◆       负载均衡.：只有 ICX得满分，其他集群系统只得0.25，因为它们使用了备份的数据集，因此只能支持有限的负载均衡。

 

数据可用性

◆       处理器冗余： 只有ICX 得满分，其他集群系统只有部分支持，因此得0.5。

◆       软件冗余：只有ICX 得满分，其他集群系统只有部分支持，因此得0.5。

◆      通讯链路冗余.：共享磁盘的集群系统得分最少，只有0.5分； 独立磁盘的集群系统得0.75；ICX得分满分，是因为它充分利用了多个独立的服务器以及它们各自的独立磁盘的冗余性。

◆      数据冗余：

u      主动异步复制.：除了磁盘和文件镜像外，所有其它都得满分。

u      主动同步复制.：只有 ICX 得满分。

u      被动异步复制：所有集群系统都得满分。

u      被动同步更新：所有集群系统都得满分。

u      通过广域网的复制技术：

◆       远程主动异步复制： 所有的集群系统都支持这种复制技术，只不过对队列的管理能力有所不同。DM，FM和RAID的得分全是0分。RAID在所有的远程复制类别里的得分全是0。

◆       远程主动同步复制：只有ICX得了满分，其它的系统得0分。

◆       远程被动异步复制：DM 和 FM支持这种类型的复制，因为DM和FM对集群是透明的，是在集群系统的下一层工作的，这样，如果有需要的话，所有的集群系统都可以利用它们提供的功能。因此，所有的集群系统也得了满分。

◆      远程被动同步复制：DM和FM支持这种类型的复制，因为这种复制方式只在距离很近的时候才能使用（使用双模光纤，半径五英里），因此这种技术得0.5分。同样地，因为DM和FM对集群是透明的, 所有的集群系统都可以利用它们提供的功能, 如果部署的话，所有的集群系统都得到同样的分数。

 

安全性

◆       口令： 所有集群系统都得满分。

◆      数据库防火墙：只有ICX得满分。

 

数据集的可扩性

◆       数据分区：. ICX和所有基于数据库引擎的集群系统得满分，其他零分。

◆       数据分区的可用性： 只有ICX得满分。

 

集群管理

 

所有共享磁盘的集群系统得了0.75分，因为此种系统中的每一单独的服务器需要特殊处理，但是和独立磁盘的集群系统比较，就容易管理多了（虽然进行初始化和修改配置的时候也不那么容易）。独立磁盘的集群系统象 UDB, ASE和MySQL CS得分稍低点，得了0.5分，那是因为它们的手工操作增加了。ICX的得分在易管理性（初始配置和将来的修改）方面和独立磁盘集群系统的得分相当，但是在对底层数据管理复杂性方面的得分却增加了。那些磁盘工具，即DM，FM和RAID，由于它们对集群是透明的，因为得了满分。

 

应用透明度

 

所有的集群系统都只得了0.75，是因为它们对应用程序都有些特殊的要求，以便应用程序能使用这些集群功能。但是DM，FM和RAID得了满分，那是因为它们对应用程序是完全透明的。

 

总得分

 

在假定每项讨论的技术类别都同等重要的情况下，最后一行显示了某一集群系统或技术的总得分情况。

 

需要提示的是，这些得分并不是绝对的衡量标准，它们只提供了在本文讨论的技术范围内的参考价值。每个应用程序都会有自己的设计意图，因此这里讨论的有些技术类别对于某个应用程序而言就显得不那么重要了。但是，可以这样说，对于今天绝大多数的应用来讲，所有方面都是重要的。因此，我们给每一项的满分全是1分。

 

图5 显示了最后的得分情况。本评分表格也可以在你系统规划的时候使用：你可以去掉不重要的行或者你给不同的行赋予不同的权重，这样你就能得到符合你的选择并且带有不同权重的最后得分。

 

	RAC	MSCS	UDB	ASE	MySQL CS	ICX	DM	FM	RAID
数据库性能
磁盘技术	1	1	1	1	1	1	(0.25)	(0.25)	1
分区技术	1	1	1	1	0.5	1	0	0	0
对称多处理机	1	1	1	1	1	1	0	0	0
负载均衡	0.25	0.25	0.25	0.25	0.25	1	0	0	0
数据库可用性
处理机冗余	0.5	0.5	0.5	0.5	0.5	1	0	0	0
通讯链路冗余	0.5	0.5	0.75	0.75	0.75	1	0	0	0
软件冗余	0.5	0.5	0.5	0.5	0.5	1	0	0	0
数据冗余度
主动异步.	1	1	1	1	1	1	0	0	0
主动同步.	0	0	0	0	0	1	0	0	0
被动异步.	1	1	1	1	1	1	1	1	1
被动同步.	1	1	1	1	1	1	1	1	1
远程主动异步.	1	1	1	1	1	1	0	0	0
远程主动同步.	0	0	0	0	0	1	0	0	0
远程被动异步.	1	1	1	1	1	1	1	1	0
远程被动同步.	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0
安全性
Password	1	1	1	1	1	1	0	0	0
Data Firewall	0	0	0	0	0	1	0	0	0
数据集可扩性
数据分区	1	1	1	1	1	1	0	0	0
数据分区的可用性	0	0	0	0	0	1	0	0	0
集群管理	0.75	0.75	0.5	0.5	0.5	0.75	1	1	1
应用程序透明度	0.75	0.75	0.75	0.75	0.75	0.75	1	1	1
总得分	13.8	13.8	13.8	13.8	13.25	20	5.25	5.25	5

 

图5. 数据库集群系统和技术的评价

 

 

 

八、结论

 

ICX得分最高是由于它独特的技术优势造成的。基于中间件的数据库集群技术（美国专利：#6,421,688）具有许多先天的优点，这些优点是使用任何别的方法很难做到的。

 

这种复制中间件位于关键的网络路径上，监听所有进出数据库系统的流量，它能方便地提供防火墙和其它安全服务，保护物理的数据库服务器。

 

这种中间件复制技术通过多个服务器的并发处理很容易地隐藏了处理的延迟。除此之外，这种配置提供了硬件、软件和通讯链路充分的冗余，因此提供了最佳的系统可用性。

 

中间件事务复制引擎只复制那些对于完成客户事务处理而言必须的SQL语句。相比较而言，文件和磁盘复制方法就涉及到移动大量的数据，因为它们不清楚事务处理的边界。这使得远程交易复制通过低带宽，低延迟的网络成为可能。

 

ICX-UDS事务处理复制引擎的另外一个显著特点是：在无需停止集群服务的情况下自动重新同步数据集。这使得集群修复、数据库重新组织、重新索引、范式更新、硬件和通讯链路更新，集群中机器的增减等在不停止集群服务的情况下成为可能。

 

很显然，一旦我们突破了并行同步交易复制的技术障碍，用户就能通过由多个数据库服务器构成的集群来获得高性能，高可用性和高安全性。

 

使用ICX-UDS，每一个事务处理实时地在多个服务器上处理。此系统可以极大地简化企业数据库的备份过程，包括灾难预防和恢复，同时自动地提供了高可用性。通过将只读查询自动分离，负载均衡，达到了高性能。通过将只读查询分离到专门的负载均衡服务上，或者在应用程序里嵌入ICX控制语句，这样就能获得远高于目前SMP技术能达到的交易处理速度。

 

ICX的最大优点是它同时解决了数据库集群技术面临的四方面的挑战。此技术为获得具有高可扩性的高性能数据库提供了一条切实可行的途径，同时能灵活地适应未来的技术变化。