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

云数据库

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