一文看懂分布式數(shù)據(jù)庫(kù)原理和 PostgreSQL 分布式架構(gòu)

作者：twt社區(qū) 2020-04-14 11:14:02

數(shù)據(jù)庫(kù)

其他數(shù)據(jù)庫(kù)

分布式

分布式

PostgreSQL 分布式系統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)原理(第三版)中的描述：“我們把分布式數(shù)據(jù)庫(kù)定義為一群分布在計(jì)算機(jī)網(wǎng)絡(luò)上、邏輯上相互關(guān)聯(lián)的數(shù)據(jù)庫(kù)。

公司主營(yíng)業(yè)務(wù)：成都做網(wǎng)站、網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶(hù)真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶(hù)帶來(lái)驚喜。創(chuàng)新互聯(lián)推出江城免費(fèi)做網(wǎng)站回饋大家。

 一、 什么是分布式數(shù)據(jù)庫(kù)

分布式系統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)原理(第三版)中的描述：“我們把分布式數(shù)據(jù)庫(kù)定義為一群分布在計(jì)算機(jī)網(wǎng)絡(luò)上、邏輯上相互關(guān)聯(lián)的數(shù)據(jù)庫(kù)。分布式數(shù)據(jù)庫(kù)管理系統(tǒng)(分布式DBMS)則是支持管理分布式數(shù)據(jù)庫(kù)的軟件系統(tǒng)，它使得分布對(duì)于用戶(hù)變得透明。有時(shí)，分布式數(shù)據(jù)庫(kù)系統(tǒng)(Distributed Database System,DDBS)用于表示分布式數(shù)據(jù)庫(kù)和分布式DBMS這兩者?！?/p>

[[322120]]

在以上表述中，“一群分布在網(wǎng)絡(luò)上、邏輯上相互關(guān)聯(lián)”是其要義。在物理上一群邏輯上相互關(guān)聯(lián)的數(shù)據(jù)庫(kù)可以分布式在一個(gè)或多個(gè)物理節(jié)點(diǎn)上。當(dāng)然，主要還是應(yīng)用在多個(gè)物理節(jié)點(diǎn)。這一方面是X86服務(wù)器性?xún)r(jià)比的提升有關(guān)，另一方面是因?yàn)榛ヂ?lián)網(wǎng)的發(fā)展帶來(lái)了高并發(fā)和海量數(shù)據(jù)處理的需求，原來(lái)的單物理服務(wù)器節(jié)點(diǎn)不足以滿(mǎn)足這個(gè)需求。

分布式不只是體現(xiàn)在數(shù)據(jù)庫(kù)領(lǐng)域，也與分布式存儲(chǔ)、分布式中間件、分布式網(wǎng)絡(luò)有著很多關(guān)聯(lián)。最終目的都是為了更好的服務(wù)于業(yè)務(wù)需求的變更。從哲學(xué)意義上理解是一種生產(chǎn)力的提升。

二、 分布式數(shù)據(jù)庫(kù)理論基礎(chǔ)

1. CAP理論

首先，分布式數(shù)據(jù)庫(kù)的技術(shù)理論是基于單節(jié)點(diǎn)關(guān)系數(shù)據(jù)庫(kù)的基本特性的繼承，主要涉及事務(wù)的ACID特性、事務(wù)日志的容災(zāi)恢復(fù)性、數(shù)據(jù)冗余的高可用性幾個(gè)要點(diǎn)。

其次，分布式數(shù)據(jù)的設(shè)計(jì)要遵循CAP定理，即：一個(gè)分布式系統(tǒng)不可能同時(shí)滿(mǎn)足 一致性( Consistency ) 、可用性 ( Availability ) 、分區(qū)容 忍 性 ( Partition tolerance ) 這三個(gè)基本需求，最 多只能同時(shí)滿(mǎn)足其中的兩項(xiàng)， 分區(qū)容錯(cuò)性 是不能放棄的，因此架構(gòu)師通常是在可用性和一致性之間權(quán)衡。這里的權(quán)衡不是簡(jiǎn)單的完全拋棄，而是考慮業(yè)務(wù)情況作出的犧牲，或者用互聯(lián)網(wǎng)的一個(gè)術(shù)語(yǔ)“降級(jí)”來(lái)描述。

