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
如果有一个节点告诉说不行,要回滚,协调者会直接通知用户要回滚,自己告诉参与者回滚
优化:
early acknowledgement
当请求被所有参与者都同意的时候,直接给用户发送提交成功,然后再进行commit操作
问题:
如果协调者崩溃了,参与者自己决定怎么办,一般是直接回滚
参与者崩溃了怎么办,协调者就会认为参与者不同意这个事务
PAXOS
共识机制,大部分都同意了,那么不同意的也要同意
propooser 提案者
acceptor 参与者
提案者发现大多数同意了,提案通过,发给参与者,参与者完成之后发给用户成功,对于宕机的就等到他没事时让其强制执行
多个事务:拒接旧的事务,同意新的事务
系统会选择一个单一的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 分区容错性
consistency:
两个集群根据网络连接起来,将其同步,越弱的一致性, 数据同步越慢
availbility:
备库挂了,与备库近的用户可以访问其他备库或主库来实现高可用
partition tolerance:
集群机器没挂,网络挂了,就会出现双主库,当网络不中断就能最后确认是什么
传统的数据库当网络分区挂了之后,我们会下线数据库,牺牲了可用性来保证CP
nosql数据库会在重连之后梳理
如果一个数据库想搞不同的数据库在一起,就可以搞(federated databases联邦数据库),当然不太好做,没有做的比较好的
数据库搞一个中间件给其他的不同数据库,postgreSQL可以连其他数据库
但是不考虑有骗子的情况