引言
分布式数据库系统（DDBS）概述
结合了数据库系统（database system）和计算机网络（computer network）技术
达到为对于数据的集中定义和集中管理的目的
带来了数据独立性（data independence）
分布式数据库系统中数据库系统技术和计算机网络技术两者是否矛盾？两者各自强调什么？
数据库系统强调提供集中的、对于数据可控制的存取
计算机网络技术强调反对集中的工作模式
将两者结合的重要思想：
数据库技术最重要的目标是集成而不是集中
集成和集中是两个不同概念，必要时会为了集成而放弃集中
分布式数据处理
本书中关于分布式处理的定义：
使用的分布式计算系统（distributed computing system）的定义，要求它具备一定数量的自主式处理单元（不一定同构），这些单元通过计算机网络互连，并且协同处理它们各自分配到的任务。
- 这里的"处理单元"是指能够执行自己程序的计算装置
根据什么分布？
处理逻辑分布
功能分布
- 计算机系统的不同功能可以分派到不同的硬件或软件部件上
数据分布
- 应用所使用的数据可以分派到若干处理站点上
控制分布
- 不同任务的控制执行也可以分布，而不是由一个计算机系统完成。从分布式数据库系统的观点看，所有这些方式都是必要和重要的
为什么需要分布？
使用一种分而治之的办法应对今天所面临的大规模数据管理问题
把复杂的问题分割成更小的部分并把它们分配到不同的软件群加以解决
这些软件群工作在不同的计算机上，它们形成一个系统，运行在多个处理单元上，有效工作，完成一件共同的任务
什么是分布式数据库系统？
分布式数据库定义：
- 一群分布在计算机网络上、逻辑上互相关联的数据库
数据发送的不同选择
数据发送的不同选择：
发送方式 delivery mode
频率 frequence
通信方法 communication methods
发送方式：
内拉（pull-only）
由客户端的发起请求，从服务器端拉取数据
特点
- 新数据到达或已有数据的更新不会通知客户
外推（push-only）
- 由服务器发起，将数据推送给客户端
混合（hybrid）
把客户端的内拉和服务器端的外推结合起来
实现：
连续查询
起初由客户端发起内拉
而后服务器端将更新的数据外推给客户端
数据发送规律的频率有三种典型的度量
有周期（periodic）
服务器端按照一定的时间间隔将数据推送给客户端
外推、内拉都能定义为周期性的方式
有条件（conditional）
数据按照定义的条件发送，而不是重复的发送
例子：
- 仅当变化时才发送股票价格就是一个典型的有条件外推
凭经验（ad-hoc）或不规则（irregular）
- 凭经验的发送是不规则的，且在大部分情况下是在基于内拉式的系统里执行
通信方法
指服务器和客户端的对应关系，可以分为：
单播（unicast）
- 客户和服务器之间的通信是一对一的：服务器按照某种频率，采用特定的发送方式，仅把数据发送给一个客户
一对多（one-to-many）
在一对多的情况下，如同它的名称所说的那样，服务器向许多客户发出数据
- 请注意，我们这里没有指定任何协议。一对多的通信可以使用多播或者广播协议
DDBS的承诺
DDBS的四个基础问题
分布及复制数据的透明管理
分布式事务提供可靠的数据存取
改进的性能
更为容易的系统扩展
分布及复制数据的透明管理
透明的含义
将系统的高层语义和底层的实现相分离。
向用户"隐藏"了系统实现的细节
透明在这里可以理解为隐藏实现细节，以下各种名词+透明，核心意思就是向用户隐藏对应的名词实现细节
为了让分布式系统能够处理分布、分片、复制的数据查询需要应对几种不同类型透明
- 数据独立性
指用户应用不会受到数据的定义的变化影响
数据定义的两个维度
逻辑结构 通常称为模式定义（schema definition）
物理结构 通常称为物理数据描述（physical data description）
所以为了保证数据定义的透明，就要保证数据的独立性，按照数据定义的维度保证对应两者的独立性
逻辑数据独立性（logical data independence）
- 是说用户应用不受数据库的逻辑结构（例如模式）变化的影响。
物理数据独立性（physical data independence）
- 向用户应用隐蔽了存储结构的细节。当编写用户应用时，不会涉及物理存储结构的细节
- 网络透明（network transparency）或分布透明（distribution transparency）
用户应当免于关心网络的细节，甚至可能不必关心网络的存在，从DBMS的角度来说，分布透明要求用户不必指出数据在哪里存放
分布透明除了指网络，还有另外两种透明：
位置透明（location transparency）是指这样的事实：
- 用来执行任务的命令既和数据的位置无关，也和由哪个系统完成无关
命名透明（naming transparency）是指：
- 对于数据库里的每个对象都提供一个唯一的名字。如果没有命名透明，用户需要把位置名称（或一个标识符）放入对象名称内
- 复制透明
复制
- 这里指分布式系统中数据的复制，即副本的概念
数据复制透明
- 即是否向用户隐藏副本的存在，而不是副本的位置，副本位置属于网络透明范畴
- 分片透明
分片的两种方式：
水平分片（horizontal fragmentation）
- 按照行拆分
垂直分片（vertical fragmentation）
- 按照列拆分
怎么理解分片透明
将数据分片后，对于用户端的查询是基于原先完整关系上的查询，而在DDBS中需要转换这种查询，将最初关系查询转换成基于分片后的查询
分布式事务提供的可靠性
事务（transaction）是一个一致和可靠计算的基本单元，由作为原子单元执行的一系列数据库操作组成。
事务的核心就是保证数据的一致性
即使是在多个事务并发执行（有时称为并发透明（concurrency transparency））的情况下，在发生故障的情况下也可以把数据库从一个一致的状态转变到另一个一致的状态（也称为故障原子性（failure atomicity））
提供完全事务支持的DBMS即使是而临系统故障，只要事务是正确的，即遵守为数据库所声明的完整性规则，也可以保证用户并发事务的执行不会违反数据库的一致性
改进的性能
分布式数据库性能的改进来源于两点：
本地化（localization）
这就带来了两个潜在的好处：
由于每个站点仅仅处理数据库的一小部分，对CPU和I/O的服务竞争不会有集中式数据库那样激烈。
本地化减少了通常由广域网带来的远程访问的延时（例如，在基于卫星的系统中，最小的双向消息传播的时间大约为1秒）。
大多数分布式DBMS按照从数据本地化中获得最大利益的思路来构造。
- 减少竞争和减少通信额外开销的完全好处只有通过数据的正确划分和数据库的分布才能取得。
查询之间的和查询内的并行化
查询之间的并行化
- 来自于同时执行多个查询的能力
查询内的并行
- 是通过把单个查询分解成若干个子查询，让每个子查询在不同的站点上执行，访问分布式数据库的不同部分。
更为容易的系统扩展
分布式环境更为容易适应不断增长的数据规模。主要的系统变更很少发生，通过增加处理和存储的能力即可做到系统扩展。显然，不可能在能力上做到线性增长，这是由于分布产生的额外开销的缘故。但是，获得能力上显著的提高还是完全可以的。
分布带来的复杂性
分布式环境下复杂性主要受到了三方面的影响：
数据可以在分布的环境里复制。
分布式数据可以设计成部分或全部的数据库复制在计算机网络的每个站点上。网络的每个站点包含一个数据库并不重要，重要的问题是数据库驻留在不止一个站点上。
复制数据项的出发点是可靠性和性能的考虑，因此分布式数据库系统要负责：
选择一个副本来响应搜索
保证数据项的每个副本都会得到有效的更新。
故障恢复
- 如果正在更新时某些站点出现故障（例如，硬件或软件的功能出现问题），或者是通信故障（从而使得某些站点失去联系）。在这种情况下，系统必须确保在故障恢复时将更新的效果反映到出现故障的站点或当时无法联系的站点上。
分布式环境中的事务同步
- 因为每个站点不可能随时知道其他站点上正在进行的操作，这就使得多站点上的事务同步比集中式系统要困难得多
设 计 问 题
分布式数据库设计
即如何将数据库放置到分散的站点上。
对于数据的放置存在两种不同的选择：
划分（partitioned）（或无重复（non-replicated））
- 在划分的方案下，数据被划分成不同片段，分别存放在不同的节点上，每个节点上存放数据均不同
重复（replicated）
- 不同节点可以存放相同数据
分布式目录管理
和数据放置问题相似，目录可以集中一个节点，可以分布在几个节点
分布式查询处理
这里涉及两个算法：
对查询进行分析的算法
将查询转换为数据操作的算法
这里的主要问题是当给出了代价的定义之后，如何确定在网络上执行每个查询的策略：
分布式并发控制
并发控制不仅要考虑单个数据库的完整性，而且还要考虑数据库多个副本的一致性。需要每个数据项的多个副本的值趋于一致的条件称为相互一致性（mutual consistency）。
这一问题的解决方案太多太多，总体上讲存在两大类通用的方法
悲观（pessimistic）方法
- 在执行用户请求开始之前首先同步这些请求。
乐观（optimistic）方法
首先执行用户请求，然后再检查是否违反了数据库的一致性。
有两个基本元语可供这两种方法所使用。
第一个基本元语是加锁（locking），它建立在对所访问的数据的相互排斥的基础之上。
第二个元语是加时间戳（timestamping），它按照时间戳的顺序执行事务。
分布式死锁管理
如果同步机制使用的是加锁的方法,访问同一组资源（即数据）的用户之间的竞争会导致死锁。
分布式数据库的可靠性
我们必须提供一些机制来保证数据库一致性，以及故障恢复。
一致性
- 对分布式数据库而言，当发生故障导致不同的站点或者是停止运行，或者是不可访问时，正常运行的站点上的数据库仍然保持在一致和最新的状态
故障恢复
当计算机系统或网络从故障中恢复时，DDBMS应当能够恢复，并且必须将故障站点的数据库带入到最新的状态。
- 在出现网络划分的情况时，这可能非常困难。因为站点被划分成两个或更多的小组，在这些小组之间无法通信。分布式可靠性协议是第12章的主题。
复制
如果分布式数据库是（部分或全部）复制的，则必须执行保证副本一致性的协议，即同一个数据项的拷贝要具有相同的值。
副本一致性协议的两种方式
即时（eager）的，即在事务完成之前强迫执行一致性协议；
惰性（lazy）的，即事务只更新一个拷贝（称为主拷贝（master），而在事务完成之后再把更新传播给其他拷贝。第13章将讨论复制协议。
问题之间的相互关系
自然，这些问题不是互相孤立的。每个问题受到其他问题的影响，直至影响到解决这些问题的可行的方法，这正是本节所要讨论的内容。
分布式DBMS体系架构
本节为分布式数据库DBMS给出三个参考体系架构
客户/服务器系统
P2P分布式DBMS
多数据库系统。
ANSI/SPARC体系架构
图中有三种数据视图：
外部视图（external view），即终端用户例如程序员所见到的视图；
内部视图（internal view），即系统或机器所见的视图；
概念视图（conceptual view），即企业所见的视图。
这一体系架构的最底层是内部视图
- 它处理数据的物理定义和组织。数据的位置以及不同的存储设备，为了获得并操纵数据所使用的机制等问题是这一层必须要考虑的。
另一个极端是
- 外部视图，主要与用户如何看待数据库有关。个别用户的视图代表的是该用户所存取的那部分数据，以及用户看到的数据之间的关系。多个用户可以共享同一个视图，这些用户的视图构成了一个外部模式。
集中式DBMS的通用体系架构
DBMS是一个可由多个进程(事务(transaction))组成的程序，而这些进程又运行它们自己的数据库程序。
DBMS要和另外两个部件交互
通信子系统
通信子系统支持DBMS和其他子系统交互，实现和应用之间的联络。
- 例如，终端监视器需要和DBMS联络以便运行交互式事务。
操作系统。
- 操作系统提供了 DBMS和计算机资源(处理器、内存、磁盘驱动器等等)之间的接口。
集中式DBMS的功能层
图中的箭头指出了数据和控制流的方向。自顶向下来看，这些层分别是界面、控制、编译、执行、数据访问以及一致性管理。
界面层(interface layer)
- 管理和应用交互的界面。
控制层（control layer）
通过在查询中加入语义完整性谓词和授权谓词完成对查询的控制。
而这种语义完整性的限制和授权是由说明性语言所定义的，这会在第5章进行讨论。
这一层的输出是用高级语言加以丰富的查询。
查询处理层（query processing）（或编译（compilation））
把查询映射成优化后的低层操作的序列。
这一层与性能有关，它把查询分解成代数操作的树结构并试图寻找操作的“最优”顺序，它的结果保存在访问计划里。
这一层的输出是底层代码（代数操作）表示的查询。
执行层（execution layer）
指挥访问计划的执行，包括事务管理（提交，重做）以及代数操作的同步。
它通过调用数据访问层的检索和更新请求来解释关系代数。
数据访问层（data access layer）
管理实现文件和索引的数据结构。
它也管理缓冲区，对最经常访问的数据进行快速缓存。
对于这一层的精心使用可以把对磁盘数据的读写降到最低。
一致层（consistency layer）
对并发控制进行管理，同时记录更新请求的日志。
这一层支持事务、系统、介质的故障恢复。
分布式DBMS体系架构的模型
DBMS的不同实现方式
构造分布式DBMS有多种方法，该图从以下几个方面对系统进行刻画：
本地系统的自治性（Autonomy）；
系统的分布（Distribution）；
系统的异构（Heterogeneity）。
自治性
这里所说的自治性（autonomy）是指对控制的分配，而不是数据的分配，它告诉我们在多大程度上每个单独的DBMS能够独立地运行。
自治性可以这样来加以说明【Du and Elmagarmid，1989】：
设计自治：
- 每个单独的DBMS可以自由地选择数据模型和事务处理技术
通信自治：
- 每个单独的DBMS可以自由地决定什么样的信息可以提供给其他DBMS
执行自治：
- 能够用它自己的方式执行提交事务
让我们来看看如何使用这些特征来对DBMS进行分类：
紧密集成(tight integration)，
在多个数据管理程序中，有一个管理程序负责对每一个用户的请求处理进行控制，即使这个请求需要用到多个数据管理程序所提供的服务的情况下也是如此。
这种情况下，数据管理程序通常不会作为一个独立的DBMS来运行。
半自治系统(semiautonomous)
它由独立运行的DBMS组成，但是它们必须要加入一个联盟才能实现本地数据的共享
每一个这样的DBMS要决定它拥有的数据的哪个部分可供其他DBMS使用。
它们还不是全自治的系统，因为对它们必须进行修改才能实现彼此间的信息交换.
全孤立(total isolation)系统
在这样的系统里，每个DBMS都是独立存在的，它们既不知道其他DBMS的存在，也不知道如何和它们通信
此时,涉及多个数据库的用户事务处理特别困雄，因为系统内不存在对于个别DBMS执行所施加的全局控制.
分布
前面讨论的自治指的是对于控制的分配(或分散)，而下面要讨论的分布则指的是如何处理数据的间題。
对于DBMS,已经有了几种不同的分布方式.可把它们抽象为
客户/服务器(client/server)分布
把数据管理的任务集中在服务器端
而客户端则集中于提供包括用户界面在内的应用环境
通信的任务则由客户和服务器共同承担
P2P（peer-to-peer)分布
在P2P系统(peer-tbpeer systems)里不存在客户端和服务器端机器这样的差别
每台机器具备完整的DBMS功能，同时可以和其他机器通信以完成査询和事务的执行
异构性
在本书中和这个问题较为密切的是
数据模型
- 用不同的建模工具表示数据就会产生异构，这是由各个数据模型先天的表达能力和局限性所造成的。
查询语言
查询语言方面的异构不仅与不同的模型采用完全不同的数据访问的方式有关（从关系系统的一次一个集合，到某些面向对象系统的一次一个纪录），而且还涉及语言的不同，即便是使用同一个模型也仍然会出现这个问题。
虽然SQL现在是标准的关系查询语言，但是对它的实现不尽相同，而每个商家的语言则会带着略有不同的风格（有时甚至不同的语义，从而产生不同的结果）。
事务管理的协议。
