分布式数据库教程（2）--原创
三、传统的数据库于分布式数据库的区别
传统的数据库应用程序经常采用客户机/服务器结构（即C/S结构，如图2），这种结构在技术上已经很成熟了并且应用也很广泛，但这种结构的应用系统有其不足之处。比如当客户数量很多，数据量又都很大的情况下，服务器的负载就会很重，而且重复性工作很多，因为很多客户发出的查询可能完全相同，而查询结果无法共享，即使两个客户发出的请求完全相同也要在服务器上执行两次查询；在客户端存储了具有商业价值的查询算法；数据库服务器负担过重导致效率低下等。
而当在服务器和客户机之间再加一个服务器，专门用于存储查询算法和临时查询结果，则问题就得到了很好的解决：一方面不同的客户可以共用临时的查询结果而无须再访问数据库服务器，减轻了服务器的负担；同时在客户端也看不到作为商业机密的查询算法。这也就是分布式系统的工作原理。
分布式系统的出现源于传统的C/S结构的若干弊病，如效率低，安全性差等，结合到数据库方面来说，全球的DNS（域名解析系统 Domain Name System）系统是一个很典型的例子，试想如果把全世界所有的域名都集中到一台服务器中来进行管理，那服务器肯定会因负载过重而无法正常工作，整个互联网也就瘫痪了。（可以画一个寻址DNS服务器的图）
与传统式数据库中避免数据冗余不同，数据冗余在分布式系统中被看作是所需要的特性，其原因在于：
首先，如果在需要的节点复制数据，则可以提高局部的应用性。
其次，当某节点发生故障时，可以操作其它节点上的复制数据，因此这可以增加系统的有效性。
但在分布式系统中对最佳冗余度的评价是很复杂的。
四、分布式数据库技术设计
数据库设计的原则
从全局应用的角度出发，将这些数据库自下而上构成分布式数据库系统，实现全局数据的完整性和一致性，各场地仍然存放本场地的数据，通过网络对共享池进行操作，对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。该分布式数据库系统可以在对当前机构影响最小的情况下进行扩充，增加新的场地时只需增加一个节点就可以了，同时也使得各处理机之间的相互干扰降到最低。
数据存储
在分布式数据库中，数据存储通过以下三种途径实现：
①复制：系统维护关系的几个完全相同的副本，这些副本存储在不同的结点上。
②分片：关系被划分为几个片段，各个片段存储在不同的结点上。
③复制+分片：关系被划分为几个片段，系统为每个片段维护几个副本。
因为各数据库之间存在一定的数据冗余，又存在着差异，我们使用了复制+分片的方式进行数据存储。
数据分片
在分布式数据库系统中，将关系分片，有利于按用户需求组织数据的分布，目前的分片方式有水平分片、垂直分片、导出分片、混合分片等四种。我们可以根据不同的数据关系采用了不同的分片方式。
数据同步
数据同步方式则根据系统需求使用事务复制（transaction replication）和合并复制(merge replication)两种，由于场地只存放本场地的数据，数据管理和分析功能是由网络共享池的数据库服务器来实现的，各场地只需将更新的数据保存到共享池的数据库即可，我们使用事务复制进行业务数据的同步，把场地的数据库作为出版者和分发者，共享池的数据库作为订阅者，对各场地的数据建立快照代理，并在分发数据库中记录同步状态的信息。每一个使用事务复制的场地数据库均有自己的日志读取代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直接推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布代理运行在分发者上并与订阅者相连。
事务复制可以支持两种类型的对象复制：表和存储过程。在出版者中定义数据库中的部分或全部的数据，选择多个存储过程作为复制。当场地的数据发生更新时，日志读取代理将即时的把更新信息推到共享池的数据库中。基于存储过程的复制使应用具有更好的性能，可以大大减少网络的通讯量。事务性日志使用事务日志来监视文章中的数据改变。
合并复制作为一种从出版者向订购者分发数据方法允许出版者和订购者对出版数据进行修改，而不管订购者与出版者是相互连接或是断开，然后当所有（或部分）节点相连时便合并发生在各个节点的变化。在合并复制中，每个节点都独立完成属于自己的任务，不像事务复制和快照复制那样订购者与出版者之间要相互连接，完全不必要连接到其他节点，也不必使用MS DTC来实现两阶段提交就可以在多个节点进行修改，只是在某一时刻才将该节点与其他节点相连（此时的其他节点并不一定指所有其他节点）。
然后将所发生的数据变化复制到这些相连接节点的数据库中。
以下即为该系统的设计框图：
图 4
■分布式事务处理 利用分布式技术实现事务处理和查询
分布式数据库系统中数据的分布导致事务具有了分布性。一个全局事务的执行被划分为在许多场地上子事务的执行。
分布式事务要能够在多个服务器上执行，我们使用MS DTC作为事务管理器来协调各个服务器对事务的处理操作，为了减少网络故障对分布式事务处理的影响，避免分布式事务造成不同服务器间数据的不一致，X/Open XA规范将分布式事务的处理过程规定为两个阶段，即准备阶段和提交阶段，就是常说的两阶段提交。
在进行分布式事务处理时，我们首先在服务器端用Transact SQL脚本程序BEGIN DISTRIBUTED TRANSACTION语句启动一个分布式事务，将该服务器作为分布式事务管理服务器，然后脚本程序对连接服务器执行分布式查询或远程服务器上的存储过程，分布式事务管理服务器会自动调用MS DTC，使远程服务器参加分布式事务处理。当脚本程序执行COMMIT TRANSACTION、COMMIT WORK、ROLLBACK TRANSACTION或ROLLBACK WORK语句时，分布式事务管理服务器将再次调用MS DTC，用它来管理两阶段提交进程，使连接服务器和远程服务器提交或回滚事务。例如在保险业务系统中，如果总公司数据库管理系统发现该客户是交叉投保，则需将该保单插入拒保记录表中，同时在对应的营业分支机构的数据库中将该保单的状态设为无效。我们在营业分支机构的数据库（DBServer1）中建立存储过程update_policy更新保单状态，在总公司数据库服务器（DBServer）上执行以下脚本程序，启动一个分布式事务insert_reject：
USE business
GO
BEGIN DISTRIBUTED TRANSACTION
INSERT reject
VALUES(policy_id, insurance_no,business_date,customer_id,customer_name…)
EXECUTE DBServer1.business.dbo.update_policy
COMMIT TRANSACTION
GO
系统执行insert_reject事务向DBServer中的reject表插入一条记录，同时更新对应的分支机构数据库中的保单表status字段，该事务使系统数据的完整性得到了保证。
■ 分布式查询
分布式数据库系统中数据的分布导致查询也具有了分布性，分布式查询可能针对异类的OLE DB 或 ODBC 数据源。SQL Server 支持分布式查询，即包括来自两个或更多服务器数据的查询，支持服务器间的检索、更新和游标，并使用 Microsoft Distributed Transaction Coordinator (MS DTC) 保证节点间事务语义，维护服务器间的安全。
在系统设计的过程中，为了减少网络通讯量，我们根据应用的功能已将数据关系进行分片存放在各数据库中，因此大部分的应用是面向局部数据库的操作，但全局性的查询仍需要多个数据库的数据支持。在业务人员的管理模块中，由于各分支机构对其业务人员进行直接管理，且管理制度都有差异，我们将业务人员信息存放在分支机构的数据库中，通过联合分布式查询对公司所属的所有业务员进行登记；在客户管理模块中，我们根据来源将客户信息分别存放在业务数据库服务器的传统客户表和Web数据库服务器的网络客户表中，通过联合分布式查询才能对公司所属的所有业务员和客户进行登记，下面以年度的业务员查询为例介绍联合分布式查询的方法：
SELECT emp.emp_name, emp.emp_id ， emp.emp_gender…FROM DBServer1.business.dbo.employee AS emp
WHERE date between '01/01/2000' and '12/31/2000'
UNION
SELECT emp.emp_name, emp.emp_id ， emp.emp_gender…
FROM DBServer2.business.dbo.employee AS emp
WHERE date between '01/01/2000' and '12/31/2000'