42、分布式数据库：查询、事务、并发与复制的全面解析-优快云博客

本文链接：https://blog.youkuaiyun.com/i0j1k2l3m/article/details/151003783

分布式数据库：查询、事务、并发与复制的全面解析

1. 分布式查询策略

在处理分布式查询时，有多种策略可供选择。其中一种策略是将物化的工资视图转移到培训站点，在那里执行连接操作，然后将结果返回给协调器。虽然从医疗保健站点向培训站点转移工资行看似可以通过一条语句完成，但由于医疗保健站点不知道培训站点的存在，无法直接进行转移，因此在协调器上会涉及一个隐式临时表。

另一种策略是将课程行转移到医疗保健站点，并在那里执行连接操作。对于全局查询而言，最有效的计划是最大限度限制网络流量的计划。如果工资表比课程表小，那么第二种策略可能是最佳选择。将工资表转移到培训站点的网络成本较低，并且连接结果也会较小，因为只有有限数量的课程行与转移的工资行匹配。

在没有关于工资表和课程表物化的相对大小的信息的情况下，无法做出合理的决策。可以通过收集表统计信息来辅助决策，例如可以不时地通过在全局控制系统（GCS）中物化视图并对其进行分析来收集类似的统计信息。

当全局查询被分解并将本地查询分发到各个本地节点后，本地查询优化器负责将接收到的查询最终转换为最优的文件和缓冲区操作。这不仅会考虑统计信息，还会考虑表存储结构、索引等信息。

分布式查询分解示例

以下是一个分布式查询分解的示例：
- 分布式查询：

select * from medicaltraining;

分解后的查询：

create [Training].tempA as select *
from [HealthCare].payroll;
select ID, name, course_ID, data, cost
from [Training].courses, [Training].tempA
where ID=delegate_ID;

2. 分布式事务

2.1 事务特性

在分布式数据库中，事务的原子性、一致性、隔离性和持久性同样重要。数据库必须保证事务中的所有语句，无论是分布式还是非分布式的，都作为一个整体提交或回滚。正在进行的事务的影响对所有节点上的其他事务都应该是不可见的，这种透明性对于包括查询、更新、插入或删除等任何类型操作的事务都应该成立。

在分布式数据库中，即使发生网络或系统故障，也必须通过网络协调事务控制，以保持数据一致性。分布式事务的一个特殊问题是，全局查询被分解为一系列序列化的本地事务，并提交给自治的本地服务器。如果其中一个本地事务因任何原因失败而其他事务成功，分布式视图将受到影响。每个本地服务器会通过其事务机制维护本地一致性，但必须通过协调器进行某种形式的事务控制。

2.2 两阶段提交（2PC）

两阶段提交（2PC）是一种用于保证分布式数据库原子性和一致性的机制。在每个本地事务结束时，事务处于预提交状态或失败状态。投票协调器会询问每个参与服务器根据其状态进行投票。

如果所有服务器都同意全局提交，投票协调器会发出全局提交命令，每个参与服务器提交其本地事务，并向投票协调器确认该命令。
如果有任何一个服务器投票反对全局提交，投票协调器会发出全局中止命令。处于预提交状态的服务器执行回滚，处于失败状态的服务器进入中止状态，并再次向协调器发送确认信息。

两阶段提交机制试图保证分布式事务中的所有参与服务器要么全部提交，要么全部回滚。它还保护由完整性约束或触发器执行的隐式本地DML操作。大多数主流数据库包都实现了2PC，但研究文献中提出了许多加强2PC机制的方法，以解决其局限性，例如投票协调器在任何一个阶段失败或参与者投票后失败等问题。这些扩展需要包含在专门构建的软件中。

两阶段提交状态转换流程图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([Initial]):::startend --> B(Coordinator):::process
    A --> C(Participating site):::process
    B --> D(Prepare):::process
    C --> E(Prepare):::process
    D --> F(Vote Commit):::process
    E --> G(Vote Commit):::process
    F --> H{Unanimous?}:::decision
    G --> H
    H -->|Yes| I(Global Commit):::process
    H -->|No| J(Global Abort):::process
    I --> K(Commit):::process
    J --> L(Rollback/Abort):::process
    K --> M([End]):::startend
    L --> M

