第1章引言

最新推荐文章于 2022-12-30 01:41:08 发布

susanhonly

最新推荐文章于 2022-12-30 01:41:08 发布

阅读量226

点赞数

本文链接：https://blog.csdn.net/qq_35781301/article/details/107439852

版权

分布式数据库系统（DDBS）技术是看起来在一个圆上对立的两种数据处理方法，即数据库系统（database system）和计算机网络（computer network）技术的结合。

1.1 分布式数据处理

分布式计算系统（distributed computing system）的定义要求它具备一定数量的自主式处理单员（不一定同构），这些单元通过计算机网络互联，并且协同处理它们各自分配到的任务。

什么需要分布？其中之一可以是处理逻辑（processing logic）。另一种可能的分补方式是按照功能（function）。第三种可能的分布则是根据数据（data），应用所使用的数据可以分派到若干处理站点上。最后，控制（control）也能够分布。

1.2 什么是分布式数据库系统

在多处理器上运行的数据库系统称为并行数据库系统（parallel database system）。

1.3 数据发送的不同选择

我们将数据发送的不同选择从发送方式（delivery mode）、频率（frequency）以及通信方法（communication methods）三个正交的维度加以刻画。

不同的发送方式有：内拉（pull-only）、外推（push-only）以及混合（hybrid）。

　　所谓内拉方式是指从服务器到客户端的数据传输是由客户端的请求发起的，当客户的请求到达服务器时，服务器进行响应并查找所需要的信息。这种基于内拉式发送的主要特点是新数据的到达或者对已有数据的更新是在服务器端，它不会通知客户，除非客户明确地向服务器发出探测。另外，服务器不段地被中断以便处理客户端的请求。再说，客户能从服务器得到的信息仅仅限于客户所请求的范围，现代DBMS仅仅提供有限的内拉式发送。

　　在外推的发送方式下，服务器到客户端的数据传输是由服务器在没有任何客户请求的情况下，由服务器初始发动的。外推式的主要难点在于决定哪些是共同关系的数据，以及何时将这些数据发送到客户端——可用的选择是周期性发送、不规则发送或按条件发送。因此，服务i去推送的实效完全取决于服务器对客户需要的预测。在外推的发送方式下，服务器的信息发布对象是一组不固定的进行收听的客户（随机广播），或者是有选择的属于数据接收范畴的固定客户（多播）。

　　混合方式把客户端的内拉和服务器端的外推结合起来。连续查询的方法代表了其中的一种，数据从服务器向客户的传输最初由客户的内拉（发出查询）发起，而此后向客户的更新信息的传输则由服务器的外推发起。

　　对数据发送规律的频率由三种典型的度量，即有周期（periodic）、有条件（conditional）、以及凭经验（ad-hoc）或不规则（irregular）。

1.4.1.2 网络透明

　　在集中式数据库系统里，唯一需要共享的资源就是数据（即存储系统）。在分布式环境下，存在第二种资源需要类似的管理：网络。显然，用户应当免于关心网络的细节，甚至可能不必关系网络的存在。这样，运行在集中式数据库上的应用和运行在分布式数据库上的应用之间就不会存在任何差别。这样类型的透明称为网络透明（network transparency）或分布透明（distribution transparency），用户可用从服务或者数据的角度来考虑网络透明。对于前者来说，是希望用统一的方式对服务进行访问。而从DBMS的角度来说，分布透明要求用户不必指出数据在哪里存放。

　　有时还会涉及另两种分布透明：位置透明和命名透明。位置透明（location transparency）是指这样的事实：用来执行任务的命令既和数据的位置无关，也和由哪个系统完成无关。命名透明（naming transparency）是指对于数据库里的每个对象都提供一个唯一的名字。如果没有命名透明，用户需要把位置名称（或一个标识符）放入对象名称内。

1.4.1.3 复制透明

　　通常，人们希望分布式数据能够在网络内的机器上复制。这种复制有助于提高性能，使不同而又冲突的用户需求可以更容易协调。例如，有一个用户共同访问的数据可以保存到这个用户的本地机器上，以及具有同样需求的零一给用户的机器上，这就增加了引用的本地性。当然，这是一种简单化的描述。实际上，是否复制的决定以及究竟复制多少拷贝的问题在相当程度上取绝与用户应用。

