分布式OLTP数据库系统_分布式oltp有哪些

OLTP

OLTP VS OLAP

On-line Transaction Processing:

• 短暂的读/写txns。
• Small footprint
• 可重复操作

On-line Analytical Processing:

• 长期运行的只读查询。
• 复杂的Joins
• 临时查询

三个问题:

1. 如果节点出现故障，会发生什么情况？
2. 如果我们的信息显示晚了会发生什么？
3. 如果我们不等待每个节点都同意，会发生什么？

重要假设：
假设分布式DBMS中的所有节点都行为良好，并且在同一管理域下。如果我们告诉节点提交txn，那么它将提交txn（如果没有失败）。

如果不信任分布式DBMS中的其他节点，则需要对txns（区块链）使用拜占庭容错协议(Byzantine Fault Tolerant)。

Atomic Commit Protocol

当多节点txn完成时，DBMS需要询问所有涉及的节点是否安全提交。

examples:

• Two-Phase Commit
• Three-Phase Commit
• Paxos
• Raft
• Apache Zookeeper
• Viewstamped Replication

Two-Phase Commit/Abort

Two-Phase Commit

每个节点将每个阶段的入站/出站消息和结果记录在非易失性存储日志中。

恢复时，检查日志中是否有2PC消息：

• 如果本地txn处于准备状态，联系Cooidinator。
• 如果本地TXN未准备好，将其中止。
• 如果本地txn正在提交，而节点Coordinator，则向节点发送提交消息。

Two-Phase Commit Failures

如果Coordinator崩溃会发生什么？

• Participants必须决定超时后要做什么。
• 系统在此期间不可用。
  如果Coordinator崩溃，会发生什么？
• Coordinator假定如果尚未发送确认，则它以中止响应。
• 同样，节点使用超时来确定Participant已死亡。

2PC Optimizations

Early Prepare Voting(Rare)
如果将查询发送到知道将在那里执行的最后一个查询的远程节点，则该节点也将返回他们对准备阶段的投票，并返回查询结果。

Early Ack After Prepare(Common)
如果所有节点都投票提交txn，协调器可以在提交阶段结束之前向客户端发送其txn成功的确认。

Early acknowledgement after prepare是一种对2PC的优化方法，它可以提高事务的响应时间和吞吐量。它的基本思想是，如果所有参与者都同意提交事务，那么协调者可以在提交阶段之前就向客户端发送一个确认消息（Acknowledge Message），表示该事务已经成功完成。这样，客户端就不需要等待提交阶段的结束，而可以立即开始新的事务。同时，协调者也可以减少对参与者的通信开销，因为它不需要等待所有参与者的完成消息。

Early acknowledgement after prepare的优点是可以降低事务的平均延迟，提高系统的并发性和性能。缺点是可能增加系统的复杂性和风险，因为如果在提交阶段发生了故障或网络分区，那么客户端可能会收到错误的确认消息，导致数据不一致或异常。因此，这种优化方法需要保证系统的可靠性和容错性，以及合理地选择确认消息的发送时机。

PAXOS

共识协议，其中coordinator提出结果（例如，提交或中止），然后participants就该结果是否应成功进行投票。
如果大多数Participants可用，并且在最佳情况下消息延迟可证明最小，则不会阻止。

MULTI-PAXOS

如果系统选择了一个Leader，在一段时间内监督提议的变更，则它可以跳过提议阶段。每当出现故障时，都会恢复到完整的Paxos。
系统定期使用另一轮Paxos续订领导者（称为租约）。节点必须在Leader选举期间交换日志条目，以确保每个人都是最新的。

2PC VS PAXOS

2 Phase Commit
如果Coordinator在发送准备消息后失败，则阻塞，直到Coordinator恢复。

PAXOS
如果大多数Participants还活着，则不封锁，前提是有足够长的时间没有进一步的失败。

Replication

DBMS可以跨冗余节点复制数据，以提高可用性。

设计决策：

• 副本配置
• 传播方案
• 传播时机
• 更新方法

Replica Configurations

方法一：Primary-Replica

• 所有更新都将转到每个对象的指定主对象。
• 主节点在没有原子提交协议的情况下将更新传播到其副本。
• 只读txns可能被允许访问副本。
• 如果主节点关闭，则举行选举以选择新的主节点。

方法二：Multi-Primary

• Txns可以更新任何副本上的数据对象。
• 副本必须使用原子提交协议相互同步。

K-Safety

K-Safety是确定复制数据库容错性的阈值。
值K表示每个数据对象必须始终可用的副本数。
如果复制副本的数量低于此阈值，则DBMS将停止执行并使自己脱机。

Propagation Scheme

当txn在复制的数据库上提交时，DBMS决定它是否必须等待txn的更改传播到其他节点，然后才能将确认发送到应用程序。

传播级别：

1. 同步（强一致性）： 主服务器向复制副本发送更新，然后等待它们确认它们已完全应用（即，记录）更改。
2. 异步（最终一致性）：主设备立即将确认返回给客户端，而无需等待副本应用更改。

Propagation Timing

方法一：Continuous：DBMS在生成日志消息时立即发送日志消息。 还需要发送提交/中止消息。
方法二：On Commit : DBMS仅在提交txn后将txn的日志消息发送到副本。不要浪费时间发送中止的txns的日志记录。 假设txn的日志记录完全适合内存

Updata Method

方法一：Acitve-Active

• txn在每个副本上独立执行。
• 需要在最后检查txn是否在每个副本上都有相同的结果。

方法二：Active-Passive

• 每个txn在单个位置执行，并将更改传播到副本。
• 可以执行物理复制或逻辑复制。
• 与主副本与多主副本不同

CAP理论

• Consistent
• Always Available
• Network Partition Tolerant

一个缺陷是，它忽略了一致性与延迟的权衡。