2.3 分布式并发

两阶段提交保证了原子性、持久性和一致性，但仍需要通过并发控制来维护隔离原则。全局事务管理器将优化和分解后的全局查询作为离散的本地查询进行分发。虽然每个本地查询在本地服务器中通过该服务器的锁和日志管理器进行安全隔离，但由于本地服务器不知道每个本地查询在全局查询中所起的作用，会出现问题。

例如，考虑两个全局查询。第一个查询在一个站点读取表，作为更新另一个站点匹配行的前奏；第二个查询更新第一个站点的表中的行。如果本地数据库按照SQL92事务原则运行，第一个事务可能会遇到不可重复读或幻读的问题。因此，需要在全局查询级别进行某种形式的并发控制，以实现可串行化的并发级别。

并发控制方法主要分为乐观方法和悲观方法：
- 乐观方法 ：无论是基于锁还是使用时间戳，乐观方法都会将冲突解决或验证推迟到事务进入预提交阶段。读取操作从已提交的数据中进行，写入操作则写入所谓的影子文件，并对其他事务保密。验证阶段确定事务的执行是否可串行化。如果是，则提交事务；如果不是，则回滚事务并在随机时间延迟后重新启动。乐观控制不会产生等待状态或互斥，因此不会出现死锁。不维护和检查锁的获取可以减少事务管理器的开销，有利于提高吞吐量，但如果其使用与分布式数据库中的处理类型不匹配，可能会导致大量的重启。
- 悲观方法 ：悲观方法在请求时验证锁的获取或时间戳的顺序。锁管理器根据锁兼容性授予锁。在分布式数据库中，锁管理器（可能不一定与全局事务管理器位于同一位置）维护全局模式对象的锁表，本地模式对象由本地数据库控制。

并发控制方法分类

并发控制方法	特点
乐观方法	推迟冲突解决或验证，减少等待状态和互斥，可能导致大量重启
悲观方法	在请求时验证锁或时间戳，通过锁管理器授予锁

分布式并发控制分类图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(分布式并发控制):::startend --> B(乐观方法):::process
    A --> C(悲观方法):::process
    B --> D(基于锁):::process
    B --> E(使用时间戳):::process
    C --> F(时间戳排序):::process
    C --> G(锁定):::process
    G --> H(集中式):::process
    G --> I(分布式):::process
    I --> J(主副本方法):::process
    I --> K(分散式):::process

乐观控制适用条件

条件	描述
所有事务都是只读的	事务只进行读取操作，不进行写入操作
许多事务，每个事务只访问/修改非常大的数据集的一小部分	事务对数据集的访问和修改范围较小
事务执行中发生冲突的比例与总数相比较小	事务之间发生冲突的可能性较低

3. 复制

复制是在构成分布式数据库系统的多个数据库中复制和维护数据库对象（如表格）的过程。在一个站点应用的更改会被捕获并本地存储，然后转发并应用到每个远程位置，这称为更新传播，是保持所有副本彼此一致的核心要求。

3.1 复制的优缺点

复制可以为分布式数据库系统带来许多优点，但也带来了一系列主要与复制数据的一致性维护相关的问题。
- 优点：
- 提高数据库对单个节点故障或网络中断的恢复能力。如果一个事务可以使用替代副本继续进行，故障透明度会增强，尽管故障站点的副本与任何更新都将不一致。
- 分布式数据库系统可以将经常作为全局查询对象的副本表与负责这些查询的用户放在一起。拥有频繁访问的数据库副本可以避免为支持全局连接而反复在网络上发送完整数据集，从而提高性能。
- 缺点：复制会对分布式数据库中的分布式查询优化、事务控制和并发控制产生影响。同时，引入复制会影响本地站点的自主性。如果本地站点必须保持完全自主，那么从这些站点复制数据就会变得困难。

3.2 复制与分布式数据库模型

为了使分布式数据库能够获取关于副本的信息，需要扩展现有的模型。在协调器级别包含复制模式是一种方法。例如，一个异构的、分布式的多数据库，对本地数据库的自主性有限制，即联邦多数据库，可以通过这种方式来处理复制。

数据可以使用在协调器控制下在选定本地站点创建的全局模式对象的可更新物化视图进行复制。可更新物化视图允许对视图中的行进行插入、更新和删除操作。

