607
汽車大全
HTAP數據庫(OLTP+OLAP) - 數據庫典型架構 優缺點剖析(shard VS shared)
標簽
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實踐 - 多階聚合》
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的頂尖產品)。
最後更新：2017-10-28 23:34:19