針對(duì)CAP理論，查閱了國(guó)外的相關(guān)文檔表述，CAP理論來(lái)源于2002年麻省理工學(xué)院的Seth Gilbert和Nancy Lynch發(fā)表的關(guān)于Brewer猜想的正式證明。

 

CAP 三個(gè)特性描述如下 ：

一致性：確保分布式群集中的每個(gè)節(jié)點(diǎn)都返回相同的 、 最近 更新的數(shù)據(jù) 。一致性是指每個(gè)客戶(hù)端具有相同的數(shù)據(jù)視圖。有多種類(lèi)型的一致性模型 ， CAP中的一致性是指線(xiàn)性化或順序一致性，是強(qiáng)一致性。

可用性：每個(gè)非失敗節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回所有讀取和寫(xiě)入請(qǐng)求的響應(yīng)。為了可用，網(wǎng)絡(luò)分區(qū)兩側(cè)的每個(gè)節(jié)點(diǎn)必須能夠在合理的時(shí)間內(nèi)做出響應(yīng)。

分區(qū)容忍性：盡管存在網(wǎng)絡(luò)分區(qū)，系統(tǒng)仍可繼續(xù)運(yùn)行并 保證 一致性。網(wǎng)絡(luò)分區(qū)已成事實(shí)。保證分區(qū)容忍度的分布式系統(tǒng)可以在分區(qū)修復(fù)后從分區(qū)進(jìn)行適當(dāng)?shù)幕謴?fù)。

原文主要觀(guān)點(diǎn)有在強(qiáng)調(diào)CAP理論不能簡(jiǎn)單的理解為三選二。

 

在分布式數(shù)據(jù)庫(kù)管理系統(tǒng)中，分區(qū)容忍性是必須的。網(wǎng)絡(luò)分區(qū)和丟棄的消息已成事實(shí)，必須進(jìn)行適當(dāng)?shù)奶幚?。因此，系統(tǒng)設(shè)計(jì)人員必須在一致性和可用性之間進(jìn)行權(quán)衡 。簡(jiǎn)單地說(shuō)，網(wǎng)絡(luò)分區(qū)迫使設(shè)計(jì)人員選擇完美的一致性或完美的可用性。在給定情況下， 優(yōu)秀 的分布式系統(tǒng)會(huì)根據(jù)業(yè)務(wù)對(duì)一致性和可用性需求的重要等級(jí)提供最佳的答案，但通常一致性需求等級(jí)會(huì)更高，也是最有挑戰(zhàn)的 。

2. BASE理論

基于CAP定理的權(quán)衡，演進(jìn)出了 BASE理論 ，BASE是Basically Available(基本可用)、Soft state(軟狀態(tài))和Eventually consistent(最終一致性)三個(gè)短語(yǔ)的縮寫(xiě)。BASE理論的核心思想是：即使無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性。

BA：Basically Available 基本可用，分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，允許損失部分可用性，即保證核心可用。

s：soft State 軟狀態(tài)，允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。

E：Consistency 最終一致性，系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過(guò)一定時(shí)間后，最終能夠達(dá)到一致的狀態(tài)。

BASE 理論本質(zhì)上是對(duì) CAP 理論的延伸，是對(duì) CAP 中 AP 方案的一個(gè)補(bǔ)充。

這里補(bǔ)充說(shuō)明一下什么是強(qiáng)一致性：

Strict Consistency ( 強(qiáng)一致性 ) 也稱(chēng)為Atomic Consistency ( 原子一致性) 或 Linearizable Consistency(線(xiàn)性一致性) ，必須滿(mǎn)足以下 兩個(gè)要求：

1、任何一次讀都能讀到某個(gè)數(shù)據(jù)的最近一次寫(xiě)的數(shù)據(jù)。

2、系統(tǒng)中的所有進(jìn)程，看到的操作順序，都和全局時(shí)鐘下的順序一致。

