分布式数据库

Parallel VS. Distributed

Parallel DBMSs:

节点在物理上彼此靠近。
连接高速LAN的节点。
假设通信成本较小。

分布式DBMS：

节点可以彼此远离。
使用公网连接的节点。
沟通成本和问题不容忽视

Distributed DBMSs

使用我们在单节点DBMS中介绍的构建块，现在支持分布式环境中的事务处理和查询执行。

优化&查询
并发控制
日志&恢复

System architecture

分布式DBMS的系统架构规定了CPU可以直接访问哪些共享资源
这将影响CPU之间的协调方式以及它们在数据库中检索/存储对象的位置。

分布式数据库四种架构是指数据库系统在不同的物理或逻辑节点上如何存储和处理数据的方式，它们分别是：

Shared everything：这种架构下，所有的节点都可以完全透明地共享CPU、内存、磁盘和其他资源。这种架构的优点是可以实现高度的并发和事务处理，以及简化数据管理和负载均衡。缺点是扩展性较差，因为增加节点会增加资源的竞争和同步的开销，以及降低系统的可靠性和容错性。
Shared nothing：这种架构下，每个节点都有自己独立的CPU、内存、磁盘和其他资源，节点之间不共享任何资源。这种架构的优点是可以实现高度的扩展性和并行性，以及降低资源冲突和同步开销。缺点是需要进行复杂的数据划分和路由，以及处理跨节点的事务一致性问题。Shared nothing架构是目前最流行的分布式数据库架构，它可以支持海量数据和复杂查询的场景。
Shared disk：这种架构下，每个节点都有自己独立的CPU和内存，但是共享一个或多个磁盘系统。这种架构的优点是可以实现高度的数据可用性和容灾能力，以及简化数据管理和备份。缺点是需要消耗大量的网络带宽和磁盘I/O，以及处理复制冲突和延迟问题。Shared disk架构一般适用于传统的关系型数据库系统，或者需要支持强一致性和事务性的场景。
Shared storage：这种架构下，多个无状态的计算节点共享一个有状态的分布式存储引擎。这种架构的优点是可以实现计算和存储的分离和优化，以及支持跨节点的复杂查询。缺点是需要实现复杂的分布式存储协议，以及处理存储层和计算层之间的通信问题。Shared storage架构一般适用于新型的关系型数据库系统（NewSQL），或者需要支持OLAP（联机分析处理）的场景。

Homogenous VS Heterogenous

Homogenous Nodes(同构)

群集中的每个节点都可以执行相同的任务集（尽管在可能不同的数据分区上）。
使调配和故障切换“更容易”。

Heterogenous Nodes(异构)

节点被分配特定的任务。
可以允许单个物理节点托管用于专用任务的多个“虚拟”节点类型。

Data Transaparency

不应要求应用程序知道数据在分布式DBMS中的物理位置。

在单节点DBMS上运行的任何查询都应在分布式DBMS上产生相同的结果。

在实际开发中，开发人员需要意识到查询的通信成本，以避免过度“昂贵”的数据移动。

Data partitioning

跨多个资源拆分数据库：

磁盘、节点、处理器。
在NoSQL系统中通常被称为“分片”。

DBMS在每个分区上执行查询片段，然后组合结果以生成单个结果。
DBMS可以对数据库进行物理分区（无共享）或逻辑分区（共享磁盘）。

NÏVE TABLEPARTITIONING（原生表分区）

将整个表分配给单个节点。
假设每个节点都有足够的存储空间容纳整个表。
如果查询从不跨存储在不同节点上的表连接数据，并且访问模式是统一的，则是理想的选择。

Vertical Partitioning

将表的属性拆分为单独的分区。
必须存储元组信息以重建原始记录。

Horizontal Partitioning

根据某些分区键和方案，将表的元组拆分为不相交的子集。

选择在大小、负载或使用情况方面平均划分数据库的列。

分区方案：

Hashing
Ranges
Predicates(谓词)

Logical Partitioning

Consistent Hashing

Consistent hashing（一致性哈希）是一种分布式哈希算法，它可以将一个键空间映射到一个抽象的圆环上，称为哈希环。哈希环上有多个节点，每个节点代表一个服务器或一个存储单元。每个键通过一个哈希函数计算出一个值，然后在哈希环上顺时针找到最近的节点，就是该键所属的分区。这样，当节点增加或减少时，只有少量的键需要重新映射到其他节点，从而保持了数据的一致性和平衡性。

水平分区和一致性哈希可以结合使用，来实现分布式数据库中的数据划分和负载均衡。具体来说，可以将每个表按照某个属性进行水平分区，然后将每个子表通过一致性哈希映射到不同的节点上。这样，可以根据数据的访问特征和分布特征来选择合适的划分属性和哈希函数，从而提高数据访问和处理的效率，以及简化数据管理和维护。

Single-Node VS. Distrubuted

单节点txn只访问一个分区中包含的数据。

DBMS可能不需要检查在其他节点上运行的行为并发txns。

分布式txn访问一个或多个分区的数据。

需要昂贵的协调。

Transaction Coordination

如果我们的DBMS支持多操作和分布式txns，我们需要一种方法来协调它们在系统中的执行

分布式系统中的事务协调（Transaction Coordination）是一种保证分布式事务的原子性和一致性的机制，它涉及到多个参与者（Participants）和一个或多个协调者（Coordinators）。参与者是执行事务操作的实体，比如数据库服务器或应用服务器。协调者是负责管理和控制事务的生命周期的实体，比如事务管理器或中间件。事务协调的主要任务是在所有参与者之间达成一致的决定，即要么所有参与者都提交（Commit）事务，要么所有参与者都回滚（Rollback）事务。

