分散式資料庫管理系統 - 快速指南

上一頁
下一頁

分散式資料庫管理系統 - 概念

任何組織的正常運作都需要一個維護良好的資料庫。在最近的過去，資料庫通常是集中式的。然而，隨著全球化的發展，組織往往在全球範圍內多元化。他們可以選擇將資料分佈在本地伺服器上，而不是集中式資料庫。因此，出現了分散式資料庫的概念。

本章概述了資料庫和資料庫管理系統 (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)。

資料安全

在分散式系統中，除了通訊之外，必須採取措施來保護資料安全。資料安全措施包括：

  • 身份驗證和授權 - 這些是採用的訪問控制措施，以確保只有經過身份驗證的使用者才能使用資料庫。為了提供身份驗證，使用了數字證書。此外，登入透過使用者名稱/密碼組合進行限制。

  • 資料加密 - 分散式系統中資料加密的兩種方法是：

    • 分散式資料庫內部方法：使用者應用程式加密資料，然後將加密後的資料儲存在資料庫中。為了使用儲存的資料，應用程式從資料庫中提取加密後的資料，然後對其進行解密。

    • 分散式資料庫外部方法：分散式資料庫系統具有自己的加密功能。使用者應用程式儲存資料並檢索資料，而無需意識到資料以加密形式儲存在資料庫中。

  • 驗證輸入 - 在此安全措施中，使用者應用程式在每個輸入用於更新資料庫之前對其進行檢查。未經驗證的輸入會導致各種漏洞，例如緩衝區溢位、命令注入、跨站點指令碼和資料損壞。

資料審計

資料庫安全系統需要檢測和監視安全違規，以確定應採取的安全措施。在發生安全違規時，通常很難檢測到。識別安全違規的一種方法是檢查審計日誌。審計日誌包含以下資訊：

  • 失敗的訪問嘗試的日期、時間和站點。
  • 成功訪問嘗試的詳細資訊。
  • 資料庫系統中的重要修改。
  • 大量資料的訪問，特別是來自多個站點中的資料庫。

以上所有資訊提供了資料庫活動情況的概述。定期分析日誌有助於識別任何異常活動，以及其發生的地點和時間。理想情況下，此日誌應儲存在獨立的伺服器上，以防止攻擊者訪問。

列印頁面
上一頁
下一頁
廣告

© . All rights reserved.