　　复制透明要成为DBMS的标准特征。复制透明仅仅谈及副本的存在，而不是它们的实际位置。同时，副本在网络上的分布透明属于网络透明的范畴。

1.4.1.4 分片透明

　　分片透明，即把数据库关系分割成更小的片段，并把这些片段处理成分开的数据库对象（即另一个关系）。这样做还的原因还是基于对性能、可用性以及可靠性上的考虑。进一步讲，分片可以减少复制的负面效果。每一个复制不再是全部的关系，而仅仅是它的一个子集。于是，减少了所需的空间，减少了需要管理的数据项。

　　有两种通用的分片选择。一种叫做水平分片（horizontal fragmentation），即把一个关系划分成为一组子关系，每个子关系仅仅含有原来关系的元组（行）的一个子集。第二种选择叫作垂直分片（vertical fragmentation），它把每个子关系定义成原来关系的属性（列）的一个子集。

　　当数据库对象被分片时，必须处理如何将原来一个完整关系上的查询分解到子关系上执行的问题。换句话说，要找到一种基于片段，而不是基于最初关系的查询处理策略，即便查询是针对最初关系的。典型的情况下，这需要一种把全局查询（global query）变成片段查询（fragment query）的转换。

1.4.1.5 谁应当提供透明

　　为了给普通用户提供容易、有效的DBMS服务，人们希望获得包括所有讨论过的各种形式的完全透明。无论如何，透明的程度需要在容易使用和提供高级服务所要付出的代价和困难之间做出折中。

　　我们尚未讨论谁来提供这些服务的问题，但可以用三个有区别的层来提供透明，它们通常被看作是提供服务的相互排斥的方法，尽管把它们看成是互补的更为合适。

　　可以把提供透明存取数据的责任留给存取层。透明的特性可以建立在用户语言里，由语言把请求的服务翻译成需要的操作。换句话说，编译器或者解释器接手这一任务，而不向编译器或者解释器的实现程序提供透明服务。

　　能够提供透明的第二层是操作系统层。现代操作系统为系统用户提供了某种程度的透明。例如，操作系统的设备驱动程序负责指挥每个外部设备完成所请求的操作。典型的计算机用户，乃至应用程序员不会编写设备驱动程序去与个别的外部设备打交道，这一操作对用户而言是透明的。

　　在操作系统层提供的透明显然可以扩展到分布式环境，在这样的环境里，网络资源的管理由分布式操作系统执行，或者是由支持分布式DBMS的中间件来承担。这样的方法由两个潜在的问题。第一是没有可用的商品化分布式操作系统能投提供合理透明的网络管理。第二是有些应用部希望被挡在分布细节之外，因为处于性能优化的原因它们需要访问这些细节。

　　能够提供透明的第三层是DBMS。由操作系统向DBMS设计人员提供的、支持数据库功能的透明一般维持在最小的程度，仅仅限于执行某些任务的非常基本的部分。DBMS有责任完成从操作系统向高层的用户界面的翻译，这正是今天最常用的方法。但是，把提供全透明的任务留给DBMS也有各种问题。这与操作系统和分布式DBMS之间的交互有关。

　　下图是透明的层次：

1.4.2 分布式事务提供的可靠性

　　分布式DBMS试图提高可靠性，因为它们具有重复的构成从而消除了单站点故障。单站点故障，或者是使得一个或多个站点不可达的共同连结故障还不足以使整个系统垮掉。在分布式数据库的情景下，这意味着某些数据可能无法使用，但通过恰当的办法仍然允许用户访问部分的分布式数据库。这个“恰当的办法”来自于分布式事务和应用协议的支持。