两个方法
根据协调者的数量和位置，分布式系统中的事务协调可以分为两种类型：集中式（Centralized）和去中心化（Decentralized）。

Centralized:Global “traffic cop”
Decentralized:Nodes organize themselves

TP Monitors
TP监视器是分布式DBMS的集中协调器(Centralized)的示例。常见的例子：ATM

Centralized Coordinator

集中式事务协调是指只有一个协调者负责管理所有参与者的事务状态和决定。这种类型的事务协调通常采用两阶段提交协议（Two-Phase Commit Protocol，2PC）或其变体来实现。两阶段提交协议包括两个阶段：投票阶段（Voting Phase）和提交阶段（Commit Phase）。在投票阶段，协调者向所有参与者发送准备消息（Prepare Message），询问它们是否准备好提交事务。每个参与者根据自己的本地事务状态回复同意消息（Agree Message）或拒绝消息（Abort Message）。在提交阶段，协调者根据所有参与者的回复决定最终的事务结果，并向所有参与者发送提交消息（Commit Message）或回滚消息（Rollback Message）。每个参与者根据协调者的指令执行相应的操作，并向协调者发送完成消息（Complete Message）。集中式事务协调的优点是简单、高效、易于实现。缺点是单点故障、性能瓶颈、网络延迟等问题。

Dentralized Coordinator

去中心化事务协调是指有多个协调者负责管理不同的参与者或不同的子事务。这种类型的事务协调通常采用三阶段提交协议（Three-Phase Commit Protocol，3PC）或其变体来实现。三阶段提交协议在两阶段提交协议的基础上增加了一个预提交阶段（Pre-Commit Phase），以避免单点故障导致的不确定状态。在预提交阶段，如果所有参与者都同意提交事务，那么协调者向所有参与者发送预提交消息（Pre-Commit Message），并等待它们的确认消息（Acknowledge Message）。在提交阶段，如果所有参与者都确认预提交消息，那么协调者向所有参与者发送提交消息，并等待它们的完成消息。去中心化事务协调的优点是容错性、可扩展性、并行性等。缺点是复杂、低效、难以实现等。

Distributed Concurrency Control

需要允许多个txns在多个节点上同时执行。

可以适配来自单节点DBMS的许多相同协议。

这更难，因为：

复制
网络通信开销
节点故障
时钟偏斜

Distributed 2PL

分布式两阶段锁（Distributed Two-Phase Locking，D2PL）是一种分布式事务的并发控制协议，它基于两阶段锁（Two-Phase Locking，2PL）的原理，将锁的管理和释放分为两个阶段进行。在第一个阶段，称为增长阶段（Growing Phase），事务可以根据需要获取不同节点上的数据对象的锁，但不能释放任何锁。在第二个阶段，称为收缩阶段（Shrinking Phase），事务不能再获取任何新的锁，只能释放已经持有的锁。这样可以保证事务的执行满足冲突可串行化（Conflict Serializability）的要求，即不会出现因为多个事务之间的读写操作顺序不一致而导致的数据不一致或异常的情况。

分布式两阶段锁的实现需要一个全局的锁管理器（Lock Manager），它负责维护所有节点上的数据对象的锁状态和请求队列，并根据一定的策略分配和释放锁。每个节点上的事务管理器（Transaction Manager）负责向锁管理器发送锁请求和释放消息，并根据锁管理器的回复执行相应的操作。分布式两阶段锁协议的基本流程如下：

当一个事务需要访问一个数据对象时，它首先向锁管理器发送一个锁请求消息，指明数据对象的标识符、所需的锁模式（共享或独占）和事务标识符。
锁管理器收到锁请求消息后，检查该数据对象是否已经被其他事务加锁，以及该事务是否已经进入收缩阶段。如果该数据对象没有被加锁，或者已经被加了与所需模式相容的锁，并且该事务还在增长阶段，那么锁管理器就将该数据对象加上相应的锁，并向事务管理器发送一个授予消息，表示同意该事务访问该数据对象。如果该数据对象已经被加了与所需模式不相容的锁，或者该事务已经进入收缩阶段，那么锁管理器就将该事务加入到该数据对象的等待队列中，并向事务管理器发送一个拒绝消息，表示暂时不允许该事务访问该数据对象。
事务管理器收到授予消息后，就可以执行对应的读写操作，并继续发送其他的锁请求消息。如果收到拒绝消息，就必须等待直到收到授予消息才能继续执行。
当一个事务完成了对所有需要访问的数据对象的操作后，它就进入收缩阶段，并向锁管理器发送一个释放消息，指明要释放哪些数据对象上的哪些模式的锁。
锁管理器收到释放消息后，就将该事务持有的相应的锁解除，并检查是否有其他等待中的事务可以获得这些锁。如果有，就将这些锁分配给这些事务，并向它们发送授予消息。如果没有，就将这些数据对象标记为未加锁状态。

分布式两阶段锁协议可以保证分布式事务之间不会发生冲突操作，从而实现并发控制和数据一致性。但是它也有一些缺点和限制：

它需要一个全局的、可靠的、高效的、低延迟的锁管理器来协调所有节点上的事务和数据对象。这在实际中可能很难实现或维护。
它可能导致死锁（Deadlock）的发生，即多个事务相互等待对方持有的锁而无法继续执行。这需要额外的机制来检测和解决死锁，比如设置超时时间、使用等待图、采用死锁预防或避免策略等。
它可能降低系统的并发性和性能，因为事务需要等待锁的授予和释放，而且不能提前释放不再需要的锁。这会增加事务的响应时间和资源占用，以及网络通信的开销。