對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過(guò)的數(shù)據(jù)能被后續(xù)的訪(fǎng)問(wèn)都能看到，這是強(qiáng)一致性。簡(jiǎn)言之，在任意時(shí)刻，所有節(jié)點(diǎn)中的數(shù)據(jù)是一樣的。

BASE 理論的最終一致性屬于弱一致性。

接下來(lái)介紹另一個(gè)分布式數(shù)據(jù)庫(kù)重要的概念：分布式事務(wù)。瀏覽了幾篇介紹分布式事務(wù)的文章，發(fā)現(xiàn)會(huì)有不同的描述，但大致含義是相同的。分布式事務(wù)首先是事務(wù)， 需要滿(mǎn)足事務(wù)的ACID的特性。主要考慮業(yè)務(wù)訪(fǎng)問(wèn)處理的數(shù)據(jù)分散在網(wǎng)絡(luò)間的多節(jié)點(diǎn)上，對(duì)于分布式數(shù)據(jù)庫(kù)系統(tǒng)而言， 在保證數(shù)據(jù)一致性的要求下，進(jìn)行事務(wù)的分發(fā)、協(xié)同多節(jié)點(diǎn)完成業(yè)務(wù)請(qǐng)求。

多節(jié)點(diǎn)能否正常、順利的協(xié)同作業(yè)完成事務(wù)是關(guān)鍵，它直接決定了訪(fǎng)問(wèn)數(shù)據(jù)的一致性和對(duì)請(qǐng)求響應(yīng)的及時(shí)性。從而就需要科學(xué)有效的一致性算法來(lái)支撐。

3. 一致性算法

目前主要的 一致性算法 包括 ：2PC 、 3pc 、 paxos 、 Raft 。

2PC ：Two-Phase Commit ( 二階段提交 ) 也被認(rèn)為是一種一致性協(xié)議，用來(lái)保證分布式系統(tǒng)數(shù)據(jù)的一致性。絕大部分的關(guān)系型數(shù)據(jù)庫(kù)都是采用二階段提交協(xié)議來(lái)完成分布式事務(wù)處理。

主要包括以下兩個(gè)階段：

第一階段：提交事務(wù)請(qǐng)求(投票階段)

第二階段：執(zhí)行事務(wù)提交(執(zhí)行階段)

優(yōu)點(diǎn)：原理簡(jiǎn)單、實(shí)現(xiàn)方便

缺點(diǎn)：同步阻塞、單點(diǎn)問(wèn)題、數(shù)據(jù)不一致、太過(guò)保守

3PC ：Three- Phase Commi ( 三階段提交 )包括 CanCommit、PreCommit、doCommit 三個(gè)階段。

為了避免在通知所有參與者提交事務(wù)時(shí)，其中一個(gè)參與者 crash 不一致時(shí)，就出現(xiàn)了三階段提交的方式。

三階段提交在兩階段提交的基礎(chǔ)上增加了一個(gè) preCommit 的過(guò)程，當(dāng)所有參與者收到 preCommit 后，并不執(zhí)行動(dòng)作，直到收到 commit 或超過(guò)一定時(shí)間后才完成操作。

優(yōu)點(diǎn)：降低參與者阻塞范圍，并能夠在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致 缺點(diǎn)：引入 preCommit 階段，在這個(gè)階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，協(xié)調(diào)者無(wú)法與參與者正常通信，參與者依然會(huì)進(jìn)行事務(wù)提交，造成數(shù)據(jù)不一致。

2PC / 3PC 協(xié)議用于保證屬于多個(gè)數(shù)據(jù)分片上操作的原子性。

這些數(shù)據(jù)分片可能分布在不同的服務(wù)器上，2PC / 3PC 協(xié)議保證多臺(tái)服務(wù)器上的操作要么全部成功，要么全部失敗。

Paxos 、 Raft 、 Zab 算法用于保證同一個(gè)數(shù)據(jù)分片的多個(gè)副本之間的數(shù)據(jù)一致性 。以下是三種算法的概要描述 。

