HTAP資料庫(OLTP+OLAP)-資料庫典型架構優缺點剖析(shardVSshared)

標籤

PostgreSQL , 共享分散式儲存 , 儲存計算能力。

---

背景

隨著網際網路的發展，資料爆炸性的增長，資料庫逐漸成為了很多業務的絆腳石，很多業務也哭著喊著要上分散式資料庫（個人認為大部分是高估了自己的業務）。

分散式資料庫又分很多流派，比如重點要說的sharding和共享分散式儲存的架構，它們有著什麼樣的優缺點呢？

sharding vs 共享分散式儲存 資料庫架構

如果要在單機並行能力的前提下，再實現多機器並行，可以有兩種玩法：

第一種玩法，可以帶其他產品一起玩，用PostgreSQL 10+的fdw+append parallel+繼承+pushdown(join,agg,where,sort,…)+merge sort，可以實現對任意產品的多機並行（比如後端可以是MySQL）。

第二種玩法，更加的先進，節點間不僅共享資料，而且能直接通訊，每個節點運算資料的一部分(至少需要改進優化器實現這個功能)，多機並行，任意表任意欄位JOIN，多階段聚合等都能上陣，簡單來說就是具備MPP的能力。

citus有這樣的潛質，當然需要適配共享儲存架構進行改造。

點評

1、作為OLTP業務，使用sharding帶來的問題較多，有點得不償失。

1、1. 擴容不方便（資料重分佈）

1、2. 分佈鍵變更很麻煩

1、3. 分佈鍵選擇（架構設計）謹慎

1、4. 跨庫JOIN效能差，甚至只能按分佈鍵JOIN，其他欄位不支援JOIN。（因為這種產品架構資料節點之間是孤島，資料需要在孤島之間互動，需要通過上層的中介軟體節點，而這樣的話，如果有跨庫JOIN，就需要將資料收到中介軟體節點再JOIN，效能差是可想而知的。）

1、5. 分散式事務效能差，甚至不支援分散式事務。

1、6. SQL限制多、功能缺失多

1、7. 應用改造成本巨大

1、8. 全域性一致性時間點恢復幾乎不可實現

2、作為OLAP業務，如果使用sharding(MPP)架構，是值得的，可以充分利用多機的計算能力、IO能力，提高處理吞吐，例如阿里雲的HybridDB for PG。

而如果使用中介軟體的sharding形態，則不適合OLAP業務。(原因是節點間不支援互通，在AP中有大量的JOIN需求，節點間不同帶來一個問題，JOIN需要將資料匯聚到中介軟體節點執行，導致非常慢，幾乎不可用)

HDB PG是MPP形態的產品，計算節點之間可以相互通訊，任意列的JOIN都不存在問題，同時還支援行列混合，多階聚合的功能，是專門為OLAP場景打造的一款PB級分散式分析資料庫。

《阿里雲HybridDB for PostgreSQL實踐 – 多階聚合》

阿里雲的HybridDB for PG

HDB PG支撐了很多海量分析的業務場景。

3、作為HTAP(oltp+olap)業務，使用共享分散式儲存，一寫多讀的架構，是目前最先進的架構。

3、1. 例項擴容方便（秒級新增只讀節點）

3、2. 儲存擴容方便（幾乎無限擴充套件IO、頻寬）

3、3. 不存在分佈鍵問題

3、4. 不存在跨庫JOIN問題

3、5. 不存在分散式事務問題

3、6. SQL沒有任何限制

3、7. 應用無需改造

3、8. 支援全域性一致性時間點恢復

3、9. 只讀節點延遲毫秒內

3、10. 所有節點都支援平行計算

3、11. 分散式儲存：儲存和引擎分離後，儲存可以專心支援多副本，支援跨域容災，支援高頻寬，支援幾乎無限的擴容能力。同時與資料庫引擎深度結合，支援硬體級計算、加解密、加解壓、資料過濾、型別預處理等能力。大幅度降低資料傳輸和上層處理的壓力。

目前阿里雲推出的PolarDB正是這種架構，已支援MySQL協議，正在支援PostgreSQL協議(PostgreSQL具備了先天的優勢（向量計算、平行計算、JIT、雜湊聚合、擴充套件列存、繼承、等一系列特性），勢必成為HTAP的頂尖產品)。