3.3 复制对本地自主性的影响

持有复制物化视图的站点之一将是主站点或源站点，该站点持有支持视图的基表。如果本地站点在分布式数据库中有一定的自主性，可能希望这些基表仍可直接用于本地事务。然而，如果直接更新基表，本地物化视图及其在分布式数据库各节点上的副本将与基表不一致。这种自主的本地更新是在任何全局查询之外进行的，唯一的解决方案是降低自主性，禁止直接更新复制物化视图的基表。

分布式数据库复制模型图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(全局概念模式):::startend --> B(片段模式):::process
    A --> C(分配模式):::process
    A --> D(复制模式):::process
    B --> E(本地信息模式1):::process
    B --> F(本地信息模式n):::process
    C --> G(本地概念模式1):::process
    C --> H(本地概念模式n):::process
    D --> I(复制信息):::process

4. 复制情况下的查询管理

4.1 副本选择

如果复制对象要参与查询，分布式查询优化器必须使用复制模式来选择直接使用的副本。选择标准将基于副本是否与查询中的其他全局模式对象位于同一位置。如果能够实现本地化连接，这将特别重要。如果在查询中要更新副本，则优化器生成的事务执行计划将包括在查询结束阶段进行传播更新。

4.2 事务处理

全局事务管理器接收执行计划，并将其组件作为查询提交给本地数据库。通常，全局事务管理器或临时指定的提交点服务器会执行两阶段提交程序。当分布式数据库中有复制元素时，可以使用几种投票协议，这些协议将2PC的共识（提交需要一致投票）规则放宽为多数规则。

4.3 网络故障处理

如果网络故障将分布式数据库划分为两个无法通信的部分，其中一部分节点数会多于另一部分，这称为主分区。只有主分区中的节点可以参与投票决策。如果主分区包含所有未复制的节点或足够的副本以确保整个更新数据集存在，则可以进行投票。根据定义，次分区只能包含副本或主分区中现在存在的副本的源站点。如果提交点服务器不在主分区中，可以选举一个替代服务器。

如果主分区中投票提交的站点包含所有更新数据集，则发出提交请求。次分区中的所有副本站点以及主分区中未投票提交的副本将被标记为不一致。当不一致的站点恢复到分布式数据库时，事务的提交点服务器会发出传播更新，使它们恢复一致。

投票协议处理网络故障示例

情况	处理方式
网络故障分区	确定主分区和次分区，主分区节点参与投票
提交点服务器不在主分区	选举替代服务器
主分区投票提交站点包含所有更新数据	发出提交请求，标记不一致副本，后续恢复一致性

5. 分布式数据库案例研究

5.1 背景

乌托邦职业球员协会（UPPA）是乌托邦足球联盟（UFL）球员的工会，预算有限，无法承担UFL所投资的昂贵计算和软件系统。UFL同意UPPA可以有限访问其主要的Oracle系统，将球员的个人详细信息纳入其会员系统。会员系统运行在Microsoft Access中，其功能之一是记录每个球员每月的会员订阅费用。

5.2 连接配置

Access可以基于ODBC标准与Oracle建立连接。在Access程序建立连接之前，本地ODBC驱动管理器必须配置一个数据源供其使用。在Windows XP中，可以通过控制面板的“管理工具”文件夹进行配置。

具体操作步骤如下：
1. 安装Oracle时，会将Oracle ODBC驱动添加到驱动管理器中。在数据源配置中，指定数据源将使用的Oracle实例及其ODBC名称。
2. 填写表单并点击“测试连接”，直到出现成功消息。
3. 点击“确定”后，新的数据源“UFL”将列在“机器数据源”选项卡中。

5.3 数据链接与应用构建

这个数据源可以用于从任何符合ODBC标准的程序连接到UFL数据库，包括MS Access、Excel、PowerPoint、Word以及使用ODBC API编写的用户程序。