Paxos 算法主要解決數(shù)據(jù)分片的單點(diǎn)問(wèn)題 ， 目的是讓整個(gè)集群的結(jié)點(diǎn)對(duì)某個(gè)值的變更達(dá)成一致。Paxos (強(qiáng)一致性) 屬于多數(shù)派算法 。任何一個(gè)點(diǎn)都可以提出要修改某個(gè)數(shù)據(jù)的提案，是否通過(guò)這個(gè)提案取決于這個(gè)集群中是否有超過(guò)半數(shù)的結(jié)點(diǎn)同意，所以 Paxos 算法需要集群中的結(jié)點(diǎn)是單數(shù) 。

Raft 算法是簡(jiǎn)化版的Paxos， Raft 劃分成三個(gè)子問(wèn)題：一是Leader Election;二是 Log Replication;三是Safety。Raft 定義了三種角色 Leader、Follower、Candidate，最開(kāi)始大家都是Follower，當(dāng)Follower監(jiān)聽(tīng)不到Leader，就可以自己成為Candidate，發(fā)起投票 ，選出新的leader 。

其有兩個(gè)基本過(guò)程：

① Leader選舉：每個(gè) C andidate隨機(jī)經(jīng)過(guò)一定時(shí)間都會(huì)提出選舉方案，最近階段中 得 票最多者被選為 L eader。

② 同步log：L eader會(huì)找到系統(tǒng)中l(wèi)og(各種事件的發(fā)生記錄)最新的記錄，并強(qiáng)制所有的follow來(lái)刷新到這個(gè)記錄。

Raft一致性算法是通過(guò)選出一個(gè)leader來(lái)簡(jiǎn)化日志副本的管理，例如，日志項(xiàng)(log entry)只允許從leader流向follower。ZAB基本與 raft 相同。

三、PostgreSQL 分布式架構(gòu)一覽

 

PostgreSQL發(fā)展時(shí)間線(xiàn)及分支圖

1. 基于內(nèi)核分布式方案 Postgres-XL

(1) 什么是Postgres-XL

Postgres-XL是一款開(kāi)源的PG集群軟件，XL代表eXtensible Lattice，即可擴(kuò)展的PG“格子”之意，以下簡(jiǎn)稱(chēng)PGXL。

官方稱(chēng)其既適合寫(xiě)操作壓力較大的OLTP應(yīng)用，又適合讀操作為主的大數(shù)據(jù)應(yīng)用。它的前身是Postgres-XC(簡(jiǎn)稱(chēng)PGXC)，PGXC是在PG的基礎(chǔ)上加入了集群功能，主要適用于OLTP應(yīng)用。PGXL是在PGXC的基礎(chǔ)上的升級(jí)產(chǎn)品，加入了一些適用于OLAP應(yīng)用的特性，如 Massively Parallel Processing (MPP) 特性。

通俗的說(shuō)PGXL的代碼是包含PG代碼，使用PGXL安裝PG集群并不需要單獨(dú)安裝PG。這樣帶來(lái)的一個(gè)問(wèn)題是無(wú)法隨意選擇任意版本的PG，好在PGXL跟進(jìn)PG較及時(shí)，目前最新版本Postgres-XL 10R1，基于PG 10。

社區(qū)發(fā)展史：

2004~2008 年， NTT Data 構(gòu)建了模型 Rita-DB

2009 年， NTT Data 與 EnterpriseDB 合作進(jìn)行社區(qū)化開(kāi)發(fā)

2012 年， Postgres-XC 1.0 正式發(fā)布

2012 年， StormDB 在 XC 基礎(chǔ)上增加 MPP 功能 .

2013 年， XC 1.1 發(fā)布 ;TransLattice 收購(gòu) StormDB

2014 年， XC 1.2 發(fā)布 ;StormDB 開(kāi)源為 Postgres-XL.

2015 年，兩個(gè)社區(qū)合并為 Postgres-X2

2016 年 2 月， Postgres-XL 9.5 R1

