CMU Database Systems - Distributed OLTP & OLAP

OLTP

scale-up和scale-out

scale-up会有上限，没法不断up，并且相对而言，up升级会比较麻烦，因此大数据，云计算须要scale-out

scale-out，就是分布式数据库，刚开始确定是Shared Nothing，可是分布式也引入了更高的架构复杂度和维护成本

因此如今的趋势，是架构分层，层之间是逻辑的scale-up，层内部是物理的scale-out

最终sharing-everything，其实在架构上又回到了scale-up

因此随着硬件的进步和技术的演进，架构上没有绝对的好坏

Shared Nothing是最多见的，也是最开始的分布式方案

共享磁盘，表明是Amazon的Aurora

执行层和存储层分离，那么当前在数据库层就不须要管副本同步的问题，主挂了，备拉起看到的数据仍是同样的，在数据库层只有一份磁盘数据

共享内存，共享磁盘虽然解决大部分数据同步的问题，可是执行层仍然是有状态的，由于内存中的状态，并无落盘，因此failover后仍然须要状态恢复

若是共享内存，那么执行层就能够彻底无状态，那样维护成本会大幅下降

可是很明显，共享内存很难实现，稳定性和性能的要求会很高，如今没有数据库实现共享内存

 

早期的分布式数据库，

分布式数据库设计须要考虑一些架构上的问题，

同构仍是异构，Mongo是典型的异构架构

 

数据Partition，既然是分布式数据库，数据确定是要分开放的，怎么分？

能够按照Table分，明显这样扩展性不太好，若是Table太大会有问题

比较天然的方式，是水平划分，如右图

 

 Partition还分为，逻辑的和物理的，若是是逻辑的，只是扩展数据库处理能力

 

 中心化，仍是去中心化

 

中心化实现简单，可是单点问题，扩展和failover，典型表明，Bigtable

非中心化，实现复杂，一致性很难保证，更优雅 

 

分布式一致性，是分布式数据库中最困难的问题

能够看到简单的分布式2PL很容易形成死锁

 

 分布式一致性的经常使用方法以下，

2PL分为两个阶段，准备和提交；2PL的最大问题就是活性，任意一个节点挂都会致使失败

 

 

Early acknowledgement，Prepare都成功后，直接给client返回成功，不用等commit阶段结束

 

Paxos，简单的理解为，majority版本的2PL 

 

副本机制用于解决单点问题，因此多存几份

副本最大的问题就是同步问题

 

主备或多主，两种状况

 

副本间同步策略，

同步，主备都是落盘

异步，主落盘

半异步，主落盘，备收到数据，未落盘

  

 

 

持续同步，或是commit的时候同步

基本都采用持续同步 

 

 

Active，主进程主动同时写多个副本

Passive，主进程只写主副本，其余须要同步进程进行被动同步

CAP理论 ，3选二

 

一致性，一旦commit，从每一个副本上读到的数据是同样的

可用性，挂掉一个副本仍然可读写

分区容错，分区间失联(多是挂了，也有多是因为网络致使脑裂)，那么这种状况下须要选择，

选可用性，以下图，你能够脑裂的状况下，继续写，可是数据就不一致了

选一致性，根据不一样的策略，判断是否可写，好比传统2PC只能等，Paxos要求多数可写

 

 

OLAP

传统OLAP是个数仓概念，

经过ETL把TP中的数据同步到数仓

数据的存储结构，主要分为两种，

星型和雪花型

Star，只有一层维表，而雪花会有多层维表

维表少，说明非范式化，那么查询比较简单，一层join；可是存储空间比较大，并且修改比较麻烦，可是对于AP这不是大问题

Agenda 

 

Execution Models

分红，push，pull

如今其实能push都是尽可能push的，哪怕不能整条push，也会部分谓词，Join push down

这样再pull上必须的数据进行后续计算

下降计算节点的压力，也下降数据的网络传输量

 

 

对于分布式AP，查询计划也须要打散，两种方式

一种是算子方式，大部分系统都是这么设计的

另外一种是Sql的方式，通常中间件会采用这样的方式

 以Sql为形式打散的例子，

 

分布式Join算法

1. 小表广播

2. join key等于分区key

3. 把原先没有广播的小表，进行广播

4. 全shuffle

 

云数据库 

 

 

数据库是否能够用通用格式存储，这样便于数据共享