分布式数据库管理系统 - 快速指南

上一页
下一页

分布式数据库管理系统 - 概念

任何组织的正常运作都需要一个维护良好的数据库。在最近的过去，数据库通常是集中式的。然而，随着全球化的发展，组织往往在全球范围内多元化。他们可以选择将数据分布在本地服务器上，而不是集中式数据库。因此，出现了分布式数据库的概念。

本章概述了数据库和数据库管理系统 (DBMS)。数据库是相关数据的有序集合。DBMS 是一个用于处理数据库的软件包。在我们的名为“学习 DBMS”的教程中提供了关于 DBMS 的详细研究。在本章中，我们将回顾主要概念，以便轻松学习 DDBMS。涵盖的三个主题是数据库模式、数据库类型和数据库操作。

数据库和数据库管理系统

数据库是为特定目的构建的相关数据的有序集合。数据库可以组织为多个表的集合，其中每个表代表一个现实世界中的元素或实体。每个表都有几个不同的字段，这些字段代表实体的特征。

例如，公司数据库可能包含项目、员工、部门、产品和财务记录的表。Employee 表中的字段可能是姓名、公司 ID、加入日期等。

数据库管理系统是一组程序，用于创建和维护数据库。DBMS 作为软件包提供，可以促进数据库中数据的定义、构建、操作和共享。数据库的定义包括数据库结构的描述。数据库的构建涉及将数据实际存储在任何存储介质中。操作是指从数据库中检索信息、更新数据库和生成报告。数据共享使不同的用户或程序可以访问数据。

DBMS 应用领域的示例

  • 自动柜员机
  • 火车预订系统
  • 员工管理系统
  • 学生信息系统

DBMS 软件包示例

  • MySQL
  • Oracle
  • SQL Server
  • dBASE
  • FoxPro
  • PostgreSQL 等。

数据库模式

数据库模式是数据库的描述，在数据库设计期间指定，并且很少更改。它定义了数据的组织、它们之间的关系以及与它们相关的约束。

数据库通常通过三级模式架构或ANSI/SPARC 架构来表示。该架构的目标是将用户应用程序与物理数据库分离。三个级别是 -

  • 内部级具有内部模式 - 它描述了数据库的物理结构、内部存储的细节以及数据库的访问路径。

  • 概念级具有概念模式 - 它描述了整个数据库的结构，同时隐藏了数据物理存储的细节。这说明了实体、具有其数据类型和约束的属性、用户操作和关系。

  • 外部级或视图级具有外部模式或视图 - 它描述了与特定用户或用户组相关的数据库的一部分，同时隐藏了数据库的其余部分。

DBMS 的类型

DBMS 有四种类型。

层次 DBMS

在层次 DBMS 中，数据库中数据之间的关系建立起来，以便一个数据元素作为另一个数据元素的从属存在。数据元素具有父子关系，并使用“树”数据结构建模。这些非常快速和简单。

Hierarchical DBMS

网络 DBMS

网络 DBMS 中，数据库中数据之间的关系是网络形式的多对多类型。由于存在大量多对多关系，因此结构通常很复杂。网络 DBMS 使用“图”数据结构建模。

Network DBMS

关系 DBMS

在关系数据库中，数据库以关系的形式表示。每个关系都模拟一个实体，并表示为一个值表。在关系或表中，一行称为元组，表示单个记录。一列称为字段或属性，表示实体的特征属性。RDBMS 是最流行的数据库管理系统。

例如 - 学生关系 -

Relational DBMS

面向对象 DBMS

面向对象 DBMS 来源于面向对象编程范式的模型。它们有助于表示存储在数据库中的一致数据以及在执行程序中找到的瞬态数据。它们使用称为对象的小型可重用元素。每个对象都包含一个数据部分和一组对数据进行操作的操作。对象及其属性通过指针访问，而不是存储在关系表模型中。

例如 - 简化的银行账户面向对象数据库 -

Object-oriented DBMS

分布式数据库管理系统

分布式数据库是一组相互连接的数据库，分布在计算机网络或互联网上。分布式数据库管理系统 (DDBMS) 管理分布式数据库，并提供机制以使数据库对用户透明。在这些系统中，数据有意分布在多个节点之间，以便能够优化组织的所有计算资源。

DBMS 操作

数据库的四个基本操作是创建、检索、更新和删除。

  • 创建数据库结构并使用数据填充它 - 创建数据库关系涉及指定要存储的数据的数据结构、数据类型和约束。

    示例 - 创建学生表的 SQL 命令 -

CREATE TABLE STUDENT ( 
   ROLL INTEGER PRIMARY KEY, 
   NAME VARCHAR2(25), 
   YEAR INTEGER, 
   STREAM VARCHAR2(10) 
);

  • 定义数据格式后，实际数据将根据格式存储在某些存储介质中。

    示例 SQL 命令将单个元组插入学生表中 -

INSERT INTO STUDENT ( ROLL, NAME, YEAR, STREAM) 
VALUES ( 1, 'ANKIT JHA', 1, 'COMPUTER SCIENCE');

  • 检索数据库中的信息 - 检索信息通常涉及选择表的子集或在执行某些计算后显示表中的数据。它是通过查询表来完成的。

    示例 - 要检索计算机科学专业的所有学生的姓名，需要执行以下 SQL 查询 -

SELECT NAME FROM STUDENT 
WHERE STREAM = 'COMPUTER SCIENCE';

  • 更新存储的信息和修改数据库结构 - 更新表涉及将现有表行中的旧值更改为新值。

    示例 - SQL 命令将流从电子更改为电子与通信 -

UPDATE STUDENT 
SET STREAM = 'ELECTRONICS AND COMMUNICATIONS' 
WHERE STREAM = 'ELECTRONICS';

  • 修改数据库意味着更改表的结构。但是，表的修改受许多限制。

    示例 - 要向学生表添加新字段或列（例如地址），我们使用以下 SQL 命令 -

ALTER TABLE STUDENT 
ADD ( ADDRESS VARCHAR2(50) );

  • 删除存储的信息或删除整个表 - 删除特定信息涉及从满足某些条件的表中删除选定的行。

    示例 - 要删除所有当前为 4 年级并在毕业时离开的学生，我们使用 SQL 命令 -

DELETE FROM STUDENT 
WHERE YEAR = 4;

  • 或者，可以从数据库中删除整个表。

    示例 - 要完全删除学生表，使用的 SQL 命令为 -

DROP TABLE STUDENT;

分布式数据库管理系统 - 分布式数据库

本章介绍了 DDBMS 的概念。在分布式数据库中，存在许多可能分布在全球各地的数据库。分布式 DBMS 以一种对用户而言似乎是一个单一数据库的方式管理分布式数据库。在本章的后面部分，我们将继续研究导致分布式数据库的因素、其优点和缺点。

分布式数据库是多个相互连接的数据库的集合，这些数据库在物理上分布在各个位置，并通过计算机网络进行通信。

特征

  • 集合中的数据库在逻辑上相互关联。通常，它们表示单个逻辑数据库。

  • 数据在物理上存储在多个站点上。每个站点中的数据可以由独立于其他站点的 DBMS 管理。

  • 站点中的处理器通过网络连接。它们没有任何多处理器配置。

  • 分布式数据库不是松散连接的文件系统。

  • 分布式数据库包含事务处理，但它不是事务处理系统的同义词。

分布式数据库管理系统

分布式数据库管理系统 (DDBMS) 是一个集中式软件系统，它以所有数据都存储在单个位置的方式管理分布式数据库。

特征

  • 它用于创建、检索、更新和删除分布式数据库。

  • 它定期同步数据库，并提供访问机制，通过这些机制，分布对用户变得透明。

  • 它确保在任何站点修改的数据都得到普遍更新。

  • 它用于大量数据由众多用户同时处理和访问的应用领域。

  • 它专为异构数据库平台而设计。

  • 它维护数据库的机密性和数据完整性。

鼓励使用分布式数据库的因素

以下因素鼓励转向分布式数据库管理系统（DDBMS）−

  • 组织单元的分布式特性 − 当今大多数组织都细分为多个单元，这些单元在全球范围内物理分布。每个单元都需要自己的一套本地数据。因此，组织的整体数据库变得分布式。

  • 数据共享的需求 − 多个组织单元通常需要相互通信并共享其数据和资源。这需要以同步方式使用的公共数据库或复制数据库。

  • 对OLTP和OLAP的支持 − 联机事务处理（OLTP）和联机分析处理（OLAP）基于可能具有公共数据的不同系统。分布式数据库系统通过提供同步数据来辅助这两种处理。

  • 数据库恢复 − DDBMS中使用的一种常见技术是在不同站点之间复制数据。如果任何站点的数据库损坏，数据复制会自动帮助进行数据恢复。用户可以在重建损坏的站点时访问其他站点的数据库。因此，数据库故障对用户来说几乎可以忽略不计。

  • 支持多种应用程序软件 − 大多数组织使用各种应用程序软件，每种软件都有其特定的数据库支持。DDBMS为在不同平台之间使用相同数据提供统一的功能。

分布式数据库的优点

以下是分布式数据库优于集中式数据库的优点。

模块化开发 − 如果系统需要扩展到新的位置或新的单元，在集中式数据库系统中，此操作需要大量工作并中断现有功能。但是，在分布式数据库中，这项工作只需在新的站点添加新的计算机和本地数据，最后将它们连接到分布式系统即可，而不会中断当前的功能。

更可靠 − 在数据库故障的情况下，集中式数据库的整个系统都会停止运行。但是，在分布式系统中，当一个组件发生故障时，系统的功能可能会继续运行，但性能可能会降低。因此，DDBMS更可靠。

更好的响应速度 − 如果以有效的方式分发数据，则用户请求可以从本地数据本身得到满足，从而提供更快的响应速度。另一方面，在集中式系统中，所有查询都必须通过中央计算机进行处理，这会增加响应时间。

更低的通信成本 − 在分布式数据库系统中，如果数据位于其最常使用的位置，则可以最大程度地减少数据操作的通信成本。这在集中式系统中是不可行的。

分布式数据库的缺点

以下是与分布式数据库相关的一些缺点。

  • 需要复杂且昂贵的软件 − DDBMS需要复杂且通常昂贵的软件来提供跨多个站点的透明性和协调数据。

  • 处理开销 − 即使是简单的操作也可能需要大量的通信和额外的计算才能确保跨站点的数据一致性。

  • 数据完整性 − 需要在多个站点更新数据会带来数据完整性问题。

  • 数据分布不当带来的开销 − 查询的响应速度很大程度上取决于数据分布的合理性。数据分布不当通常会导致用户请求的响应速度非常慢。

分布式数据库管理系统 - 数据库环境

在本教程的这一部分中，我们将研究有助于设计分布式数据库环境的不同方面。本章首先介绍分布式数据库的类型。分布式数据库可以分为同构和异构数据库，并进一步细分。本章的下一部分讨论了分布式体系结构，即客户端-服务器、对等和多数据库管理系统。最后，介绍了复制和碎片等不同的设计方案。

分布式数据库的类型

分布式数据库可以广泛地分为同构和异构分布式数据库环境，每种环境都有进一步的细分，如下所示。