2017年7月 ， Postgres-XL 9.5 R1.6

2018年10月 ， Postgres-XL 10R1

2019 年 2 月 ， 宣布推出Postgres-XL 10R1 .1

 

PostgreSQL與PGXC對(duì)比圖(浙江移動(dòng)譚峰分享)

(2) 技術(shù)架構(gòu)

 

 

 

架構(gòu)圖1

從上圖可以看出Coordinator和datanode節(jié)點(diǎn)可以配置為多個(gè)，并且可以位于不同的主機(jī)上。只有Coordinator節(jié)點(diǎn)直接對(duì)應(yīng)用服務(wù)，Coordinator節(jié)點(diǎn)將數(shù)據(jù)分配存儲(chǔ)在多個(gè)數(shù)據(jù)節(jié)點(diǎn)datanode上。

Postgres-XC主要組件有g(shù)tm(Global Transaction Manager) ， gtm_standby ， gtm_proxy, Coordinator 和Datanode。

全局事務(wù)節(jié)點(diǎn) ( GTM )， 是Postgres-XC的核心組件，用于全局事務(wù)控制以及tuple的可見(jiàn)性控制。gtm 為分配GXID和管理PGXC MVCC的模塊 ， 在一個(gè)CLUSTER中只能有一臺(tái)主的gtm。gtm_standby 為gtm的備機(jī) 。

主要作用：

• – 生成全局唯一的事務(wù)ID
• – 全局的事務(wù)的狀態(tài)
• – 序列等全局信息

gtm_proxy為降低gtm壓力而誕生的, 用于對(duì)coordinator節(jié)點(diǎn)提交的任務(wù)進(jìn)行分組等操作. 機(jī)器中可以存在多個(gè)gtm_proxy。

協(xié)調(diào)節(jié)點(diǎn) (Coordinator) 是數(shù)據(jù)節(jié)點(diǎn) (Datanode) 與應(yīng)用之間的接口， 負(fù)責(zé)接收用戶(hù)請(qǐng)求、生成并執(zhí)行分布式查詢(xún)、 把 SQL 語(yǔ)句發(fā)給相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)。

Coordinator 節(jié)點(diǎn)并不物理上存儲(chǔ)表數(shù)據(jù)，表數(shù)據(jù)以分片或者復(fù)制的方式分布式存儲(chǔ)，表數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)節(jié)點(diǎn)上。當(dāng)應(yīng)用發(fā)起SQL時(shí)，會(huì)先到達(dá) Coordinator 節(jié)點(diǎn)，然后 Coordinator節(jié)點(diǎn)將 SQL分發(fā)到各個(gè)數(shù)據(jù)節(jié)點(diǎn)，匯總數(shù)據(jù)，這一系統(tǒng)過(guò)程是通過(guò)GXID 和Global Snapshot 再 來(lái)控制的。

數(shù)據(jù)節(jié)點(diǎn)(datanode)物理上存儲(chǔ)表數(shù)據(jù)，表數(shù)據(jù)存儲(chǔ)方式分為分片(distributed)和完全復(fù)制(replicated)兩種。數(shù)據(jù)節(jié)點(diǎn)只存儲(chǔ)本地的數(shù)據(jù)。

數(shù)據(jù)分布

? replicated table 復(fù)制表

– 表在多個(gè)節(jié)點(diǎn)復(fù)制

? distributed table 分布式表

– Hash

– Round robin

注釋?zhuān)篟ound robin 輪流放置是最簡(jiǎn)單的劃分方法：即每條元組都會(huì)被依次放置在下一個(gè)節(jié)點(diǎn)上，如下圖所示，以此進(jìn)行循環(huán)。

 

(3) 主要站點(diǎn)

Overview

https://wiki.postgresql.org/wiki/Postgres-XC

2. 擴(kuò)展分布式方案Citus

(1) 什么是Citus

