Decision Support Systems(OLAP database的別名)

OLTP獲取資料，ELT將OLTP的資料Extract，Transform，Load合併成一個統一的模式，傳給OLAP
Decision support systems，分析資料，做出未來的決策

資料的架構有兩種：

Problem setup

star schema

star schema只有兩級的結構，一箇中心，延展開的其他節點是對fact table每一個維度的描述
會出現資訊冗餘，Denormalized，資料可能會出現一致性與完整性問題，也就是說如果資料不用外來鍵索引，那麼可能會出現一個數據多種表示方式

snowflake schema

snoflake 比 schmea需要的儲存空間更少，到那時需要更多的table join，所以執行query更慢

Execution Models(多節點上的執行模型)

Pushing a Query to Data

• 把query push或者query的一部分發送到各個節點
• 在相應的節點上執行儘可能多的過濾、預處理操作，將盡量少的資料通過網路傳輸返回
  
  上面的節點充當router，把query進行拆分

Pulling Data to Query

• 將資料移動到執行查詢的節點上，然後再執行查詢獲取結果
  

Query Fault Tolerance

將中間結果存到shared-disk？

cached in the buffer pool是指存到當前節點的快取吧？那麼存中間結果的快照才是存在shared-disk中？

Query Planning(多節點查詢優化)

分散式查詢優化還需要考慮資料的物理位置和network transfer cost

Physical Operators

把物理計劃切分成小塊，並分由各個節點去執行，在本地產生query plan分解成多個部分，發給不同的節點？

SQL

將原始的 SQL 語句按分片資訊重寫成多條 SQL 語句，每個節點自己在本地作查詢優化。AP 說他只見過 MemSQL 採用了這種方案，舉例如下：

Distributed Join Algorithms

對於之前的SQL語句

SELECT * FROM R JOIN S ON R.id = S.id

假設了R與S表中id相同範圍內的資料在一個節點上，這樣並不現實。要獲得R和S的join，我需要將join所需的資料移動到同一個節點上，之後便可以使用loop join，hash join等join策略

Scenario 1

如果S表非常小，那麼可以這樣做

Scenario 2

如果分割槽依賴的列是經常被連表的列，那麼這種做法容易實現

Scenario 3

這種分割槽依賴的列不是經常被連表的列，就需要兩個節點把S表資料全都放到一個節點
broadcasts

Scenario 4

臨時按照join key重新分割槽，這種開銷很大

semi-join

如果dbms不支援semi join，可以通過exist 偽造semi join。並且在分散式資料庫的情況下，可以只傳遞R.id,也就是join id來達到優化分散式join的校效果

Cloud Systems

DBaas，雲資料庫模糊了shard-nothing與shared-disk，因為雲端計算的發展，shared-nothing變得愈發少了，因為本地的硬碟可以是雲上的硬碟。雲服務可以先過濾資料，再傳送資料到計算節點

Managed DBMSs

一個執行在雲伺服器上的“雲”DBMS

Cloud-Native DBMS

雲原生DBMS，一般基於shared-disk架構

Serverless Databases

DBMS的底層page檔案一般都是私有的