Distributed Database Environments

同构分布式数据库

在同构分布式数据库中，所有站点都使用相同的DBMS和操作系统。其属性为−

  • 站点使用非常相似的软件。

  • 站点使用相同的DBMS或来自同一供应商的DBMS。

  • 每个站点都了解所有其他站点，并与其他站点合作处理用户请求。

  • 数据库通过单个接口访问，就像它是单个数据库一样。

同构分布式数据库的类型

同构分布式数据库有两种类型−

  • 自治型 − 每个数据库都是独立的，可以独立运行。它们由一个控制应用程序集成，并使用消息传递来共享数据更新。

  • 非自治型 − 数据分布在同构节点上，中央或主DBMS协调跨站点的数据库更新。

异构分布式数据库

在异构分布式数据库中，不同的站点具有不同的操作系统、DBMS产品和数据模型。其属性为−

  • 不同的站点使用不同的模式和软件。

  • 系统可能由各种DBMS组成，例如关系型、网络型、层次型或面向对象型。

  • 由于模式不同，查询处理很复杂。

  • 由于软件不同，事务处理很复杂。

  • 一个站点可能不知道其他站点，因此在处理用户请求方面合作有限。

异构分布式数据库的类型

  • 联邦型 − 异构数据库系统本质上是独立的，并集成在一起，以便它们能够作为一个数据库系统运行。

  • 非联邦型 − 数据库系统采用一个中央协调模块来访问数据库。

分布式数据库管理系统体系结构

DDBMS体系结构通常根据三个参数开发−

  • 分布 − 它说明了数据在不同站点上的物理分布。

  • 自治性 − 它指示数据库系统的控制权分配以及每个组成DBMS能够独立运行的程度。

  • 异构性 − 它指的是数据模型、系统组件和数据库的一致性或差异性。

体系结构模型

一些常见的体系结构模型包括−

  • DDBMS的客户端-服务器体系结构
  • DDBMS的对等体系结构
  • 多数据库管理系统体系结构

DDBMS的客户端-服务器体系结构

这是一种两层体系结构，其中功能分为服务器和客户端。服务器功能主要包括数据管理、查询处理、优化和事务管理。客户端功能主要包括用户界面。但是，它们也具有一些功能，例如一致性检查和事务管理。

两种不同的客户端-服务器体系结构为−

  • 单服务器多客户端
  • 多服务器多客户端（如下图所示）
Server Architecture

DDBMS的对等体系结构

在这些系统中，每个对等节点既充当客户端又充当服务器以提供数据库服务。对等节点与其他对等节点共享其资源并协调其活动。

此体系结构通常具有四个级别的模式−

  • 全局概念模式 − 描述数据的全局逻辑视图。

  • 本地概念模式 − 描述每个站点的逻辑数据组织。

  • 本地内部模式 − 描述每个站点的物理数据组织。

  • 外部模式 − 描述用户对数据的视图。

Peer- to-Peer Architecture

多数据库管理系统体系结构

这是一个由两个或多个自治数据库系统组成的集成数据库系统。

多数据库管理系统可以通过六个级别的模式来表达−

  • 多数据库视图级别 − 描述多个用户视图，这些视图包含集成分布式数据库的子集。

  • 多数据库概念级别 − 描述集成的多数据库，包括全局逻辑多数据库结构定义。

  • 多数据库内部级别 − 描述数据在不同站点和多数据库到本地数据的映射。

  • 本地数据库视图级别 − 描述本地数据的公共视图。

  • 本地数据库概念级别 − 描述每个站点的本地数据组织。

  • 本地数据库内部级别 − 描述每个站点的物理数据组织。

多数据库管理系统有两种设计方案−

  • 带有多数据库概念级别的模型。
  • 没有多数据库概念级别的模型。
Multi-database Conceptual Level

Without Multi-database Conceptual Level

设计方案

DDBMS中表的分布设计方案如下−

  • 非复制且非碎片化
  • 完全复制
  • 部分复制
  • 碎片化
  • 混合

非复制和非碎片化

在此设计方案中，不同的表放置在不同的站点。数据放置的位置应靠近其最常使用的位置。它最适合于查询需要连接放置在不同站点的表中的信息百分比较低的数据库系统。如果采用适当的分布策略，则此设计方案有助于降低数据处理过程中的通信成本。

完全复制

在此设计方案中，每个站点都存储所有数据库表的副本。由于每个站点都有整个数据库的副本，因此查询速度非常快，所需的通信成本可以忽略不计。相反，数据的大量冗余在更新操作期间需要巨大的成本。因此，这适用于需要处理大量查询而数据库更新次数较少的系统。

部分复制

表的副本或表的某些部分存储在不同的站点。表的分布是根据访问频率进行的。这考虑到了这样一个事实，即访问表的频率在不同站点之间存在很大差异。表的副本数量（或部分）取决于访问查询执行的频率以及生成访问查询的站点。

碎片化

在此设计中，一个表被分成两个或多个称为碎片或分区的块，每个碎片可以存储在不同的站点。这考虑到了这样一个事实，即在给定站点很少需要表中存储的所有数据。此外，碎片化提高了并行性和提供了更好的灾难恢复。在这里，系统中每个碎片只有一个副本，即没有冗余数据。

三种碎片化技术为−

  • 垂直碎片化
  • 水平碎片化
  • 混合碎片化

混合分布

这结合了碎片化和部分复制。在这里，表最初以任何形式（水平或垂直）进行碎片化，然后根据访问碎片的频率在不同站点之间部分复制这些碎片。

分布式数据库管理系统 - 设计策略

在上一章中，我们介绍了不同的设计方案。在本章中，我们将研究有助于采用这些设计的策略。这些策略可以广泛地分为复制和碎片化。但是，在大多数情况下，两种策略结合使用。

数据复制

数据复制是在两个或多个站点存储数据库的不同副本的过程。它是分布式数据库的一种流行的容错技术。

数据复制的优点

  • 可靠性 − 如果任何站点发生故障，数据库系统将继续工作，因为在另一个站点（或多个站点）有副本可用。

  • 减少网络负载 − 由于本地数据副本可用，因此查询处理可以在减少网络使用的情况下完成，尤其是在高峰时段。数据更新可以在非高峰时段完成。

  • 更快的响应速度 − 本地数据副本的可用性确保了快速查询处理，从而缩短了响应时间。

  • 更简单的事务 − 事务需要更少的连接位于不同站点的表以及网络间最少的协调。因此，它们的本质变得更简单。

数据复制的缺点

  • 存储需求增加 − 维持数据的多个副本会增加存储成本。所需的存储空间是集中式系统所需存储空间的倍数。

  • 数据更新成本和复杂性增加 − 每次更新数据项时，都需要在不同站点的数据所有副本中反映更新。这需要复杂的同步技术和协议。

  • 不希望的应用程序-数据库耦合 − 如果不使用复杂的更新机制，则消除数据不一致性需要在应用程序级别进行复杂的协调。这会导致不希望的应用程序-数据库耦合。

一些常用的复制技术包括：

  • 快照复制
  • 近实时复制
  • 拉取复制

碎片化

碎片化是将表划分为一组较小表的任务。表的子集称为碎片。碎片化可以分为三种类型：水平、垂直和混合（水平和垂直的组合）。水平碎片化可以进一步分为两种技术：主水平碎片化和派生水平碎片化。

碎片化应以这样一种方式进行，即可以从碎片重建原始表。这是为了能够在需要时从碎片重建原始表。此要求称为“可重构性”。

碎片化的优点

  • 由于数据存储在使用站点附近，因此提高了数据库系统的效率。

  • 由于数据在本地可用，大多数查询都足够使用本地查询优化技术。

  • 由于站点上没有无关数据，因此可以维护数据库系统的安全性和隐私。

碎片化的缺点

  • 当需要来自不同碎片的数据时，访问速度可能会非常慢。

  • 在递归碎片化的情况下，重建工作将需要昂贵的技术。

  • 在不同站点缺乏数据的备份副本可能会导致数据库在某个站点发生故障时失效。

垂直碎片化

在垂直碎片化中，表的字段或列被分组到碎片中。为了保持可重构性，每个碎片都应包含表的primaryKey字段。垂直碎片化可用于强制实施数据隐私。

例如，让我们考虑一个大学数据库，它在名为Student的表中保存所有注册学生的信息，该表具有以下模式。

STUDENT

Regd_No Name Course Address Semester Fees Marks

现在，费用详细信息在会计部门维护。在这种情况下，设计人员将对数据库进行如下碎片化：

CREATE TABLE STD_FEES AS 
   SELECT Regd_No, Fees 
   FROM STUDENT;

水平碎片化

水平碎片化根据一个或多个字段的值对表的元组进行分组。水平碎片化也应符合可重构性规则。每个水平碎片必须具有原始基表的所有列。

例如，在学生模式中，如果需要在计算机科学学院维护所有计算机科学课程学生的详细信息，则设计人员将对数据库进行如下水平碎片化：

CREATE COMP_STD AS 
   SELECT * FROM STUDENT  
   WHERE COURSE = "Computer Science";

混合碎片化

在混合碎片化中，使用水平和垂直碎片化技术的组合。这是最灵活的碎片化技术，因为它生成的碎片包含最少的冗余信息。但是，重建原始表通常是一项昂贵的任务。

混合碎片化可以通过两种替代方式完成：

  • 首先，生成一组水平碎片；然后从一个或多个水平碎片生成垂直碎片。

  • 首先，生成一组垂直碎片；然后从一个或多个垂直碎片生成水平碎片。

DDBMS - 分布式透明性

分布式透明性是分布式数据库的属性，通过该属性，分布的内部细节对用户隐藏。DDBMS 设计人员可以选择对表进行碎片化、复制碎片并将它们存储在不同的站点。但是，由于用户不知道这些细节，因此他们发现使用分布式数据库就像使用任何集中式数据库一样容易。

分布式透明性的三个维度是：

  • 位置透明性
  • 碎片透明性
  • 复制透明性

位置透明性

位置透明性确保用户可以查询任何表或表的任何碎片，就好像它们存储在用户的本地站点一样。表或其碎片存储在分布式数据库系统中的远程站点这一事实，应该完全对最终用户隐藏。远程站点地址和访问机制完全隐藏。

为了合并位置透明性，DDBMS 应该能够访问更新且准确的数据字典和 DDBMS 目录，其中包含数据位置的详细信息。

碎片透明性

碎片透明性使用户能够查询任何表，就好像它没有被碎片化一样。因此，它隐藏了用户正在查询的表实际上是一个碎片或一些碎片的联合这一事实。它还隐藏了碎片位于不同站点的事实。

这有点类似于 SQL 视图的用户，用户可能不知道他们正在使用表的视图而不是表本身。

复制透明性

复制透明性确保数据库的复制对用户隐藏。它使用户能够查询表，就好像该表只存在一个副本一样。

复制透明性与并发透明性和故障透明性相关联。每当用户更新数据项时，更新都会反映在表的全部副本中。但是，此操作不应让用户知道。这是并发透明性。此外，如果某个站点发生故障，用户仍然可以使用复制的副本继续进行查询，而无需了解故障。这是故障透明性。

