OLTP 和 OLAP
在线事务处理 (OLTP)：
- 短期读/写事务。
- 占地面积小。
- 重复操作。
在线分析处理 (OLAP)：
- 长时间运行的只读查询。
- 复杂连接。
- 探索性查询。
我们还没有讨论如何确保所有节点都同意提交一个事务，然后确保它在我们决定应该提交的情况下确实提交。
- 如果一个节点发生故障会发生什么？
- 如果我们的消息迟到了怎么办？
- 如果我们不等待每个节点都同意会发生什么？
重要假设
我们可以假设分布式 DBMS 中的所有节点都表现良好并且在同一个管理域下。
如果我们告诉一个节点提交一个事务，那么它将提交该事务（如果没有失败）。
如果您不信任分布式 DBMS 中的其他节点，则需要为事务使用拜占庭容错协议（区块链）。
原子提交协议
当多节点事务完成时，DBMS 需要询问所有涉及的节点是否可以安全提交。
例如：
- 两阶段提交
- 三阶段提交（未使用）
- Paxos
- Raft
- ZAB（Apache Zookeeper）
- 时间戳复制（Viewstamp Replication）
两阶段提交（2PC）
2PC 过程
2PC 的优化
提前准备投票：如果您已知发送到某远程节点的查询是您将在此执行的最后一个查询，那么该节点还将返回他们对准备阶段的投票以及查询结果。
准备后的早期确认：如果所有节点都投票提交一个事务，协调器可以在提交阶段完成之前，向客户端发送一个确认：它们的事务是成功的。
2PC 故障处理
每个节点在非易失性存储日志中记录每个阶段的结果。
如果协调者崩溃了怎么办？
参与者必须决定做什么。
如果参与者崩溃了怎么办？
如果尚未发送确认，则协调者假定它以中止响应。
Paxos
过程
协调者提出结果（例如，提交或中止）然后参与者投票决定该结果是否应该成功的共识协议。 如果大多数参与者都可用并且在最好的情况下具有可证明的最小消息延迟，则不会阻止。
Multi-Paxos
如果系统选举了一个负责在一段时间内提议更改的领导者，那么它可以跳过提议阶段。每当出现故障时回退到完整的 Paxos。
系统会使用另一轮 Paxos 定期更新领导者。
2PC 和 Paxos
2PC：如果在发送准备消息后协调者宕机，则放弃事务，直到协调者恢复。
Paxos：如果大多数参与者还活着，则不会阻塞，只要有足够长的时间没有进一步的失败。
复制
DBMS 可以跨冗余节点复制数据以提高可用性。
设计决策：
- 副本配置
- 传播方案
- 传播时序
- 更新方法
复制方案
方法 #1：主节点-副本
- 所有更新都转到每个对象的指定主节点。
- 主节点在没有原子提交协议的情况下将更新传播到其副本。
- 可能允许只读事务访问副本。
- 如果主节点宕机，则举行选举以选择新的主节点。
方法 #2：多主节点
- 事务可以更新任何副本的数据对象。
- 副本必须使用原子提交协议相互同步。
K-SAFETY
K-safety 是确定复制数据库容错的阈值。K 表示每个数据对象必须始终可用的副本数。如果副本数量低于此阈值，则 DBMS 将停止执行并使其自身脱机。
传播方案
当一个事务在复制数据库上提交时，DBMS 决定是否必须等待该事务的更改传播到其他节点，然后才能向应用程序发送确认。
传播级别：
- 同步（强一致性）
- 异步（最终一致性）
方法 #1：同步传播：主服务器向副本发送更新，然后等待他们确认他们已完全应用（即记录）更改。
方法 #2：异步传播：主节点立即向客户端返回确认，而无需等待副本应用更改。
传播时间
方法 #1：持续传播
- DBMS 在生成日志消息时立即发送它们。
- 还需要发送提交/放弃消息。
方法 #2：提交时传播
- DBMS 仅在事务提交后将事务的日志消息发送到副本。
- 不要浪费时间为中止的事务发送日志记录。
- 假设事务的日志记录完全符合内存。
主动与被动
方法 #1：主动-主动
- 一个事务在每个副本上独立执行。
- 最后需要检查事务是否在每个副本上得到相同的结果。
方法 #2：主动-被动
- 每个事务在单个位置执行并将更改传播到副本。
- 可以进行物理或逻辑复制。
- 不同于主节点-副本与多主节点
一致性问题 (CAP)
CAP 定理：由Eric Brewer提出，在 2002 年被证明，分布式系统不可能总是：
- 一致（Consistency）：可线性化
- 始终可用（Availability）：所有 up 节点都可以满足所有请求。
- 网络分区容错（Partition Tolerant）：尽管消息丢失，仍然可以正常运行。
OLTP DBMS 中的 CAP
DBMS 如何处理故障决定了它们支持 CAP 定理的哪些元素。传统/NewSQL DBMS：在大多数节点重新连接之前停止允许更新；NoSQL DBMS：提供在节点重新连接后解决冲突的机制。
联合数据库
我们假设分布式系统中的节点运行相同的 DBMS 软件。但组织经常在其应用程序中运行许多不同的 DBMS。如果我们可以为所有数据提供一个接口，那就太好了。
将多个 DBMS 连接到一个逻辑系统中的分布式架构。查询可以访问任何位置的数据。
这很难，没有人能做好：
- 不同的数据模型、查询语言、限制。
- 没有简单的方法来优化查询
- 大量数据复制（坏）。
总结
我们假设分布式 DBMS 中的节点是友好的。
区块链数据库假设节点是对抗性的。 这意味着您必须使用不同的协议来提交事务。
