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

 

雲數據庫 

 

 

數據庫是否能夠用通用格式存儲，這樣便於數據共享