透明度的组合

在任何分布式数据库系统中，设计人员都应确保在很大程度上维护所有声明的透明性。设计人员可以选择对表进行碎片化、复制并将其存储在不同的站点；所有这些都对最终用户隐藏。但是，完全的分布式透明性是一项艰巨的任务，需要大量的设计工作。

分布式 DBMS - 数据库控制

数据库控制是指执行规定的任务，以便为数据库的真实用户和应用程序提供正确的数据。为了使用户能够获得正确的数据，所有数据都应符合数据库中定义的完整性约束。此外，应将数据屏蔽在未经授权的用户之外，以维护数据库的安全性和隐私。数据库控制是数据库管理员 (DBA) 的主要任务之一。

数据库控制的三个维度是：

  • 身份验证
  • 访问权限
  • 完整性约束

身份验证

在分布式数据库系统中，身份验证是仅允许合法用户访问数据资源的过程。

身份验证可以在两个级别执行：

  • 控制对客户端计算机的访问 − 在此级别，在登录到为数据库服务器提供用户界面的客户端计算机时，会限制用户访问。最常见的方法是用户名/密码组合。但是，对于高安全数据，可以使用更复杂的方法，如生物识别身份验证。

  • 控制对数据库软件的访问 − 在此级别，数据库软件/管理员会向用户分配一些凭据。用户使用这些凭据访问数据库。一种方法是在数据库服务器中创建一个登录帐户。

访问权限

用户的访问权限是指授予用户关于 DBMS 操作的权限，例如创建表、删除表、在表中添加/删除/更新元组或查询表的权限。

在分布式环境中，由于表数量众多，用户数量更多，因此无法将单个访问权限分配给用户。因此，DDBMS 定义了某些角色。角色是数据库系统中具有某些权限的构造。定义了不同的角色后，将为各个用户分配其中一个角色。通常会根据组织的权力和责任等级来定义角色的层次结构。

例如，以下 SQL 语句创建了一个角色“Accountant”，然后将此角色分配给用户“ABC”。

CREATE ROLE ACCOUNTANT; 
GRANT SELECT, INSERT, UPDATE ON EMP_SAL TO ACCOUNTANT; 
GRANT INSERT, UPDATE, DELETE ON TENDER TO ACCOUNTANT; 
GRANT INSERT, SELECT ON EXPENSE TO ACCOUNTANT; 
COMMIT; 
GRANT ACCOUNTANT TO ABC; 
COMMIT;

语义完整性控制

语义完整性控制定义并强制执行数据库系统的完整性约束。

完整性约束如下：

  • 数据类型完整性约束
  • 实体完整性约束
  • 引用完整性约束

数据类型完整性约束

数据类型约束限制了可以应用于具有指定数据类型的字段的值范围和操作类型。

例如，让我们考虑一个名为“HOSTEL”的表，它有三个字段——宿舍号、宿舍名称和容量。宿舍号应以大写字母“H”开头，且不能为 NULL，容量不应超过 150。以下 SQL 命令可用于数据定义：

CREATE TABLE HOSTEL ( 
   H_NO VARCHAR2(5) NOT NULL, 
   H_NAME VARCHAR2(15), 
   CAPACITY INTEGER, 
   CHECK ( H_NO LIKE 'H%'), 
   CHECK ( CAPACITY <= 150) 
);

实体完整性控制

实体完整性控制强制执行规则，以便可以从其他元组唯一地识别每个元组。为此，定义了primaryKey。primaryKey是一组可以唯一标识元组的最小字段。实体完整性约束规定表中不能有两个元组对primaryKey具有相同的值，并且primaryKey的一部分的任何字段都不能具有 NULL 值。

例如，在上表中，可以通过以下 SQL 语句将宿舍号分配为primaryKey（忽略检查）：

CREATE TABLE HOSTEL ( 
   H_NO VARCHAR2(5) PRIMARY KEY, 
   H_NAME VARCHAR2(15), 
   CAPACITY INTEGER 
);

引用完整性约束

引用完整性约束规定了foreignKey的规则。foreignKey是数据表中一个字段，它是相关表的primaryKey。引用完整性约束规定foreignKey字段的值应位于引用表的primaryKey的值中或完全为 NULL。

例如，让我们考虑一个学生表，其中学生可以选择住在宿舍。为了包含这一点，宿舍表的primaryKey应作为foreignKey包含在学生表中。以下 SQL 语句包含了这一点：

CREATE TABLE STUDENT (  
   S_ROLL INTEGER PRIMARY KEY, 
   S_NAME VARCHAR2(25) NOT NULL, 
   S_COURSE VARCHAR2(10), 
   S_HOSTEL VARCHAR2(5) REFERENCES HOSTEL 
);

用于查询优化的关系代数

当放置查询时，它首先会被扫描、解析和验证。然后创建查询的内部表示，例如查询树或查询图。然后为从数据库表中检索结果设计替代执行策略。选择最合适的查询处理执行策略的过程称为查询优化。

DDBMS 中的查询优化问题

在 DDBMS 中，查询优化是一项至关重要的任务。复杂性很高，因为由于以下因素，替代策略的数量可能会呈指数级增长：

  • 存在多个碎片。
  • 碎片或表在各个站点之间的分布。
  • 通信链路的传输速度。
  • 本地处理能力的差异。

因此，在分布式系统中，目标通常是找到一种良好的查询处理执行策略，而不是最佳策略。执行查询的时间是以下时间的总和：

  • 将查询发送到数据库的时间。
  • 执行本地查询碎片的时间。
  • 从不同站点组装数据的时间。
  • 将结果显示给应用程序的时间。

查询处理

查询处理是从放置查询到显示查询结果的一组所有活动。步骤如下所示：

Query Processing

关系代数

关系代数定义了关系数据库模型的基本操作集。一系列的关系代数操作构成一个关系代数表达式。该表达式的结果表示数据库查询的结果。

基本操作包括：

  • 投影
  • 选择
  • 并集
  • 交集
  • 差集
  • 连接

投影

投影操作显示表中字段的子集。这给出了表的垂直分区。

关系代数语法

$$\pi_{<{AttributeList}>}{(<{Table Name}>)}$$

例如，让我们考虑以下学生数据库：

STUDENT
学号 Name Course Semester 性别
2 阿米特·普拉萨德 BCA 1 男
4 瓦尔莎·蒂瓦里 BCA 1 女
5 阿西夫·阿里 MCA 2 男
6 乔·华莱士 MCA 1 男
8 希瓦尼·艾延格 BCA 1 女

如果我们想显示所有学生的姓名和课程，我们将使用以下关系代数表达式：

$$\pi_{姓名,课程}{(STUDENT)}$$

选择

选择操作显示表中满足某些条件的元组的子集。这给出了表的水平分区。

关系代数语法

$$\sigma_{<{Conditions}>}{(<{Table Name}>)}$$

例如，在Student表中，如果我们想显示所有选择MCA课程的学生的详细信息，我们将使用以下关系代数表达式：

$$\sigma_{课程} = {\small "BCA"}^{(STUDENT)}$$

投影和选择操作的组合

对于大多数查询，我们需要投影和选择操作的组合。有两种方法可以编写这些表达式：

  • 使用投影和选择操作的序列。
  • 使用重命名操作生成中间结果。

例如，要显示所有BCA课程的女学生的姓名：

  • 使用投影和选择操作序列的关系代数表达式

$$\pi_{姓名}(\sigma_{性别 = \small "女" AND 课程 = \small "BCA"}{(STUDENT)})$$

  • 使用重命名操作生成中间结果的关系代数表达式

$$FemaleBCAStudent \leftarrow \sigma_{性别 = \small "女" AND 课程 = \small "BCA"} {(STUDENT)}$$

$$Result \leftarrow \pi_{姓名}{(FemaleBCAStudent)}$$

并集

如果P是某个操作的结果，Q是另一个操作的结果，则P和Q的并集（$p \cup Q$）是P或Q或两者中所有元组的集合，不包含重复项。

例如，要显示所有在第1学期或BCA课程中的学生：

$$Sem1Student \leftarrow \sigma_{学期 = 1}{(STUDENT)}$$

$$BCAStudent \leftarrow \sigma_{课程 = \small "BCA"}{(STUDENT)}$$

$$Result \leftarrow Sem1Student \cup BCAStudent$$

交集

如果P是某个操作的结果，Q是另一个操作的结果，则P和Q的交集（$p \cap Q$）是P和Q中所有元组的集合。

例如，给定以下两个模式：

EMPLOYEE

员工ID Name 城市 部门 薪资

PROJECT

项目ID 城市 部门 状态

要显示项目所在的所有城市以及员工居住的所有城市的名称：

$$CityEmp \leftarrow \pi_{城市}{(EMPLOYEE)}$$

$$CityProject \leftarrow \pi_{城市}{(PROJECT)}$$

$$Result \leftarrow CityEmp \cap CityProject$$

差集

如果P是某个操作的结果，Q是另一个操作的结果，则P - Q是P中但不在Q中的所有元组的集合。

例如，列出所有没有正在进行的项目的部门（状态为“正在进行”的项目）：

$$AllDept \leftarrow \pi_{部门}{(EMPLOYEE)}$$

$$ProjectDept \leftarrow \pi_{部门} (\sigma_{状态 = \small "正在进行"}{(PROJECT)})$$

$$Result \leftarrow AllDept - ProjectDept$$

连接

连接操作将两个不同表（查询结果）中相关的元组组合到单个表中。

例如，考虑银行数据库中的两个模式Customer和Branch，如下所示：

CUSTOMER

客户ID 账户号 账户类型 支行ID 开户日期

BRANCH

支行ID 支行名称 联行代码 Address

列出员工详细信息以及支行详细信息：

$$Result \leftarrow CUSTOMER \bowtie_{Customer.BranchID=Branch.BranchID}{BRANCH}$$

将SQL查询转换为关系代数

在优化之前，SQL查询被转换为等效的关系代数表达式。查询首先被分解成更小的查询块。这些块被转换为等效的关系代数表达式。优化包括优化每个块，然后优化整个查询。

示例

让我们考虑以下模式：

EMPLOYEE

员工ID Name 城市 部门 薪资

PROJECT

项目ID 城市 部门 状态

WORKS

员工ID 项目ID 工时

示例1

要显示所有薪资低于平均薪资的员工的详细信息，我们编写SQL查询：

SELECT * FROM EMPLOYEE 
WHERE SALARY < ( SELECT AVERAGE(SALARY) FROM EMPLOYEE ) ;

此查询包含一个嵌套子查询。因此，它可以分解成两个块。

内部块是：

SELECT AVERAGE(SALARY)FROM EMPLOYEE ;

如果此查询的结果是AvgSal，则外部块是：

SELECT * FROM EMPLOYEE WHERE SALARY < AvgSal;

内部块的关系代数表达式：

$$AvgSal \leftarrow \Im_{AVERAGE(Salary)}{EMPLOYEE}$$

外部块的关系代数表达式：

$$\sigma_{Salary <{AvgSal}>}{EMPLOYEE}$$

示例2

要显示员工“Arun Kumar”的所有项目的项目ID和状态，我们编写SQL查询：