Citus是一款基于PostgreSQL的開(kāi)源分布式數(shù)據(jù)庫(kù) ， 自動(dòng)繼承了PostgreSQL強(qiáng)大的SQL支持能力和應(yīng)用生態(tài)(不僅是客戶(hù)端協(xié)議的兼容還包括服務(wù)端擴(kuò)展和管理工具的完全兼容)。Citus是PostgreSQL的擴(kuò)展(not a fork)，采用shared nothing架構(gòu)，節(jié)點(diǎn)之間無(wú)共享數(shù)據(jù)，由協(xié)調(diào)器節(jié)點(diǎn)和Work節(jié)點(diǎn)構(gòu)成一個(gè)數(shù)據(jù)庫(kù)集群。專(zhuān)注于高性能HTAP分布式數(shù)據(jù)庫(kù) 。

相比單機(jī)PostgreSQL，Citus可以使用更多的CPU核心，更多的內(nèi)存數(shù)量，保存更多的數(shù)據(jù)。通過(guò)向集群添加節(jié)點(diǎn)，可以輕松的擴(kuò)展數(shù)據(jù)庫(kù)。

與其他類(lèi)似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL相比，Citus最大的不同在于它是一個(gè)PostgreSQL擴(kuò)展而不是一個(gè)獨(dú)立的代碼分支。Citus可以用很小的代價(jià)和更快的速度緊跟PostgreSQL的版本演進(jìn);同時(shí)又能最大程度的保證數(shù)據(jù)庫(kù)的穩(wěn)定性和兼容性。

Citus支持新版本PostgreSQL的特性，并保持與現(xiàn)有工具的兼容 。Citus使用分片和復(fù)制在多臺(tái)機(jī)器上橫向擴(kuò)展PostgreSQL。它的查詢(xún)引擎將在這些服務(wù)器上執(zhí)行SQL進(jìn)行并行化查詢(xún)，以便在大型數(shù)據(jù)集上實(shí)現(xiàn)實(shí)時(shí)(不到一秒)的響應(yīng)。

Citus目前主要分為以下幾個(gè)版本：

• Citus社區(qū)版
• Citus商業(yè)版
• Cloud [AWS，citus cloud]

 

本截圖引用2020年3月蘇寧陳華軍Citus的實(shí)踐分享

(2) 技術(shù)架構(gòu)

 

本截圖引用2020年3月蘇寧陳華軍Citus的實(shí)踐分享

Citus集群由一個(gè)中心的協(xié)調(diào)節(jié)點(diǎn)(CN)和若干個(gè)工作節(jié)點(diǎn)(Worker)構(gòu)成。

CN只存儲(chǔ)和數(shù)據(jù)分布相關(guān)的元數(shù)據(jù)，實(shí)際的表數(shù)據(jù)被分成M個(gè)分片，打散到N個(gè)Worker上。這樣的表被叫做“分片表”，可以為“分片表”的每一個(gè)分片創(chuàng)建多個(gè)副本，實(shí)現(xiàn)高可用和負(fù)載均衡。

 

架構(gòu)圖1(引用2019年蘇寧Citus實(shí)踐分享)

Citus官方文檔更建議使用PostgreSQL原生的流復(fù)制做HA，基于多副本的HA也許只適用于append only的分片。

應(yīng)用將查詢(xún)發(fā)送到協(xié)調(diào)器節(jié)點(diǎn)，協(xié)調(diào)器處理后發(fā)送至work節(jié)點(diǎn)。對(duì)于每個(gè)查詢(xún)協(xié)調(diào)器將其路由到單個(gè)work節(jié)點(diǎn)，或者并行化執(zhí)行，這取決于數(shù)據(jù)是否在單個(gè)節(jié)點(diǎn)上還是在多個(gè)節(jié)點(diǎn)上。Citus MX模式允許直接對(duì)work節(jié)點(diǎn)進(jìn)行訪(fǎng)問(wèn)，進(jìn)行更快的讀取和寫(xiě)入速度。

 

架構(gòu)圖2(引用2019年蘇寧Citus實(shí)踐分享)

Citus有三種類(lèi)型表

• 分片表(最常用)
• 參考表
• 本地表

