OLTP
OLTP VS OLAP
On-line Transaction Processing:
- 短暂的读/写txns。
- Small footprint
- 可重复操作
On-line Analytical Processing:
- 长期运行的只读查询。
- 复杂的Joins
- 临时查询
三个问题:
- 如果节点出现故障,会发生什么情况?
- 如果我们的信息显示晚了会发生什么?
- 如果我们不等待每个节点都同意,会发生什么?
重要假设:
假设分布式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的更改传播到其他节点,然后才能将确认发送到应用程序。
传播级别:
- 同步(强一致性): 主服务器向复制副本发送更新,然后等待它们确认它们已完全应用(即,记录)更改。
- 异步(最终一致性):主设备立即将确认返回给客户端,而无需等待副本应用更改。
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
一个缺陷是,它忽略了一致性与延迟的权衡。