SELECT PID, STATUS FROM PROJECT 
WHERE PID = ( SELECT FROM WORKS  WHERE EMPID = ( SELECT EMPID FROM EMPLOYEE 
            WHERE NAME = 'ARUN KUMAR'));

此查询包含两个嵌套子查询。因此，可以将其分解成三个块，如下所示：

SELECT EMPID FROM EMPLOYEE WHERE NAME = 'ARUN KUMAR'; 
SELECT PID FROM WORKS WHERE EMPID = ArunEmpID; 
SELECT PID, STATUS FROM PROJECT WHERE PID = ArunPID;

（此处ArunEmpID和ArunPID是内部查询的结果）

三个块的关系代数表达式：

$$ArunEmpID \leftarrow \pi_{EmpID}(\sigma_{Name = \small "Arun Kumar"} {(EMPLOYEE)})$$

$$ArunPID \leftarrow \pi_{PID}(\sigma_{EmpID = \small "ArunEmpID"} {(WORKS)})$$

$$Result \leftarrow \pi_{PID, Status}(\sigma_{PID = \small "ArunPID"} {(PROJECT)})$$

关系代数运算符的计算

关系代数运算符的计算可以通过多种不同的方式完成，每种替代方案称为**访问路径**。

计算替代方案取决于三个主要因素：

  • 运算符类型
  • 可用内存
  • 磁盘结构

执行关系代数操作的时间是以下时间的总和：

  • 处理元组的时间。
  • 从磁盘到内存获取表元组的时间。

由于处理元组的时间远小于从存储中获取元组的时间，特别是在分布式系统中，因此磁盘访问通常被视为计算关系表达式成本的指标。

选择计算

选择操作的计算取决于选择条件的复杂性和表属性上索引的可用性。

以下是根据索引的不同计算替代方案：

  • **无索引** - 如果表未排序且没有索引，则选择过程涉及扫描表的全部磁盘块。每个块被加载到内存中，并检查块中的每个元组以查看它是否满足选择条件。如果满足条件，则将其显示为输出。这是最昂贵的方法，因为每个元组都被加载到内存中，并且每个元组都被处理。

  • **B+树索引** - 大多数数据库系统都构建在B+树索引之上。如果选择条件基于该B+树索引的关键字段，则使用此索引检索结果。但是，处理具有复杂条件的选择语句可能涉及大量磁盘块访问，在某些情况下甚至需要完全扫描表。

  • **哈希索引** - 如果使用哈希索引，并且其关键字段用于选择条件，则使用哈希索引检索元组就成为一个简单的过程。哈希索引使用哈希函数查找存储与哈希值对应的键值的桶的地址。为了在索引中查找键值，执行哈希函数并找到桶地址。搜索桶中的键值。如果找到匹配项，则从磁盘块中将实际元组提取到内存中。

连接计算

当我们想要连接两个表（例如P和Q）时，必须将P中的每个元组与Q中的每个元组进行比较，以测试是否满足连接条件。如果满足条件，则连接相应的元组，消除重复字段并将它们附加到结果关系中。因此，这是最昂贵的操作。

计算连接的常用方法包括：

嵌套循环方法

这是传统的连接方法。它可以通过以下伪代码来说明（表P和Q，元组tuple_p和tuple_q以及连接属性a）：

For each tuple_p in P 
For each tuple_q in Q
If tuple_p.a = tuple_q.a Then 
   Concatenate tuple_p and tuple_q and append to Result 
End If 
Next tuple_q 
Next tuple-p

排序合并方法

在这种方法中，两个表根据连接属性分别排序，然后合并排序后的表。由于记录数量非常多，无法容纳在内存中，因此采用外部排序技术。一旦单个表排序，将每个排序表的每一页加载到内存中，根据连接属性合并，并将连接的元组写出。

哈希连接方法

此方法包括两个阶段：分区阶段和探测阶段。在分区阶段，表P和Q被分成两组不相交的分区。确定一个通用的哈希函数。此哈希函数用于将元组分配到分区。在探测阶段，将P分区中的元组与Q对应分区中的元组进行比较。如果它们匹配，则将其写出。

集中式系统中的查询优化

一旦推导出关系代数表达式的计算的替代访问路径，就确定最佳访问路径。在本章中，我们将研究集中式系统中的查询优化，而在下一章中，我们将研究分布式系统中的查询优化。

在集中式系统中，查询处理的目标如下：

  • 最小化查询的响应时间（生成结果以响应用户查询所需的时间）。

  • 最大化系统吞吐量（在给定时间内处理的请求数量）。

  • 减少处理所需的内存和存储量。

  • 提高并行性。

查询解析和转换

最初，扫描SQL查询。然后对其进行解析以查找语法错误和数据类型的正确性。如果查询通过此步骤，则将其分解成更小的查询块。然后将每个块转换为等效的关系代数表达式。

查询优化的步骤

查询优化涉及三个步骤，即查询树生成、计划生成和查询计划代码生成。

步骤1 - 查询树生成

查询树是一种树形数据结构，表示关系代数表达式。查询的表表示为叶节点。关系代数运算表示为内部节点。根表示整个查询。

在执行期间，只要操作数表可用，就会执行内部节点。然后用结果表替换该节点。此过程继续对所有内部节点进行，直到执行根节点并用结果表替换它为止。

例如，让我们考虑以下模式：

EMPLOYEE

员工ID 员工姓名 薪资 部门号 入职日期

DEPARTMENT

部门号 部门名称 位置

示例1

让我们将查询视为以下内容。

$$\pi_{EmpID} (\sigma_{EName = \small "ArunKumar"} {(EMPLOYEE)})$$

相应的查询树将是：

Corresponding Query Tree

示例2

让我们考虑另一个涉及连接的查询。

$\pi_{EName, Salary} (\sigma_{DName = \small "Marketing"} {(DEPARTMENT)}) \bowtie_{DNo=DeptNo}{(EMPLOYEE)}$

以下是上述查询的查询树。

Query Tree

步骤2 - 查询计划生成

查询树生成后，会生成一个查询计划。查询计划是扩展的查询树，其中包含查询树中所有操作的访问路径。访问路径指定了树中关系操作应如何执行。例如，选择操作可以具有一个访问路径，该路径提供了有关使用 B+ 树索引进行选择的详细信息。

此外，查询计划还说明了如何将中间表从一个运算符传递到下一个运算符，如何使用临时表以及如何对操作进行流水线处理/组合。

步骤 3 - 代码生成

代码生成是查询优化中的最后一步。它是查询的可执行形式，其形式取决于底层操作系统的类型。一旦生成查询代码，执行管理器就会运行它并生成结果。

查询优化方法

在查询优化的方法中，最常用的是穷举搜索和基于启发式算法。

穷举搜索优化

在这些技术中，对于一个查询，首先会生成所有可能的查询计划，然后选择最佳计划。尽管这些技术提供了最佳解决方案，但由于解决方案空间很大，因此具有指数级的时间和空间复杂度。例如，动态规划技术。

基于启发式的优化

基于启发式的优化使用基于规则的优化方法来优化查询。这些算法具有多项式时间和空间复杂度，低于基于穷举搜索算法的指数复杂度。但是，这些算法不一定产生最佳的查询计划。

一些常见的启发式规则如下：

  • 在连接操作之前执行选择和投影操作。这是通过将选择和投影操作向下移动到查询树来完成的。这减少了可用于连接的元组数量。

  • 首先执行最严格的选择/投影操作，然后再执行其他操作。

  • 避免使用笛卡尔积运算，因为它们会导致非常大的中间表。

分布式系统中的查询优化

本章讨论分布式数据库系统中的查询优化。

分布式查询处理架构

在分布式数据库系统中，处理查询包括全局和本地两个级别的优化。查询在客户端或控制站点进入数据库系统。在这里，用户经过验证，查询在全局级别进行检查、转换和优化。

该架构可以表示为：

Distributed Query Processing Architecture

将全局查询映射到本地查询

将全局查询映射到本地查询的过程可以如下实现：

  • 全局查询中需要的表有片段分布在多个站点上。本地数据库只包含有关本地数据的信息。控制站点使用全局数据字典收集有关分布的信息，并从片段重建全局视图。

  • 如果没有复制，全局优化器将在存储片段的站点上运行本地查询。如果存在复制，全局优化器将根据通信成本、工作负载和服务器速度选择站点。

  • 全局优化器生成一个分布式执行计划，以便在站点之间发生的数据传输量最少。该计划说明了片段的位置、查询步骤需要执行的顺序以及参与传输中间结果的过程。

  • 本地查询由本地数据库服务器优化。最后，对于水平片段，通过联合操作将本地查询结果合并在一起；对于垂直片段，通过连接操作合并本地查询结果。

例如，假设以下 Project 模式根据城市进行水平分片，城市为新德里、加尔各答和海得拉巴。

PROJECT

项目ID 城市 部门 状态

假设有一个查询，用于检索所有状态为“正在进行”的项目的详细信息。

全局查询将是：

$$\sigma_{status} = {\small "ongoing"}^{(PROJECT)}$$

新德里服务器中的查询将是：

$$\sigma_{status} = {\small "ongoing"}^{({NewD}_-{PROJECT})}$$

加尔各答服务器中的查询将是：

$$\sigma_{status} = {\small "ongoing"}^{({Kol}_-{PROJECT})}$$

海得拉巴服务器中的查询将是：

$$\sigma_{status} = {\small "ongoing"}^{({Hyd}_-{PROJECT})}$$

为了获得总体结果，我们需要将这三个查询的结果联合起来，如下所示：

$\sigma_{status} = {\small "ongoing"}^{({NewD}_-{PROJECT})} \cup \sigma_{status} = {\small "ongoing"}^{({kol}_-{PROJECT})} \cup \sigma_{status} = {\small "ongoing"}^{({Hyd}_-{PROJECT})}$

分布式查询优化

分布式查询优化需要评估大量的查询树，每个查询树都生成查询所需的输出结果。这主要是由于存在大量复制和碎片数据。因此，目标是找到一个最优解，而不是最优解。

分布式查询优化的主要问题是：

  • 优化利用分布式系统中的资源。
  • 查询交易。
  • 减少查询的解决方案空间。

优化利用分布式系统中的资源

分布式系统在各个站点上有多个数据库服务器来执行与查询相关的操作。以下是最优资源利用的方法：

操作迁移 - 在操作迁移中，操作在存储数据而不是客户端的站点上运行。然后将结果传输到客户端站点。这适用于操作数在同一站点上可用的操作。例如：选择和投影操作。

数据迁移 - 在数据迁移中，数据片段被传输到数据库服务器，在那里执行操作。这用于操作数分布在不同站点的操作。这也适用于通信成本低且本地处理器比客户端服务器慢得多的系统。

混合迁移 - 这是数据和操作迁移的组合。在这里，数据片段被传输到高速处理器，操作在那里运行。然后将结果发送到客户端站点。

Optimal Utilization Distributed System

查询交易

在分布式数据库系统的查询交易算法中，分布式查询的控制/客户端站点称为买方，本地查询执行的站点称为卖方。买方制定了许多选择卖方和重建全局结果的备选方案。买方的目标是实现最优成本。