分片表主要解決的是大表的水平擴(kuò)容問(wèn)題，對(duì)數(shù)據(jù)量不是特別大又經(jīng)常需要和分片表Join的維表可以采用一種特殊的分片策略，只分1個(gè)片且每個(gè)Worker上部署1個(gè)副本，這樣的表叫做“參考表”。

除了分片表和參考表，還剩下一種沒(méi)有經(jīng)過(guò)分片的PostgreSQL原生的表，被稱(chēng)為“本地表”。“本地表”適用于一些特殊的場(chǎng)景，比如高并發(fā)的小表查詢(xún)。

 

本截圖引用2020年3月蘇寧陳華軍Citus的實(shí)踐分享

客戶(hù)端應(yīng)用訪(fǎng)問(wèn)數(shù)據(jù)時(shí)只和CN節(jié)點(diǎn)交互。CN收到SQL請(qǐng)求后，生成分布式執(zhí)行計(jì)劃，并將各個(gè)子任務(wù)下發(fā)到相 應(yīng)的Worker節(jié)點(diǎn)，之后收集Worker的結(jié)果，經(jīng)過(guò)處理后返回最終結(jié)果給客戶(hù)端。

 

本截圖引用2020年3月蘇寧陳華軍Citus的實(shí)踐分享

(3) 主要站點(diǎn)

http://citusdb.cn/

https://docs.citusdata.com/en/v8.2/

四、 總結(jié)

應(yīng)對(duì)大數(shù)據(jù)量、高并發(fā)混合業(yè)務(wù)數(shù)據(jù)訪(fǎng)問(wèn)，數(shù)據(jù)管理需要分布式數(shù)據(jù)庫(kù)架構(gòu)的有效支撐，以下總結(jié)了幾個(gè)主要關(guān)鍵詞：

1. 業(yè)務(wù)融合——TP/AP業(yè)務(wù)自動(dòng)識(shí)別，職能調(diào)度運(yùn)算節(jié)點(diǎn);實(shí)時(shí)流處理;關(guān)系與非關(guān)系數(shù)據(jù)訪(fǎng)問(wèn)、轉(zhuǎn)換;

2. 節(jié)點(diǎn)協(xié)同——多個(gè)計(jì)算節(jié)點(diǎn)協(xié)同作業(yè);數(shù)據(jù)多副本;同城、異地多活;

3. 冷熱分離——定期定時(shí)統(tǒng)計(jì)，自動(dòng)標(biāo)記冷熱數(shù)據(jù)，根據(jù)存儲(chǔ)速度存儲(chǔ)不同冷熱程度的數(shù)據(jù);

4. 架構(gòu)解耦——微服務(wù)、計(jì)算存儲(chǔ)分離;

5. 彈性伸縮——在線(xiàn)伸縮;自動(dòng)平衡數(shù)據(jù);

6. 智能運(yùn)維——自動(dòng)調(diào)優(yōu);自動(dòng)升降級(jí);運(yùn)行可視化，自動(dòng)告警。

參考資料：

分布式數(shù)據(jù)庫(kù)概念：

·《分布式系統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)原理》(第三版)

CAP理論 ：

·《Understanding the CAP Theorem》/ Akhil Mehra

·《CAP和BASE理論》/ ~信~仰~

Base理論：

·《終于有人把“分布式事務(wù)”說(shuō)清楚了!》/ 陳明羽

·《強(qiáng)一致性、順序一致性、弱一致性和共識(shí)》/ chao2016

一致性算法：

·《分布式理論系列(二)一致性算法：2PC 到 3PC 到 Paxos 到 Raft 到 Zab》/ binarylei

·《Paxos和Raft快速理解》/ 建懷

PGXL

·《初識(shí)Postgres-XL》/ joyeu

Citus

· 博客“小橋河西 ”

·《PostgreSQL中的分庫(kù)分表解決方案》/ 唐成

 

網(wǎng)頁(yè)標(biāo)題：一文看懂分布式數(shù)據(jù)庫(kù)原理和PostgreSQL分布式架構(gòu)
文章位置：http://www.5511xx.com/article/cdieipg.html