分布式数据库
并行数据库与分布式数据库
parallel DBMS 并行数据库
- 多节点的数据库,但是节点都在同一个机房
- 通过高速局域网实现
- 通信开销很小
distributed DBMS 分布式数据库
- 节点之间是通过互联网链接的
由于分布式数据库的特殊情况,所以有几个方面要特殊设计
- optimization & planning
- concurrency control
- logging & recovery
内容:
- system architectures 系统架构
- design issues 设计问题
- partitioning schemes 数据分区方案
- distributed concurrency control 分布式并发控制
system architectures 系统架构
多个节点在同一个机器,shared everything
内存与硬盘是集中的,但是cpu通过网络连接起来shared memory
同上,分享硬盘,shared disk
什么也不分享shared nothing
shared memory
共享内存与硬盘,cpu通信只能通过网络,基本上没有
shared disk
不用关心disk,就好像是一个大硬盘,能够增加计算能力
将存储集群与计算集群分开了
查询很简单,用谁都可以,但是更新就有缓存同步的问题,刷入其他节点(其他节点有老旧的数据)
shared nothing
坏处就是没办法独立扩容,数据一致性更难做了,提高了扫盘速度
如果数据不在这个节点就要去别的节点找,扩容需要数据重分布
design issues 设计问题
homogenous & heterogenous
homogenous 均一的,一致的节点
heterogenous 非均一的
heterogenous monogodb
每一个节点负责的功能是不一样的
data transparency 数据透明
不要让用户知道数据在哪里,也不用让用户去关心这个问题
把数据切开分配在不同的节点上
partitioning :
- naive table partitioning
按表进行分区,但是很明显就有很多问题,当然最喜欢操作就是查询一个表的内容,不做多表操作
- horizontal partitioning 水平分区
把表切开,去不同的节点,把某一列(partitionKey)以某个标准进行分区
问题就是如果查询带partitionKey,那就很简单,但是如果不带,那就要去所有的数据库去查询
consistent hashing
做一个圈,将占比作为长度表示,当想加时,找那个最长的,劈开,送给新的
到最后存储副本页可以让三个存,存的时候就能放到旁边的数据库
但是如果是shared disk,那就是逻辑上进行分区
shared nothing 就是物理上分区
TP monitors 远程监听器
有一个集中的协调器(coordinator),只能他来加锁和解锁
优化,搞一个中间件(middleware)中间件记录加锁,解锁,分区配置,但其实本质是一个单点的数据库
decentralized coordinator 分散协调器
搞一个主节点,主节点去考虑是不是安全的
distributed concurrency control
多节点并发控制
可以使用单节点的原理,但是有些问题要考虑
- replication 副本 节点内容修改了,副本内容怎么修改
- network communication overhead 互联网的开销
- node failures 节点挂了怎么办
- clock skew 系统时钟是不同步怎么办