该算法从买方将子查询分配给卖方站点开始。最优计划是由卖方提出的本地优化查询计划以及重建最终结果的通信成本组合而成的。一旦制定了全局最优计划，就会执行查询。

减少查询的解决方案空间

最优解通常涉及减少解决方案空间，以便减少查询和数据传输的成本。这可以通过一组启发式规则来实现，就像集中式系统中的启发式方法一样。

以下是一些规则：

  • 尽早执行选择和投影操作。这减少了通过通信网络的数据流。

  • 通过消除与特定站点无关的选择条件来简化水平片段上的操作。

  • 如果连接和联合操作包含位于多个站点的片段，则将碎片数据传输到大部分数据所在的站点，并在那里执行操作。

  • 使用半连接操作来限定要连接的元组。这减少了数据传输量，从而减少了通信成本。

  • 合并分布式查询树中的公共叶子和子树。

DDBMS - 事务处理系统

本章讨论事务处理的各个方面。我们还将研究事务中包含的低级任务、事务状态和事务属性。在最后一部分，我们将回顾调度和调度的可串行化。

事务

事务是一个程序，包括一系列数据库操作，作为数据处理的逻辑单元执行。事务中执行的操作包括一个或多个数据库操作，例如插入、删除、更新或检索数据。它是一个原子过程，要么完全执行完成，要么根本不执行。仅涉及数据检索而不涉及任何数据更新的事务称为只读事务。

每个高级操作都可以细分为多个低级任务或操作。例如，数据更新操作可以分为三个任务：

  • read_item() - 从存储器读取数据项到主存。

  • modify_item() - 更改主存中项目的value。

  • write_item() - 将修改后的value从主存写入存储器。

数据库访问仅限于 read_item() 和 write_item() 操作。同样，对于所有事务，读取和写入构成基本的数据库操作。

事务操作

事务中执行的低级操作如下：

  • begin_transaction - 指定事务执行开始的标记。

  • read_item 或 write_item - 作为事务一部分，可能与主存操作交错的数据库操作。

  • end_transaction - 指定事务结束的标记。

  • commit - 一个信号，指定事务已成功完全完成，并且不会被撤消。

  • rollback - 一个信号，指定事务不成功，因此数据库中所有临时更改都将被撤消。已提交的事务不能回滚。

事务状态

事务可能会经历五个状态的子集：活动、部分提交、提交、失败和中止。

  • 活动 - 事务进入的初始状态是活动状态。在执行读取、写入或其他操作时，事务将保持在此状态。

  • 部分提交 - 在事务的最后一个语句执行后，事务进入此状态。

  • 提交 - 在事务成功完成并且系统检查发出提交信号后，事务进入此状态。

  • 失败 - 当发现无法继续正常执行或系统检查失败时，事务将从部分提交状态或活动状态变为失败状态。

  • 中止 - 这是事务在失败后回滚且数据库已恢复到事务开始之前状态后的状态。

以下状态转换图描绘了事务中的状态以及导致状态更改的低级事务操作。

State Transition Diagram

事务的理想属性

任何事务都必须保持 ACID 属性，即原子性、一致性、隔离性和持久性。

  • 原子性 - 此属性指出事务是处理的原子单元，也就是说，要么完全执行，要么根本不执行。不应该存在部分更新。

  • 一致性 - 事务应将数据库从一个一致状态转换到另一个一致状态。它不应对数据库中的任何数据项产生不利影响。

  • 隔离性 − 事务应该被执行，就好像它是系统中唯一的事务一样。不应该有任何来自同时运行的其他并发事务的干扰。

  • 持久性 − 如果已提交的事务导致了更改，则该更改应该持久保存在数据库中，并且在发生任何故障时都不会丢失。

调度和冲突

在一个有多个并发事务的系统中，调度是操作执行的总顺序。给定一个包含 n 个事务的调度 S，例如 T1、T2、T3……Tn；对于任何事务 Ti，Ti 中的操作必须按照调度 S 中规定的顺序执行。

调度的类型

调度有两种类型：

  • 串行调度 − 在串行调度中，在任何时间点，只有一个事务处于活动状态，即事务之间没有重叠。这在以下图表中显示：

Serial Schedules

  • 并行调度 − 在并行调度中，多个事务同时处于活动状态，即事务包含在时间上重叠的操作。这在以下图表中显示：

Parallel Schedules

调度中的冲突

在一个包含多个事务的调度中，当两个活动事务执行不兼容的操作时，就会发生冲突。当以下三个条件同时存在时，两个操作被称为冲突：

  • 这两个操作属于不同的事务。

  • 这两个操作都访问相同的数据项。

  • 至少有一个操作是 write_item() 操作，即它试图修改数据项。

可串行化

‘n’ 个事务的可串行化调度是一个并行调度，它等价于包含相同 ‘n’ 个事务的串行调度。可串行化调度包含串行调度的正确性，同时确保并行调度更好的 CPU 利用率。

调度的等价性

两个调度的等价性可以分为以下类型：

  • 结果等价 − 产生相同结果的两个调度被称为结果等价。

  • 视图等价 − 以类似方式执行类似操作的两个调度被称为视图等价。

  • 冲突等价 − 如果两个调度包含相同的交易集并且具有相同的冲突操作对的顺序，则这两个调度被称为冲突等价。

分布式数据库管理系统 - 控制并发

并发控制技术确保多个事务同时执行，同时维护事务的 ACID 属性以及调度中的可串行化。

在本章中，我们将学习各种并发控制方法。

基于锁的并发控制协议

基于锁的并发控制协议使用数据项加锁的概念。锁是与数据项相关联的变量，它决定是否可以在该数据项上执行读/写操作。通常，使用锁兼容性矩阵来表示两个事务是否可以同时锁定数据项。

基于锁的并发控制系统可以使用单相或两相锁定协议。

单相锁定协议

在这种方法中，每个事务在使用数据项之前对其加锁，并在使用完后立即释放锁。这种锁定方法提供了最大的并发性，但并不总是强制执行可串行化。

两相锁定协议

在这种方法中，所有锁定操作都先于第一个锁释放或解锁操作。事务包含两个阶段。在第一阶段，事务只获取它需要的所有锁，并且不释放任何锁。这称为扩展阶段或增长阶段。在第二阶段，事务释放锁，并且不能请求任何新的锁。这称为收缩阶段。

遵循两相锁定协议的每个事务都保证是可串行化的。但是，这种方法在两个冲突事务之间提供了较低的并行性。

时间戳并发控制算法

基于时间戳的并发控制算法使用事务的时间戳来协调对数据项的并发访问，以确保可串行化。时间戳是由 DBMS 给事务分配的唯一标识符，表示事务的开始时间。

这些算法确保事务按照其时间戳指示的顺序提交。较旧的事务应该在较新的事务之前提交，因为较旧的事务先进入系统。

基于时间戳的并发控制技术生成可串行化调度，使得等价的串行调度按参与事务的年龄排序。

一些基于时间戳的并发控制算法包括：

  • 基本时间戳排序算法。
  • 保守时间戳排序算法。
  • 基于时间戳排序的多版本算法。

基于时间戳的排序遵循三个规则来强制执行可串行化：

  • 访问规则 − 当两个事务尝试同时访问相同的数据项时，对于冲突操作，优先考虑较旧的事务。这会导致较新的事务等待较旧的事务先提交。

  • 晚事务规则 − 如果较新的事务已写入数据项，则不允许较旧的事务读取或写入该数据项。此规则可防止较旧的事务在较新的事务已提交后提交。

  • 年轻事务规则 − 较新的事务可以读取或写入已由较旧的事务写入的数据项。

乐观并发控制算法

在冲突率低的系统中，验证每个事务的可串行化的任务可能会降低性能。在这些情况下，可串行化的测试被推迟到提交之前。由于冲突率低，中止不可串行化事务的概率也低。这种方法称为乐观并发控制技术。

在这种方法中，事务的生命周期被划分为以下三个阶段：

  • 执行阶段 − 事务将数据项提取到内存中并在其上执行操作。

  • 验证阶段 − 事务执行检查以确保将其更改提交到数据库通过可串行化测试。

  • 提交阶段 − 事务将内存中修改后的数据项写回磁盘。

该算法使用三个规则在验证阶段强制执行可串行化：

规则 1 − 给定两个事务 Ti 和 Tj，如果 Ti 读取 Tj 正在写入的数据项，则 Ti 的执行阶段不能与 Tj 的提交阶段重叠。Tj 只能在 Ti 完成执行后提交。

规则 2 − 给定两个事务 Ti 和 Tj，如果 Ti 写入 Tj 正在读取的数据项，则 Ti 的提交阶段不能与 Tj 的执行阶段重叠。Tj 只能在 Ti 已提交后开始执行。

规则 3 − 给定两个事务 Ti 和 Tj，如果 Ti 写入 Tj 也正在写入的数据项，则 Ti 的提交阶段不能与 Tj 的提交阶段重叠。Tj 只能在 Ti 已提交后开始提交。

分布式系统中的并发控制

在本节中，我们将了解如何在分布式数据库系统中实现上述技术。

分布式两阶段锁定算法

分布式两阶段锁定的基本原理与基本的两阶段锁定协议相同。但是，在分布式系统中，有一些站点被指定为锁管理器。锁管理器控制来自事务监视器的锁获取请求。为了在各个站点的锁管理器之间强制协调，至少要有一个站点被赋予查看所有事务并检测锁冲突的权限。

根据可以检测锁冲突的站点的数量，分布式两阶段锁定方法可以分为三种类型：

  • 集中式两阶段锁定 − 在这种方法中，一个站点被指定为中央锁管理器。环境中的所有站点都知道中央锁管理器的地址，并在事务期间从中获取锁。

  • 主副本两阶段锁定 − 在这种方法中，一些站点被指定为锁控制中心。每个站点负责管理一组定义的锁。所有站点都知道哪个锁控制中心负责管理哪个数据表/碎片项的锁。

  • 分布式两阶段锁定 − 在这种方法中，有多个锁管理器，其中每个锁管理器控制存储在其本地站点的锁项。锁管理器的地址基于数据分布和复制。

分布式时间戳并发控制

在集中式系统中，任何事务的时间戳由物理时钟读数确定。但是，在分布式系统中，任何站点的本地物理/逻辑时钟读数都不能用作全局时间戳，因为它们不是全局唯一的。因此，时间戳包含站点 ID 及其站点时钟读数的组合。

为了实现时间戳排序算法，每个站点都有一个调度程序，为每个事务管理器维护一个单独的队列。在事务期间，事务管理器向站点的调度程序发送锁定请求。调度程序将请求按时间戳递增的顺序放入相应的队列中。请求按照队列中时间戳的顺序从队列的前面处理，即最旧的先处理。

冲突图

另一种方法是创建冲突图。为此，定义了事务类。事务类包含两个数据项集，称为读取集和写入集。如果事务的读取集是类读取集的子集，并且事务的写入集是类写入集的子集，则事务属于特定类。在读取阶段，每个事务都会发出其读取集中的数据项的读取请求。在写入阶段，每个事务都会发出其写入请求。