在Access中构建简单应用的步骤如下：
1. 启动MS Access程序，创建一个名为“ufltest”的空白数据库。
2. 从Access主菜单中选择“文件”|“获取外部数据”|“链接表”。
3. 在文件选择对话框中，从“文件类型”下拉列表中选择“ODBC数据库”，出现DSN选择器。
4. 选择“UFL”数据源，并提供配置在其中的Oracle用户名的密码。
5. 显示用户模式中的表，选择“Players”表，并勾选“保存密码”框，点击“确定”。
6. Oracle表现在作为一个可更新视图“A27WS_PLAYERS”安装在Access中。由于密码与视图定义一起保存，Access可以在视图更改时自由连接到数据源以同步数据。打开Access中的视图也会将最新数据加载到视图中。

5.4 应用开发

可以基于这个表视图构建一个简单的Access应用。例如：
- 创建一个“members”表，该表只有三个字段。
- 使用以下查询将行追加到“members”表中：

INSERT INTO members ( ufa_id, joined )
SELECT A27WS_PLAYERS.UFA_ID, Date () AS Expr1
FROM A27WS_PLAYERS;

创建“members”和“A27WS_PLAYERS”之间的连接视图，连接基于公共字段“ufa_id”，这是一个选择查询，存储为“members and players”：

SELECT members.ufa_id, A27WS_PLAYERS.SURNAME, A27WS_PLAYERS.FORENAME,
A27WS_PLAYERS.DATEOFBIRTH, A27WS_PLAYERS.NATIONALITY,
A27WS_PLAYERS.CLUB, members.membership_id, members.joined
FROM A27WS_PLAYERS RIGHT JOIN members ON A27WS_PLAYERS.UFA_ID =
members.ufa_id;

创建一个“subscriptions”表，并使用相应的追加查询填充该表。
使用表单向导创建“members”表单，主表单基于“members and players”视图，并包含一个基于“subscriptions”的子表单，表单和子表单通过“membership_id”建立主/详细关系。

通过这种方式，与“Players”表的数据链接提供了前面所述的所有透明性。一旦链接配置完成，它就像一个本地表一样工作，不需要特殊处理或了解其位置。对球员数据的任何更改都会记录在Oracle基表中，直接对表所做的更改会在视图中显示出来。Oracle端的正常锁管理提供了并发访问控制。

6. 分布式查询优化总结

分布式查询优化流程

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(分析查询):::process
    B --> C{选择查询策略}:::decision
    C -->|根据表大小| D(确定转移对象):::process
    D --> E(收集统计信息):::process
    E --> F(本地查询优化):::process
    F --> G{是否有复制对象}:::decision
    G -->|是| H(选择合适副本):::process
    G -->|否| I(正常执行查询):::process
    H --> J(执行查询并考虑更新传播):::process
    I --> K([结束]):::startend
    J --> K

7. 分布式事务控制要点

分布式事务控制对于保证数据的一致性、原子性、隔离性和持久性至关重要。以下是分布式事务控制的关键要点：

7.1 两阶段提交（2PC）

投票机制 ：在每个本地事务结束时，投票协调器询问参与服务器投票，根据投票结果发出全局提交或全局中止命令，确保所有参与服务器要么全部提交，要么全部回滚。
局限性与扩展 ：虽然大多数主流数据库包实现了2PC，但存在一些局限性，如投票协调器或参与者失败等问题，扩展方法需包含在专门构建的软件中。

7.2 分布式并发控制

乐观方法 ：将冲突解决或验证推迟到事务预提交阶段，减少等待状态和互斥，但可能导致大量重启，适用于特定条件，如所有事务只读、事务访问数据量小、冲突比例低等。
悲观方法 ：在请求时验证锁的获取或时间戳顺序，通过锁管理器根据锁兼容性授予锁，可分为集中式和分布式等不同方式。

分布式事务控制流程

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始事务]):::startend --> B(分解全局查询):::process
    B --> C(分发本地查询):::process
    C --> D(本地事务执行):::process
    D --> E{本地事务结束}:::decision
    E -->|是| F(进入2PC投票阶段):::process
    F --> G{是否一致同意提交}:::decision
    G -->|是| H(全局提交):::process
    G -->|否| I(全局中止):::process
    H --> J(完成事务):::process
    I --> K(回滚事务):::process
    J --> L([结束]):::startend
    K --> L

8. 复制对分布式数据库的综合影响

复制在分布式数据库中既有优点也带来了挑战，对数据库的多个方面产生影响：

