IT系統及PostgreSQL的伸縮(垂直擴充套件&水平擴充套件)

一、分散式系統的垂直擴充套件和水平擴充套件

高併發

（

High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，透過設計保證系統能夠同時並行處理很多請求。提高系統併發能力的方式，方法論上主要有兩種：垂直擴充套件（Scale Up）與水平擴充套件（Scale Out）。

1 垂直擴充套件

：提升單機處理能力。垂直擴充套件的方式有：

增強單機硬體效能。如：升級CPU算力和核數，升級更好的網絡卡如萬兆，升級更好的硬碟如SSD，擴充硬碟如2T，擴充記憶體如128G；

提升單機架構效能。如：使用Cache來減少IO次數，使用非同步來增加單服務吞吐量，使用無鎖資料結構來減少響應時間；

優點

：

單機最佳化易於配置且維護和管理開銷最小，效能改善簡單快捷；

缺點

：

增強單機硬體的購置成本高，並且有可能效益不高；單機效能總是有極限的，所以網際網路分散式架構設計高併發的終極解決方案還是水平擴充套件。

2 水平擴充套件：

透過增加伺服器數量，從而線性擴充系統性能。水平擴充套件對系統架構設計是有要求的。

反向代理層的水平擴充套件：

是透過“DNS輪詢”實現的。dns-server對於一個域名配置了多個解析 ip，每次DNS解析請求來訪問 dns-server，會輪詢返回這些 ip。

當nginx成為瓶頸的時候，只要增加伺服器數量，新增 nginx 服務的部署，增加一個外網ip，就能擴充套件反向代理層的效能，做到理論上的無限高併發。

站點層的水平擴充套件

：是透過 nginx 實現的。透過修改nginx。conf，可以設定多個web後端。

當web後端成為瓶頸的時候，只要增加伺服器數量，新增web服務的部署，在nginx中配置上新的web後端，就能擴充套件站點層的效能，做到理論上的無限高併發。

服務層的水平擴充套件：

是透過“服務連線池“實現的。

站點層透過RPC-client呼叫下游的服務層RPC-server時，RPC-client中的連線池會建立與下游服務多個連線，當服務成為瓶頸的時候，只要增加伺服器數量，新增服務部署，在RPC-client處建立新的下游服務連線，就能擴充套件服務層效能，做到理論上的無限高併發。如果需要優雅的進行服務層自動擴容，這裡可能需要配置中心裡服務自動發現功能的支援。

資料層的水平擴充套件(快取、分庫、分表)

在資料量很大的情況下，資料層（快取，資料庫）涉及資料的水平擴充套件，將原本儲存在一臺伺服器上的資料（快取，資料庫）水平拆分到不同伺服器上去，以達到擴充系統性能的目的。通常涉及：分散式叢集、讀寫分離、讀擴充套件、寫擴充套件。

資料庫作為應用請求的終點，對整體效能的影響很大，以下重點介紹PostgreSQL的水平擴充套件。

二、PostgreSQL的垂直擴充套件和水平擴充套件

1 PG垂直擴充套件方案

單機伺服器系統垂直擴充套件的前提下，還可以對單機資料庫效能調優

［1］

：如：資料庫配置調優，調優vacuum的GC，透過 Analyze Explain 檢視執行計劃並調優SQL，建立索引，單表分割槽，單庫分表；

2 PG水平擴充套件方案

Pgpool II(一主多備，讀、寫分離，讀擴充套件)

PgPool II 是客戶端應用程式和PostgreSQL叢集之間的中介軟體產品。Pgpool II透過負載平衡，將寫入傳送到主節點，並在備節點之間平衡讀取語句，來提供水平可伸縮性。Pgpool II提供連線級別和語句級別的負載平衡；連線級別的負載平衡 Pgpool II 程序與備節點建立連線，該連線的所有讀取均傳送到備節點，而寫入則傳送到主節點。使用語句級連線（Pgpool II 4。1中提供），每個語句在備節點上實現負載均衡。

基於PG宣告式分割槽的分片

分片是基於PG宣告式分割槽的。

PG宣告式分割槽：在PG10中首次釋出；在宣告性分割槽之前，PG 使用表繼承 和 plpgsql 觸發器提供表分割槽。

直接使用宣告式分割槽，可以將位於一個數據伺服器上的一個主表拆分出多個子分割槽；插入主表中的行都將基於分割槽鍵被路由到所屬分割槽中。

PG11 對宣告性分割槽的效能進行了許多改進，包括分割槽修剪。

分割槽修剪：

是基於 WHERE 謂詞提供的，旨在排除無關分割槽，將查詢直接路由到特定分割槽。

分片：是一種在一個或多個外部伺服器上，對錶進行分割槽的能力。透過宣告式分割槽可以將主表拆分為位於同一資料庫伺服器上的多個分割槽表。分片允許對錶進行分割槽，並使分割槽子表位於外部外部伺服器上，而主表位於使用者建立分片父表的主節點上。分片表中使用的所有外部伺服器都是PostgreSQL外部伺服器，不支援其他異構外部伺服器，如MongoDB，MySQL等。

——在主伺服器上，建立主表

CREATE

TABLE

measurement

（

city_id

int

not

null

，

logdate

date

not

null

，

peaktemp

int

，

unitsales

int

）

PARTITION

BY

RANGE

（

logdate

）；