为活动事务所属的类创建冲突图。这包含一组垂直、水平和对角线边。垂直边连接类内的两个节点，表示类内的冲突。水平边连接两个类中的两个节点，表示不同类之间的写写冲突。对角线边连接两个类中的两个节点，表示两个类之间的写读或读写冲突。

冲突图被分析以确定同一类或跨两个不同类的两个事务是否可以并行运行。

分布式乐观并发控制算法

分布式乐观并发控制算法扩展了乐观并发控制算法。对于此扩展，应用了两个规则：

规则 1 - 根据此规则，事务在执行时必须在所有站点进行本地验证。如果发现任何站点上的事务无效，则将其中止。本地验证保证事务在已执行的站点上保持可串行化。事务通过本地验证测试后，将进行全局验证。

规则 2 - 根据此规则，事务通过本地验证测试后，应进行全局验证。全局验证确保如果两个冲突事务在多个站点一起运行，则它们应在所有一起运行的站点上以相同的相对顺序提交。这可能需要事务在验证后在提交之前等待另一个冲突事务。此要求使算法不那么乐观，因为事务可能无法在站点验证后立即提交。

分布式数据库管理系统 - 死锁处理

本章概述了数据库系统中的死锁处理机制。我们将研究集中式和分布式数据库系统中的死锁处理机制。

什么是死锁？

死锁是数据库系统的一种状态，其中两个或多个事务，每个事务都在等待由其他事务锁定的数据项。可以通过等待图中的循环来指示死锁。这是一个有向图，其中顶点表示事务，边表示等待数据项。

例如，在下面的等待图中，事务 T1 正在等待被 T3 锁定的数据项 X。T3 正在等待被 T2 锁定的 Y，而 T2 正在等待被 T1 锁定的 Z。因此，形成了一个等待循环，并且任何事务都无法继续执行。

Wait-For-Graph

集中式系统中的死锁处理

有三种经典的死锁处理方法，即：

  • 死锁预防。
  • 死锁避免。
  • 死锁检测和消除。

这三种方法都可以在集中式和分布式数据库系统中使用。

死锁预防

死锁预防方法不允许任何事务获取会导致死锁的锁。约定是，当多个事务请求锁定相同的数据项时，只允许其中一个获得锁。

最流行的死锁预防方法之一是在开始执行之前预先获取所有锁。在这种方法中，事务在开始执行之前获取所有锁，并在整个事务期间保持这些锁。如果另一个事务需要任何已获取的锁，则必须等到它需要的所有锁都可用为止。使用这种方法，可以防止系统死锁，因为没有一个等待的事务持有任何锁。

死锁避免

死锁避免方法在死锁发生之前处理死锁。它分析事务和锁以确定等待是否会导致死锁。

该方法可以简要说明如下。事务开始执行并请求它们需要锁定的数据项。锁管理器检查锁是否可用。如果可用，锁管理器分配数据项，事务获取锁。但是，如果该项被其他事务以不兼容模式锁定，则锁管理器运行一个算法来测试将事务保持在等待状态是否会导致死锁。相应地，算法决定事务是否可以等待或应中止其中一个事务。

为此目的，有两种算法，即等待-死亡和伤害-等待。假设有两个事务 T1 和 T2，其中 T1 尝试锁定已被 T2 锁定的数据项。算法如下：

  • 等待-死亡 - 如果 T1 比 T2 旧，则允许 T1 等待。否则，如果 T1 比 T2 新，则中止 T1 并稍后重新启动。

  • 伤害-等待 - 如果 T1 比 T2 旧，则中止 T2 并稍后重新启动。否则，如果 T1 比 T2 新，则允许 T1 等待。

死锁检测和消除

死锁检测和消除方法定期运行死锁检测算法，并在存在死锁时消除死锁。它不会在事务发出锁请求时检查死锁。当事务请求锁时，锁管理器检查它是否可用。如果可用，则允许事务锁定数据项；否则允许事务等待。

由于在授予锁请求时没有采取预防措施，因此某些事务可能会死锁。为了检测死锁，锁管理器定期检查等待图是否存在循环。如果系统死锁，锁管理器从每个循环中选择一个受害者事务。受害者被中止并回滚；然后稍后重新启动。一些用于受害者选择的算法是：

  • 选择最年轻的事务。
  • 选择数据项最少的事务。
  • 选择执行更新次数最少的事务。
  • 选择重启开销最少的事务。
  • 选择属于两个或多个循环的事务。

这种方法主要适用于事务量低且需要快速响应锁请求的系统。

分布式系统中的死锁处理

分布式数据库系统中的事务处理也是分布式的，即同一事务可能在多个站点上进行处理。分布式数据库系统中不存在于集中式系统中的两个主要死锁处理问题是事务位置和事务控制。解决这些问题后，可以通过任何死锁预防、死锁避免或死锁检测和消除来处理死锁。

事务位置

分布式数据库系统中的事务在多个站点上处理，并在多个站点上使用数据项。数据处理量在这些站点之间并不均匀分布。处理时间段也各不相同。因此，同一事务可能在某些站点处于活动状态，而在其他站点处于非活动状态。当两个冲突事务位于一个站点时，可能发生其中一个处于非活动状态的情况。这种情况在集中式系统中不会出现。这种问题称为事务位置问题。

可以通过雏菊链模型解决此问题。在此模型中，事务在从一个站点移动到另一个站点时会携带某些详细信息。其中一些详细信息是所需表的列表、所需站点的列表、已访问的表和站点的列表、尚未访问的表和站点的列表以及已获取锁的类型列表。事务通过提交或中止终止后，应将信息发送到所有相关站点。

事务控制

事务控制涉及指定和控制分布式数据库系统中处理事务所需的站点。关于在哪里处理事务以及如何指定控制中心，有很多选择，例如：

  • 可以选择一个服务器作为控制中心。
  • 控制中心可能在服务器之间移动。
  • 控制的责任可能由多个服务器共享。

分布式死锁预防

就像集中式死锁预防一样，在分布式死锁预防方法中，事务应在开始执行之前获取所有锁。这可以防止死锁。

事务进入的站点被指定为控制站点。控制站点向数据项所在的站点发送消息以锁定这些项。然后它等待确认。当所有站点都确认已锁定数据项后，事务开始。如果任何站点或通信链路发生故障，事务必须等到它们修复后才能继续。

尽管实现简单，但这种方法有一些缺点：

  • 预先获取锁需要很长时间来处理通信延迟。这增加了事务所需的时间。

  • 如果站点或链路发生故障，事务必须等待很长时间才能使站点恢复。同时，在运行的站点中，项目被锁定。这可能会阻止其他事务执行。

  • 如果控制站点发生故障，它将无法与其他站点通信。这些站点继续将其锁定的数据项保持在锁定状态，从而导致阻塞。

分布式死锁避免

与集中式系统一样，分布式死锁避免在发生之前处理死锁。此外，在分布式系统中，需要解决事务位置和事务控制问题。由于事务的分布式特性，可能会发生以下冲突：

  • 同一站点中两个事务之间的冲突。
  • 不同站点中两个事务之间的冲突。

发生冲突时，根据分布式等待-死亡或分布式伤害-等待算法，可以中止其中一个事务或允许其等待。

假设有两个事务 T1 和 T2。T1 到达站点 P 并尝试锁定已被 T2 在该站点锁定的数据项。因此，在站点 P 处存在冲突。算法如下：

  • 分布式伤害-死亡

    • 如果 T1 比 T2 旧，则允许 T1 等待。在站点 P 接收消息确认 T2 已在所有站点成功提交或中止后，T1 可以恢复执行。

    • 如果 T1 比 T2 新，则中止 T1。站点 P 的并发控制向 T1 已访问的所有站点发送消息以中止 T1。控制站点在 T1 已在所有站点成功中止后通知用户。

  • 分布式等待-等待

    • 如果 T1 比 T2 旧，则需要中止 T2。如果 T2 在站点 P 处于活动状态，则站点 P 中止并回滚 T2，然后将此消息广播到其他相关站点。如果 T2 已离开站点 P 但在站点 Q 处于活动状态，则站点 P 广播 T2 已被中止；然后站点 L 中止并回滚 T2 并将此消息发送到所有站点。

    • 如果 T1 比 T2 新，则允许 T1 等待。在站点 P 接收消息确认 T2 已完成处理后，T1 可以恢复执行。

分布式死锁检测

就像集中式死锁检测方法一样，允许发生死锁，并在检测到时将其消除。系统在事务发出锁请求时不执行任何检查。为了实现，创建全局等待图。全局等待图中存在循环表示死锁。但是，由于事务跨网络等待资源，因此很难发现死锁。

或者，死锁检测算法可以使用计时器。每个事务都与一个计时器相关联，该计时器设置为事务预计完成的时间段。如果事务在此时间段内未完成，则计时器超时，指示可能存在死锁。

用于死锁处理的另一个工具是死锁检测器。在集中式系统中，有一个死锁检测器。在分布式系统中，可以有多个死锁检测器。死锁检测器可以找到其控制的站点上的死锁。分布式系统中死锁检测有三种替代方案，即。

  • 集中式死锁检测器 - 指定一个站点作为中央死锁检测器。

  • 分层死锁检测器 - 将多个死锁检测器按层次结构排列。

  • 分布式死锁检测器 - 所有站点都参与检测和消除死锁。

分布式 DBMS - 副本控制

本章将探讨副本控制，副本控制是维护所有站点数据一致性所必需的。我们将研究副本控制技术以及副本控制所需的算法。

如前所述，复制是在分布式数据库中使用的技术，用于在不同站点存储数据表的多个副本。在多个站点拥有多个副本的问题在于维护数据一致性的开销，尤其是在更新操作期间。

为了在所有站点上维护相互一致的数据，需要采用副本控制技术。副本控制有两种方法，即 -

  • 同步复制控制
  • 异步复制控制

同步复制控制

在同步复制方法中，数据库是同步的，以便所有副本始终具有相同的值。请求数据项的事务将在所有站点访问相同的值。为了确保这种一致性，更新数据项的事务被扩展，以便它在数据项的所有副本中进行更新。通常，使用两阶段提交协议来实现此目的。

例如，让我们考虑一个数据表 PROJECT(PId, PName, PLocation)。我们需要运行一个事务 T1，如果 PLocation 为 'Bombay'，则将 PLocation 更新为 'Mumbai'。

Begin T1: 
   Update PROJECT Set PLocation = 'Mumbai' 
   Where PLocation = 'Bombay'; 
End T1;

如果数据表在站点 A 和站点 B 中有两个副本，则 T1 需要生成两个对应于这两个站点的子事务 T1A 和 T1B。扩展的事务 T1 将为 -

Begin T1: 
   Begin T1A : 
      Update PROJECT Set PLocation = 'Mumbai' 
      Where PLocation = 'Bombay'; 
   End T1A;  
	
   Begin T2A : 
      Update PROJECT Set PLocation = 'Mumbai'
      Where PLocation = 'Bombay'; 
   End T2A; 
	
End T1;

异步复制控制

在异步复制方法中，副本并不总是维护相同的值。一个或多个副本可能存储过时的值，并且事务可以看到不同的值。将所有副本更新到当前值的过程称为同步。

