首页 cmu 15-445

OLTP

分布式TP数据库

  • 短的读写操作
  • small footprint
  • 重复性的小操作

AP

  • 超长语句,大部分only-read
  • 有很多join
  • 探索式的查询

主节点去查询问题:

  • 节点不同意操作怎么办
  • 消息延迟
  • 不相等节点同意怎么办

列表:

  • atomic commit protocols 原子化提交方案
  • replication 副本
  • consistency issues (CAP) CAP理论
  • federated database 联邦数据库

atomic commit protocols

当一个多节点事务完成的时候,DBMS需要去告诉节点提交是不是安全的

使用技术:

  • two-phase commit 2PC
  • three-phase commit (not used)
  • paxos
  • raft
  • ZAB (apache zookeeper)
  • viewstamped replication

2PC:二阶段提交

用户将一个提交请求,发送给其中一个节点(coordinator),协调员给其他节点(participant)发送一个提交请求,参与者同意就发送一个ok返回协调者,协调者发送commit命令,所有参与者ok之后给用户发送success

image-20220308082643867.png

如果有一个节点告诉说不行,要回滚,协调者会直接通知用户要回滚,自己告诉参与者回滚

优化:

early acknowledgement

当请求被所有参与者都同意的时候,直接给用户发送提交成功,然后再进行commit操作

问题:

如果协调者崩溃了,参与者自己决定怎么办,一般是直接回滚

参与者崩溃了怎么办,协调者就会认为参与者不同意这个事务

PAXOS

共识机制,大部分都同意了,那么不同意的也要同意

propooser 提案者

acceptor 参与者

提案者发现大多数同意了,提案通过,发给参与者,参与者完成之后发给用户成功,对于宕机的就等到他没事时让其强制执行

多个事务:拒接旧的事务,同意新的事务

image-20220308092124187.png

系统会选择一个单一的leader,为了防止提案人挂了,要轮换提案人

2PC不论有任何东西挂了,都不能提交

paxos只要不是大多数挂了,就能提交

replication 副本

数据不要放到一个节点上

  • replica configuration 副本设置
  • propagation scheme 数据传播的方案
  • propagation timing 数据传播的时机
  • update method 更新方案

replica configurations 副本配置

  • primary-replica

一个机器是主,另几个机器是备,备用可以only-read,主可以做写操作

  • multi-primary

多主,都可以读写操作,但是写操作要有方案处理

K-safety

保持多少副本量

同步给从的方案:

  • synchronous 同步方案

强一致性方案,保证用户的数据在从的数据库都有了,才能告诉用户ok了,用户等待时间是比较长的

  • asynchronous 异步方案

主库提交完成后直接发送给用户成功,然后给备库发送任务,当然会出现一些数据问题

折中一点,只要日志成功到备库上就告诉成功

propagation timing 数据传播时机

  • continuous 持续不断的传播

但是回滚要主备一起回滚

  • on commit

提交的时候传给备库,当然会有时间的开销

active & passive

  • active-active

传播的日志是逻辑日志,传输的是sql指令

  • active-passive

传播的是物理日志,传输的是数据

consistency(linearizablity 线性一致性) availability可用性 partition tolerant 分区容错性

image-20220308104806609.png

consistency:

两个集群根据网络连接起来,将其同步,越弱的一致性, 数据同步越慢

availbility:

备库挂了,与备库近的用户可以访问其他备库或主库来实现高可用

partition tolerance:

集群机器没挂,网络挂了,就会出现双主库,当网络不中断就能最后确认是什么

传统的数据库当网络分区挂了之后,我们会下线数据库,牺牲了可用性来保证CP

nosql数据库会在重连之后梳理

如果一个数据库想搞不同的数据库在一起,就可以搞(federated databases联邦数据库),当然不太好做,没有做的比较好的

数据库搞一个中间件给其他的不同数据库,postgreSQL可以连其他数据库

但是不考虑有骗子的情况




文章评论