8.1 对本地自主性的影响

引入复制后，若要保证复制数据的一致性，需要限制本地站点的自主性，不允许直接更新复制物化视图的基表；若本地站点要保持完全自主，复制数据会变得困难。

8.2 对查询优化的影响

复制对象参与查询时，需要额外考虑副本的选择，根据副本与其他全局模式对象的位置关系优化查询，增加了查询优化的复杂度。

8.3 对事务控制的影响

当分布式数据库中有复制元素时，投票协议可能从2PC的共识规则放宽为多数规则，以处理网络故障等情况，确保事务的正确执行。

8.4 对并发控制的影响

复制可能导致更多的数据访问冲突，需要更复杂的并发控制机制来保证事务的隔离性，如在全局查询级别进行并发控制，实现可串行化的并发级别。

复制影响分布式数据库各方面的关系图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(复制):::startend --> B(本地自主性):::process
    A --> C(查询优化):::process
    A --> D(事务控制):::process
    A --> E(并发控制):::process
    B --> F(限制直接更新基表):::process
    C --> G(选择合适副本):::process
    D --> H(放宽投票规则):::process
    E --> I(增强并发控制):::process

9. 分布式数据库案例实践总结

通过乌托邦职业球员协会（UPPA）的案例，我们可以看到分布式数据库在实际应用中的具体操作和优势：

9.1 连接配置

基于ODBC标准，在Windows XP中通过控制面板的“管理工具”文件夹配置数据源，实现Access与Oracle数据库的连接，为后续数据操作奠定基础。

9.2 数据链接与应用构建

在Access中创建空白数据库，通过链接表的方式将Oracle表以可更新视图的形式引入，配置好密码可实现数据同步，方便对数据进行操作。

9.3 应用开发

利用引入的表视图，在Access中创建各种表、查询和表单，如“members”表、“subscriptions”表，以及相应的查询和表单，实现会员信息管理等功能，并且数据链接具有透明性，操作方便，同时Oracle端的锁管理提供并发访问控制。

分布式数据库案例实践步骤总结

步骤	操作内容
连接配置	在Windows XP中配置ODBC数据源，指定Oracle实例和ODBC名称，测试连接。
数据链接	在Access中创建空白数据库，通过“获取外部数据 - 链接表”选择ODBC数据库，选择数据源和表，保存密码。
应用开发	创建表、编写查询语句、创建表单，实现数据的插入、查询和管理等功能。

10. 分布式数据库的未来展望

随着数据量的不断增长和业务需求的日益复杂，分布式数据库在未来将面临更多的挑战和机遇：

10.1 性能优化

进一步研究和改进分布式查询优化算法，结合人工智能和机器学习技术，更精准地预测表的大小和查询模式，自动选择最优的查询策略，减少网络延迟和资源消耗。

10.2 事务处理

开发更高效、可靠的分布式事务控制协议，解决两阶段提交（2PC）的局限性，如在网络故障或节点失败时能更快地恢复和处理事务，提高系统的可用性和数据一致性。

10.3 并发控制

探索新的并发控制机制，平衡乐观方法和悲观方法的优缺点，适应不同类型的业务场景，确保事务的隔离性和并发性能。

10.4 复制管理

优化复制策略，减少更新传播的延迟，提高副本的一致性维护效率，同时降低对本地站点自主性的影响，实现复制与本地操作的更好融合。

10.5 安全与隐私

加强分布式数据库的安全防护，保障数据在传输和存储过程中的安全性和隐私性，应对日益增长的网络安全威胁。

分布式数据库未来发展方向

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A([分布式数据库]):::startend --> B(性能优化):::process
    A --> C(事务处理):::process
    A --> D(并发控制):::process
    A --> E(复制管理):::process
    A --> F(安全与隐私):::process
    B --> G(结合新技术):::process
    C --> H(改进协议):::process
    D --> I(探索新机制):::process
    E --> J(优化策略):::process
    F --> K(加强防护):::process

综上所述，分布式数据库在查询、事务、并发和复制等方面有其独特的技术和挑战。通过深入理解和掌握这些技术要点，并结合实际案例进行实践，能够更好地应用和优化分布式数据库系统，同时关注未来的发展方向，为应对不断变化的业务需求做好准备。