一种流行的同步方法是存储转发方法。在这种方法中，一个站点被指定为主站点，其他站点为辅助站点。主站点始终包含更新的值。所有事务首先进入主站点。然后将这些事务排队以在辅助站点中应用。仅当事务计划在其上执行时，才使用回滚方法更新辅助站点。

副本控制算法

一些副本控制算法有 -

  • 主从复制控制算法。
  • 分布式投票算法。
  • 多数一致性算法。
  • 循环令牌算法。

主从复制控制算法

有一个主站点和 'N' 个从站点。主算法在主站点运行以检测冲突。从算法的副本在每个从站点运行。整个算法在以下两个阶段执行 -

  • 事务接受/拒绝阶段 - 当事务进入从站点的监视器时，从站点会向主站点发送请求。主站点检查冲突。如果没有冲突，则主站点向从站点发送“ACK+”消息，然后从站点开始事务应用阶段。否则，主站点向从站点发送“ACK-”消息，然后从站点拒绝该事务。

  • 事务应用阶段 - 进入此阶段后，事务进入的从站点向所有从站广播请求以执行事务。收到请求后，对等从站执行事务并在完成后向请求的从站发送“ACK”。在请求的从站收到来自所有对等节点的“ACK”消息后，它向主站点发送“DONE”消息。主站点了解到事务已完成并将其从挂起队列中删除。

分布式投票算法

这包括 'N' 个对等站点，所有这些站点都必须在事务开始执行之前“确认”该事务。以下是该算法的两个阶段 -

  • 分布式事务接受阶段 - 当事务进入站点的监视器时，它会向所有其他站点发送事务请求。收到请求后，对等站点使用基于优先级的投票规则解决冲突。如果所有对等站点都“确认”该事务，则请求站点开始应用阶段。如果任何对等站点不“确认”该事务，则请求站点拒绝该事务。

  • 分布式事务应用阶段 - 进入此阶段后，事务进入的站点向所有从站广播请求以执行事务。收到请求后，对等从站执行事务并在完成后向请求的从站发送“ACK”消息。在请求的从站收到来自所有对等节点的“ACK”消息后，它会让事务管理器知道事务已完成。

多数一致性算法

这是分布式投票算法的一个变体，其中当大多数对等节点“确认”事务时，允许执行事务。这分为三个阶段 -

  • 投票阶段 - 当事务进入站点的监视器时，它会向所有其他站点发送事务请求。收到请求后，对等站点使用投票规则测试冲突并将任何冲突的事务（如果有）保留在挂起队列中。然后，它发送“OK”或“NOT OK”消息。

  • 事务接受/拒绝阶段 - 如果请求站点收到关于该事务的大多数“OK”，则它接受该事务并向所有站点广播“ACCEPT”。否则，它向所有站点广播“REJECT”并拒绝该事务。

  • 事务应用阶段 - 当对等站点收到“REJECT”消息时，它会将其事务从其挂起列表中删除并重新考虑所有延迟的事务。当对等站点收到“ACCEPT”消息时，它会应用该事务并拒绝挂起队列中与此事务冲突的所有延迟事务。它在完成后向请求的从站发送“ACK”。

循环令牌算法

在这种方法中，系统中的事务使用循环令牌进行序列化并相应地针对数据库的每个副本执行。因此，所有事务都被接受，即没有被拒绝。这有两个阶段 -

  • 事务序列化阶段 - 在此阶段，所有事务都按序列化顺序安排运行。每个站点中的每个事务都从一个连续序列中分配一个唯一的票证，指示事务的顺序。一旦事务被分配了票证，它就会被广播到所有站点。

  • 事务应用阶段 - 当站点收到事务及其票证时，它会根据其票证安排该事务执行。事务执行完成后，该站点广播相应的消息。当事务在所有站点中完成执行时，它结束。

分布式 DBMS - 故障和提交

数据库管理系统容易受到多种故障的影响。在本章中，我们将研究故障类型和提交协议。在分布式数据库系统中，故障可以大致分为软故障、硬故障和网络故障。

软故障

软故障是指导致计算机易失性存储器丢失，而非持久性存储器丢失的故障类型。此处，存储在非持久性存储器（如主内存、缓冲区、缓存或寄存器）中的信息将丢失。它们也称为系统崩溃。软故障的各种类型如下 -

  • 操作系统故障。
  • 主内存崩溃。
  • 事务失败或中止。
  • 系统生成的错误，例如整数溢出或除以零错误。
  • 支持软件故障。
  • 电源故障。

硬故障

硬故障是指导致持久性或非易失性存储器（如磁盘）中的数据丢失的故障类型。磁盘故障可能导致某些磁盘块中的数据损坏或整个磁盘故障。硬故障的原因是 -

  • 电源故障。
  • 介质故障。
  • 读写故障。
  • 磁盘上信息的损坏。
  • 磁盘读/写磁头损坏。

如果有一个新的、已格式化且可立即使用的备用磁盘，则从磁盘故障中恢复可能很快。否则，持续时间包括获取采购订单、购买磁盘并准备磁盘所需的时间。

网络故障

网络故障在分布式或网络数据库中很普遍。这些包括由于数据的分布式特性和通过网络传输数据而导致的数据库系统中的错误。网络故障的原因如下 -

  • 通信链路故障。
  • 网络拥塞。
  • 传输过程中信息损坏。
  • 站点故障。
  • 网络分区。

提交协议

任何数据库系统都应保证即使在故障后也能维护事务的理想属性。如果在事务执行期间发生故障，则可能发生事务带来的所有更改均未提交。这使得数据库不一致。提交协议使用事务撤销（回滚）或事务重做（向前恢复）来防止这种情况。

提交点

做出是否提交或中止事务的决策的时间点称为提交点。以下是提交点的一些属性。

  • 它是数据库一致的时间点。

  • 此时，数据库带来的修改可以被其他事务看到。所有事务都可以拥有数据库的一致视图。

  • 此时，事务的所有操作均已成功执行，其效果已记录在事务日志中。

  • 此时，如果需要，可以安全地撤消事务。

  • 此时，事务释放其持有的所有锁。

事务撤销

撤消事务对数据库所做的所有更改的过程称为事务撤销或事务回滚。这主要用于软故障的情况。

事务重做

重新应用事务对数据库所做的更改的过程称为事务重做或事务向前滚回。这主要用于从硬件故障中恢复。

事务日志

事务日志是一个顺序文件，用于跟踪对数据库项的事务操作。由于日志本质上是顺序的，因此可以从开头或结尾顺序处理。

事务日志的目的 -

  • 支持提交协议以提交或支持事务。
  • 在故障后帮助数据库恢复。

事务日志通常保存在磁盘上，因此不受软件故障的影响。此外，日志会定期备份到磁带等归档存储中，以防止磁盘故障。

事务日志中的列表

事务日志根据事务的状态维护五种类型的列表。此列表帮助恢复管理器确定事务的状态。状态和相应的列表如下 -

  • 具有事务开始记录和事务提交记录的事务是已提交的事务 - 保存在提交列表中。

  • 具有事务开始记录和事务失败记录但没有事务中止记录的事务是失败的事务 - 保存在失败列表中。

  • 具有事务开始记录和事务中止记录的事务是已中止的事务 - 保存在中止列表中。

  • 具有事务开始记录和事务提交前记录的事务是提交前事务，即所有操作都已执行但尚未提交的事务 - 保存在提交前列表中。

  • 具有事务开始记录但没有提交前、提交、中止或失败记录的事务是活动事务 - 保存在活动列表中。

立即更新和延迟更新

立即更新和延迟更新是维护事务日志的两种方法。

在立即更新模式下，当事务执行时，事务所做的更新将直接写入磁盘。在写入磁盘上的数据库之前，旧值和更新值将写入日志。提交时，对磁盘所做的更改将变为永久性。回滚时，数据库中事务所做的更改将被丢弃，并且旧值将从日志中存储的旧值恢复到数据库中。

在延迟更新模式下，当事务执行时，事务对数据库所做的更新将记录在日志文件中。提交时，日志中的更改将写入磁盘。回滚时，日志中的更改将被丢弃，并且不会对数据库应用任何更改。

分布式DBMS - 数据库恢复

为了从数据库故障中恢复，数据库管理系统采用多种恢复管理技术。在本章中，我们将研究数据库恢复的不同方法。

数据库恢复的典型策略如下 -

  • 如果发生导致数据库不一致的软件故障，恢复策略包括事务撤销或回滚。但是，有时也可能采用事务重做来恢复到事务的一致状态。

  • 如果发生导致数据库严重损坏的硬件故障，恢复策略包括从归档备份中恢复数据库的过去副本。通过从事务日志中重做已提交事务的操作，可以获得数据库的更当前状态。

从电源故障中恢复

电源故障会导致非持久性内存中的信息丢失。恢复电源后，操作系统和数据库管理系统将重新启动。恢复管理器将从事务日志中启动恢复。

在立即更新模式下，恢复管理器将执行以下操作 -

  • 处于活动列表和失败列表中的事务将被撤销并写入中止列表。

  • 处于提交前列表中的事务将被重做。

  • 对提交或中止列表中的事务不采取任何操作。

在延迟更新模式下，恢复管理器将执行以下操作 -

  • 处于活动列表和失败列表中的事务将写入中止列表。由于更改尚未写入磁盘，因此不需要撤销操作。

  • 处于提交前列表中的事务将被重做。

  • 对提交或中止列表中的事务不采取任何操作。

从磁盘故障中恢复

磁盘故障或硬件崩溃会导致数据库完全丢失。要从这种硬件崩溃中恢复，需要准备一个新磁盘，然后恢复操作系统，最后使用数据库备份和事务日志恢复数据库。恢复方法对于立即更新模式和延迟更新模式都是相同的。

恢复管理器将执行以下操作 -

  • 提交列表和提交前列表中的事务将被重做并写入事务日志中的提交列表。

  • 活动列表和失败列表中的事务将被撤销并写入事务日志中的中止列表。

检查点

检查点是将记录从缓冲区写入数据库的时间点。因此，如果发生系统崩溃，恢复管理器不必重做在检查点之前已提交的事务。定期检查点可以缩短恢复过程。

两种类型的检查点技术是 -

  • 一致性检查点
  • 模糊检查点

一致性检查点

一致性检查点在检查点创建数据库的一致映像。在恢复期间，仅撤销或重做最后一个检查点右侧的事务。最后一个一致性检查点左侧的事务已提交，无需再次处理。检查点的操作如下 -

  • 活动事务将暂时挂起。
  • 主内存缓冲区中的所有更改都将写入磁盘。
  • 在事务日志中写入“检查点”记录。
  • 事务日志将写入磁盘。
  • 挂起的交易将恢复。

如果在步骤4中，事务日志也被存档，则此检查点有助于从磁盘故障和电源故障中恢复，否则它仅有助于从电源故障中恢复。

模糊检查点

在模糊检查点中，在检查点时，所有活动事务都将写入日志。如果发生电源故障，恢复管理器仅处理检查点期间和之后处于活动状态的事务。在检查点之前已提交的事务将写入磁盘，因此无需重做。

检查点示例