　　事务（transaction）是一个一致和可靠计算的基本单元，由作为原子单元执行的一系列数据库操作组成。即使是在多个事务并发执行（有时称为并发透明（concurrency transparency））的情况下，在发生故障的情况下也可以把数据库从一个一致的状态转变到另一个一致的状态（也称为故障原子性（failure atomicity））。所以，提供完全事务支持的DBMS即使是面临系统故障，只要事务是正确的，即遵守为数据库所声明的完整性规则，也可以保证用户并发事务的执行不会违反数据库的一致性。

　　下面给出一个基于前面介绍过的工程公司的例子。假设有个应用要为所有雇员的薪水提高10%，我们希望把执行这一任务的查询（或者程序代码）封装在事务的边界之内。例如，如果程序执行了一半时系统发生了故障，我们希望在恢复时DBMS能够决定上次失败的位置并且继续完成任务（或者是从头再来）。这就是故障原子性的概念。另一种情况下，当原来的更新正在进行时，如果其他用户发出计算平均薪水的查询，其结果必然是错误的。所以，要求系统能够使这些程序的并发执行同步。为了把查询封装在事务的边界之内，只需声明事务的开始（begin）和结束（end）就可以了：

Begin_transaction SALARY_UPDATE
begin
    EXEC SQL UPDATE PAY
                    SET SAL=SAL*1.1
end

　　分布式事务要在它们需要访问本地数据的若干站点上执行。例如上面的事务要执行在Boston、Waterloo、Paris和San Francisco，因为数据分布在这些地点。有了分布式事务的有力支持，用户应用能够访问数据库的单一逻辑映像，并且无论系统出现什么情况，它们的请求都能够得到正确执行。所谓的正确是指用户应用没必要关心如何和个别的数据库协调，也没必要担心在他们的事务执行时发生的站点或者通信方面的故障。这里展现了分布式事务和透明之间的联系，因为两者都涉及分布式命名以及目录管理等问题。

1.4.3 改进的性能

　　分布式数据库性能的改进来源于两点。首先，分布式DBMS划分了概念数据库，使得数据存储在靠近使用它的位置（称之为本地化（localization））。这就带来了两个潜在的好处：

　　（1）由于每个站点仅仅处理数据库的一小部分，对CPU和I/O的服务竞争不会由集中式数据库那样激烈。

　　（2）本地化减少了通常由广域网带来的远程访问的延时（例如，在基于卫星的系统中，最小的双向消息传播的时间大约为1秒）。

　　大多数分布式DBMS按照从数据本地化中获得最大利益的思路来构造。减少竞争和减少通信额外开销的完全好处只有通过数据的正确划分和数据库的分布才能取得。

　　这一观点与数据必须存放在远程位置，只能通过远程通信才能访问的分布式计算的额外开销有关。这里的依据是：在这样的环境下，把数据管理的功能分布道数据的所在地，而不用移动大量的数据。这在后来成为关于竞争的研究题目。有人认为，广泛存在的高速大容量网络使数据和管理的分布不再有意义，把数据存储在一个中心站点并通过告诉网访问（下载）可能会简单得多。这种观点听起来有道理，但它忘记了分布式数据库的本制。首先，在今天的大部分应用下数据都是分布的，唯一需要讨论的是在何处以及如何处理它们。第二，也是更为重要的，这种观点没有在带宽（计算机连结的能力）和延时（多长时间完成数据传输）之间进行区别。延时是分布式环境所固有的，在网络上我们受到了数据发送速度的物理限制。如前所述，卫星连结需要大约0.5秒才能完成在两个地面站之间数据传输。这是由地球到卫星的举例所决定的，我们无法做任何事情来改进这一性能。对于某些应用而言，这可能会形成不可接受的延迟。

　　第二个观点是分布式系统固有的并行可以用于查询之间的和查询内的并行化。查询之间的并行化来源自于同时执行多个查询的能力，而查询内的并行是通过把单个查询分解成若干个子查询，让每个子查询在不同的站点上执行，访问分布式数据库的不同部分。

　　如果用户对分布式数据库的访问仅仅由询问（即只读的访问），查询之间的和查询内的并行就可以尽量多地复制数据。但是，由于大多数数据库并不是只读的，这种读和更新的混合操作需要实现并发控制和事务提交的协议。