——遠端伺服器上（shard_1），建立一個分割槽表（結構與主表相同）

CREATE

TABLE

measurement_year2019

（

city_id

int

not

null

，

logdate

date

not

null

，

peaktemp

int

，

unitsales

int

）

；

——在主伺服器上，給主表繫結外部伺服器上的子分割槽表

CREATE

TABLE

measurement_year2019

PARTITION

OF

measurement

FOR

VALUES

FROM

（

‘2019-01-01’

）

TO

（

‘2020-01-01’

）

Server

shard_1

；

基於FDW的內建分片技術

PG內建分片功能使用基於FDW的方法，而FDW基於SQL/ MED規範，該規範定義瞭如何從PG伺服器訪問外部資料來源。

PG提供了許多用於訪問外部資料來源的外部資料封裝器（FDW）：

postgres_

fdw 用於訪問在外部伺服器上執行的Postgres資料庫；

oracle

_fdw用於從PG訪問Oracle資料庫；

mysql_fdw 用於從PG訪問MySQL資料庫；

mongodb_fdw用於訪問MongoDB等。

當前存在的一些問題和挑戰

［2］

1. 用於FDW的兩階段提交

當前，FDW事務不支援兩階段提交，這意味著，如果在一個事務中使用多個外部伺服器，並且一部分事務在一臺外部伺服器中失敗，則所有外部事務上的整個事務都將失敗。為了保證整個資料庫群集中的資料一致性，此功能是必需的。

為了支援OLTP工作負載，此功能是必需的，因此對於分片功能非常重要。

此功能的設計建議和補丁已經發送給hackers 好幾年了，但是社群對此沒有足夠的興趣，儘管該功能的設計仍然非常出色。

2.並行外部掃描

當一個查詢在單個查詢中查詢多個外部掃描時，所有外部掃描都以一種連續的方式依次執行。並行外部掃描功能正在並行執行多個外部掃描。此功能對於OLAP測試用例確實非常重要，例如，如果您正在對被劃分為大量分割槽的大型分割槽表上執行AVG查詢。AVG操作將順序傳送到每個外部伺服器，每個外部伺服器的結果將傳送到父節點，該父節點將在父節點上聚合併發送回客戶端。一旦有了並行foriegn掃描功能，所有外部伺服器上的所有平均操作都將並行執行，並將結果傳送到父節點。

這是完成分片功能所需的關鍵部分，我們目前具有聚合下推功能，可以將聚合向下傳送到外部伺服器，但是我們沒有在所有分割槽上並行執行聚合操作的功能。

對於OLAP用例而言，此功能特別重要，擁有大量外部伺服器（包含用於大型分割槽表的分割槽）以及在並行運行於所有外部伺服器分割槽上的聚合操作的想法非常大。

並行外部掃描功能的基礎結構是非同步查詢執行，這是PostgreSQL中的一個重大更改。在此方面已經完成了一些工作，但是感覺它仍需一個或兩個發行版。一旦非同步查詢執行完成，新增並行外部掃描功能將變得更加容易。

3. 分片管理

當前不會自動在外部伺服器上建立分割槽，需要在外部伺服器上手動建立分割槽。如果要建立具有大量分割槽和子分割槽的分割槽表，這可能是非常繁瑣的任務。

假定分片管理功能提供了在外部伺服器上自動建立分割槽和子分割槽的功能。這將使分片表的建立非常容易。

不打算討論如何實現此功能的任何設計細節，其基本思想是，分片表語法將建立在宣告性分片語法的基礎上。postgres_fdw將用於將DDL下推到外部伺服器，而FDW僅用於執行SELECT或DML，而在外部源上執行DDL則不是sql/med規範的一部分。

4. 全域性事務管理器/快照管理器

這是分片功能所必需的另一個非常重要且困難的功能。假定全域性事務/快照管理器的目的是提供全域性事務一致性。本章第1節“用於外部資料包裝器事務的2PC”中描述的問題也與全域性事務管理器有關。

假設您有兩個正在使用分片表的併發客戶端，客戶端1 試圖訪問伺服器1上的分割槽，客戶端2也試圖訪問伺服器1上的分割槽。客戶端2分割槽的一致檢視，即客戶端2不應在客戶端1事務中看到對該分割槽所做的任何更改（即更新等）。客戶端2提交事務後，所有新事務都將看到更新。全域性事務管理器假設要確保所有全域性事務都能獲得資料庫叢集的一致檢視。使用資料庫群集的所有併發客戶端（具有在多個外部伺服器上分表的表）應該看到資料庫群集的一致檢視。

這是很難解決的問題，像Postgres Professional這樣的公司已經嘗試透過使用外部事務管理器來解決此問題。到目前為止，社群似乎還沒有接受任何解決方案。目前，沒有明顯的集中精力嘗試在核心或在外部元件中實現全域性事務管理器。

其他方法，例如Clock-SI（分割槽表的快照隔離）方法，或借鑑其他成功案例（例如谷歌cloud spanner和YugaByte）來解決同一問題。

基於分散式中介軟體：

ShardingSphere-Proxy：

資料庫與應用程式中間的中介軟體，獨立部署代理；

ShardingSphere-JDBC：

jdbc 層的分散式分庫分表中介軟體，需要在應用程式程式碼中引入；

參考

^https：//www。jdon。com/51929

^https：//mp。weixin。qq。com/s/IAPghS0UqV4Na2_tsCxvVw