让我们考虑一下，在系统中，检查点时间为tcheck，系统崩溃时间为tfail。假设有四个事务Ta、Tb、Tc和Td，其中 -

  • Ta在检查点之前提交。

  • Tb在检查点之前启动并在系统崩溃之前提交。

  • Tc在检查点之后启动并在系统崩溃之前提交。

  • Td在检查点之后启动并在系统崩溃时处于活动状态。

这种情况在下图中描述 -

Depicted Situation

恢复管理器采取的操作是 -

  • 对Ta不执行任何操作。
  • 对Tb和Tc执行事务重做。
  • 对Td执行事务撤销。

使用撤销/重做的事务恢复

事务恢复是为了消除错误事务的不利影响，而不是为了从故障中恢复。错误事务包括所有已将数据库更改为不需要的状态的事务，以及已使用错误事务写入的值的事务。

在这些情况下，事务恢复是一个两步过程 -

  • 撤销所有错误事务以及可能受错误事务影响的事务。

  • 重做所有未出错但由于错误事务而被撤销的事务。

撤销操作的步骤如下 -

  • 如果错误事务已执行插入操作，则恢复管理器将删除插入的数据项。

  • 如果错误事务已执行删除操作，则恢复管理器将从日志中插入已删除的数据项。

  • 如果错误事务已执行更新操作，则恢复管理器将通过从日志中写入更新前值来消除该值。

重做操作的步骤如下 -

  • 如果事务已执行插入操作，则恢复管理器将从日志中生成插入操作。

  • 如果事务已执行删除操作，则恢复管理器将从日志中生成删除操作。

  • 如果事务已执行更新操作，则恢复管理器将从日志中生成更新操作。

分布式DBMS - 提交协议

在本地数据库系统中，要提交事务，事务管理器只需将提交决策传达给恢复管理器即可。但是，在分布式系统中，事务管理器应将提交决策传达给正在执行事务的各个站点中的所有服务器，并统一执行该决策。当每个站点上的处理完成后，它将进入部分提交事务状态，并等待所有其他事务到达其部分提交状态。当它收到所有站点已准备好提交的消息时，它将开始提交。在分布式系统中，要么所有站点都提交，要么没有一个站点提交。

不同的分布式提交协议包括 -

  • 一阶段提交
  • 两阶段提交
  • 三阶段提交

分布式一阶段提交

分布式一阶段提交是最简单的提交协议。让我们考虑一下，有一个控制站点和许多正在执行事务的从站。分布式提交的步骤如下 -

  • 每个从站本地完成其事务后，都会向控制站点发送“完成”消息。

  • 从站等待来自控制站点的“提交”或“中止”消息。此等待时间称为漏洞窗口。

  • 当控制站点从每个从站收到“完成”消息时，它将决定提交或中止。这称为提交点。然后，它将此消息发送到所有从站。

  • 收到此消息后，从站要么提交要么中止，然后向控制站点发送确认消息。

分布式两阶段提交

分布式两阶段提交减少了一阶段提交协议的漏洞。两阶段执行的步骤如下：

阶段 1：准备阶段

  • 每个从站本地完成其事务后，向控制站发送“DONE”消息。当控制站从所有从站收到“DONE”消息时，它向从站发送“Prepare”消息。

  • 从站投票决定是否仍然要提交。如果从站想要提交，则发送“Ready”消息。

  • 不想提交的从站发送“Not Ready”消息。当从站存在冲突的并发事务或超时时，可能会发生这种情况。

阶段 2：提交/中止阶段

  • 控制站从所有从站收到“Ready”消息后：

    • 控制站向从站发送“Global Commit”消息。

    • 从站应用事务并向控制站发送“Commit ACK”消息。

    • 当控制站从所有从站收到“Commit ACK”消息时，它认为事务已提交。

  • 控制站从任何从站收到第一个“Not Ready”消息后：

    • 控制站向从站发送“Global Abort”消息。

    • 从站中止事务并向控制站发送“Abort ACK”消息。

    • 当控制站从所有从站收到“Abort ACK”消息时，它认为事务已中止。

分布式三阶段提交

分布式三阶段提交的步骤如下：

阶段 1：准备阶段

步骤与分布式两阶段提交相同。

阶段 2：准备提交阶段

  • 控制站发出“Enter Prepared State”广播消息。
  • 从站响应“OK”。

阶段 3：提交/中止阶段

步骤与两阶段提交相同，只是不需要“Commit ACK”/“Abort ACK”消息。

DDBMS - 数据库安全与加密

在本章中，我们将探讨数据库系统面临的威胁以及控制措施。我们还将学习加密作为一种安全工具。

数据库安全与威胁

数据安全是任何数据库系统中一个重要的方面。在分布式系统中，由于用户数量众多、数据碎片化和复制、多个站点和分布式控制，数据安全显得尤为重要。

数据库中的威胁

  • 可用性丢失 - 可用性丢失是指合法用户无法访问数据库对象。

  • 完整性丢失 - 完整性丢失发生在对数据库执行不可接受的操作时，无论是偶然的还是恶意的。这可能发生在创建、插入、更新或删除数据时。它会导致数据损坏，从而导致错误的决策。

  • 机密性丢失 - 机密性丢失是由于未经授权或意外泄露机密信息而导致的。这可能导致非法行为、安全威胁和公众信任的丧失。

控制措施

控制措施可以大致分为以下几类：

  • 访问控制 - 访问控制包括数据库管理系统中的安全机制，以防止未经授权的访问。用户只有通过有效的用户帐户，在清除登录过程后才能访问数据库。每个用户帐户都受密码保护。

  • 流控制 - 分布式系统包含大量从一个站点到另一个站点以及站点内的数据流。流控制防止数据以未经授权的代理可以访问的方式传输。流策略列出了信息可以流动的通道。它还为数据和事务定义安全级别。

  • 数据加密 - 数据加密是指在通过公共通道通信敏感数据时对数据进行编码。即使未经授权的代理访问了数据，由于数据处于不可理解的格式，他也无法理解它。

什么是加密？

加密是在通过不可靠的通信路径发送信息之前对信息进行编码的科学，以便只有授权的接收者才能对其进行解码和使用。

编码后的消息称为密文，原始消息称为明文。发送方使用加密算法将明文转换为密文的过程称为编码或加密。接收方使用解密算法将密文转换为明文的过程称为解码或解密。

使用加密进行通信的整个过程可以通过以下图表说明：

Cryptography

传统加密方法

在传统加密中，加密和解密使用相同的密钥。在这里，发送方使用密钥副本和加密算法对消息进行加密。然后，加密后的消息通过公共通信通道发送。接收方收到加密后的消息后，使用相同的密钥和相应的解密算法对其进行解密。

传统加密的安全性取决于两个因素：

  • 一种对所有人公开的可靠算法。

  • 一个随机生成的，最好是较长的密钥，只有发送方和接收方知道。

最著名的传统加密算法是数据加密标准或DES。

这种方法的优点是易于应用。但是，传统加密的最大问题是在通信双方之间共享密钥。发送密钥的方式很麻烦，并且极易受到窃听。

公钥加密

与传统加密相反，公钥加密使用两个不同的密钥，称为公钥和私钥。每个用户生成一对公钥和私钥。然后，用户将公钥放在一个可访问的地方。当发送方想要发送消息时，他使用接收方的公钥对其进行加密。接收方收到加密后的消息后，使用其私钥对其进行解密。由于私钥只有接收方知道，因此任何其他接收消息的人员都无法对其进行解密。

最流行的公钥加密算法是RSA算法和Diffie-Hellman算法。这种方法发送私人消息非常安全。但是，问题在于它涉及大量的计算，因此对于长消息来说效率低下。

解决方案是结合使用传统加密和公钥加密。在共享密钥之前，使用公钥加密对密钥进行加密。然后，使用共享密钥和传统加密方法发送消息。

数字签名

数字签名 (DS) 是一种基于公钥加密的认证技术，用于电子商务应用程序。它将唯一的标记与个人在其消息正文中关联。这有助于其他人验证消息的有效发送者。

通常，用户的数字签名在每条消息中都不同，以防止伪造。方法如下：

  • 发送方获取消息，计算消息摘要并使用私钥对其进行签名。

  • 然后，发送方将签名的摘要与明文消息一起附加。

  • 消息通过通信通道发送。

  • 接收方删除附加的签名摘要，并使用相应的公钥验证摘要。

  • 然后，接收方获取明文消息并通过相同的摘要算法运行。

  • 如果步骤 4 和步骤 5 的结果匹配，则接收方知道消息具有完整性和真实性。

DDBMS - 分布式数据库中的安全

与集中式系统相比，分布式系统需要额外的安全措施，因为存在许多用户、多样化的数据、多个站点和分布式控制。在本章中，我们将探讨分布式数据库安全的各个方面。

在分布式通信系统中，有两种类型的入侵者：

  • 被动窃听者 - 他们监视消息并获取私人信息。

  • 主动攻击者 - 他们不仅监视消息，还通过插入新数据或修改现有数据来破坏数据。

安全措施包括通信安全、数据安全和数据审计。

通信安全

在分布式数据库中，由于数据、用户和事务位置的多样化，大量数据通信发生。因此，它要求用户和数据库之间以及不同数据库环境之间进行安全的通信。

通信安全包括以下内容：

  • 数据在传输过程中不应损坏。

  • 通信通道应免受被动窃听者和主动攻击者的攻击。

  • 为了实现上述要求，应采用定义明确的安全算法和协议。

两种流行且一致的技术可用于实现端到端安全通信：

  • 安全套接字层协议或传输层安全协议。
  • 虚拟专用网络 (VPN)。

数据安全

在分布式系统中，除了通信之外，必须采取措施来保护数据安全。数据安全措施包括：

  • 身份验证和授权 - 这些是采用的访问控制措施，以确保只有经过身份验证的用户才能使用数据库。为了提供身份验证，使用了数字证书。此外，登录通过用户名/密码组合进行限制。

  • 数据加密 - 分布式系统中数据加密的两种方法是：

    • 分布式数据库内部方法：用户应用程序加密数据，然后将加密后的数据存储在数据库中。为了使用存储的数据，应用程序从数据库中提取加密后的数据，然后对其进行解密。

    • 分布式数据库外部方法：分布式数据库系统具有自己的加密功能。用户应用程序存储数据并检索数据，而无需意识到数据以加密形式存储在数据库中。

  • 验证输入 - 在此安全措施中，用户应用程序在每个输入用于更新数据库之前对其进行检查。未经验证的输入会导致各种漏洞，例如缓冲区溢出、命令注入、跨站点脚本和数据损坏。

数据审计

数据库安全系统需要检测和监视安全违规，以确定应采取的安全措施。在发生安全违规时，通常很难检测到。识别安全违规的一种方法是检查审计日志。审计日志包含以下信息：

  • 失败的访问尝试的日期、时间和站点。
  • 成功访问尝试的详细信息。
  • 数据库系统中的重要修改。
  • 大量数据的访问，特别是来自多个站点中的数据库。

以上所有信息提供了数据库活动情况的概述。定期分析日志有助于识别任何异常活动，以及其发生的地点和时间。理想情况下，此日志应存储在独立的服务器上，以防止攻击者访问。

打印页面
上一页
下一页
广告