共用方式為


Azure PostgreSQL 資料庫中的彈性叢集

適用於 PostgreSQL 的 Azure 資料庫服務上的彈性叢集是開放原始碼超大規模 (Citus) 延伸模組的受控供應項目,可啟用 PostgreSQL 的水平分區化。

雖然 Citus 只是延伸模組,但它會連線多個 PostgreSQL 執行個體。 使用 Citus 部署適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時,它會將多個 PostgreSQL 執行個體的管理和設定處理為單一資源。 它也會自動設定節點,並讓超大規模 (Citus) 延伸模組知道這些節點。

服務上的彈性叢集提供兩種分區模型:資料列型分區和結構描述型分區。 如果您想要深入了解,請查看關於分區化模型的開放原始碼文件。

架構

彈性叢集是由一或多個 Azure Database for PostgreSQL 彈性伺服器實例的節點所組成。 這些執行個體會自動彼此知會,並相互連線以形成超大規模 (Citus) 叢集。 節點必須是相同的計算和儲存層,而且可以一致地相應增加或減少至較高或較低層。

彈性叢集會使用彈性伺服器 (稱為節點) 的執行個體,在「無共用」結構中彼此協調。 此架構也可藉由將更多節點新增至叢集,讓資料庫進行調整。

使用連接埠 5432 連線到叢集,會將您放在指定的協調器節點上。 如果您使用埠 7432 進行連線,彈性叢集也可讓您使用五元組哈希方法來平衡整個叢集的連線負載。 使用 7432,您仍然可以降落在目前指定為協調器的節點。 針對某些叢集範圍的作業,例如散發資料表,您可能需要透過連接埠 5432 連線。 當您打算執行應用程式結構描述升級和類似的變更時,強烈建議您一律在連接埠 5432 上連線。 如果您在彈性叢集上 啟用 PgBouncer ,您可以使用埠 8432,在每個節點上的 PgBouncer 實例之間負載平衡連線(或使用埠 6432 做為指定的協調器)。

不同於適用於 PostgreSQL 的 Cosmos DB,節點位址不會在外部公開。 如果您查看超大規模 (Citus) 中繼資料表,如 pg_dist_node,您可能會注意到所有節點的 IP 位址與範例 10.7.0.254 相同,但連接埠號碼不同。

select nodeid, nodename, nodeport from pg_dist_node;
 nodeid |  nodename  | nodeport
--------+------------+----------
      1 | 10.7.0.254 |     7000
      2 | 10.7.0.254 |     7001
 
(2 rows)

在 Azure 的基礎結構中,這些節點會存在於不同的虛擬機器上,即使它們可能看似同一部機器上的不同埠。

若要深入了解超大規模 (Citus),您可以參考官方開放原始碼專案文件

根據預設,使用超大規模 (Citus) 建立的資料表和結構描述不會在叢集之間自動散發。 您必須決定分區化模型,並決定散發結構描述,或決定使用以資料列型的分區化來散發資料表資料。

針對分散式資料表上的每個查詢,查詢的節點會將其路由傳送至單一節點,或將其平行處理到數個節點。 決策取決於所需的資料是否位於單一節點或多個節點上。 使用結構描述型分區化,協調員會將查詢直接路由傳送至裝載結構描述的節點。 在這兩者中,結構描述型分區化和資料列型分區化,節點會藉由諮詢中繼資料表來決定該怎麼做。 這些資料表會追蹤節點的位置和健康情況,以及跨節點的資料分佈。

使用其中一個分區化模型散發資料后,您可以連線到任何節點來執行 DML (資料修改語言) 作業 (SELECT、UPDATE、INSERT、DELETE)。 所有節點都包含尋找查詢所需資料需要的中繼資料,而且能夠取得它來回應查詢。

DDL (資料定義語言) 作業和叢集範圍作業目前僅限於擁有協調器角色的節點。 請務必連線到連接埠 5432,而不是使用連接埠 7432 來執行 DDL 和全叢集作業。

您可以透過新增節點和重新平衡資料來擴展彈性叢集。 重新平衡是線上作業,不會封鎖執行中的工作負載。

分區

上一節說明如何將分散式資料表儲存為背景工作角色節點上的分區。 本節討論這些分區的其他技術詳細資料。

pg_dist_shard 中繼資料資料表包含系統中每個分散式資料表之每個分區的資料列。 資料列會比對分區識別碼 (shardid) 與雜湊空間中的整數範圍 (shardminvalueshardmaxvalue)。

SELECT * from pg_dist_shard;
logicalrelid  | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
 github_events |  102026 | t            | 268435456     | 402653183
 github_events |  102027 | t            | 402653184     | 536870911
 github_events |  102028 | t            | 536870912     | 671088639
 github_events |  102029 | t            | 671088640     | 805306367
 
 (4 rows)

如果節點想要判斷哪一個分區保存的 github_events 資料列,它會雜湊資料列中散發資料行的值。 然後節點會檢查哪個分區的範圍包含哈希值。 定義範圍,使雜湊函式的映像為其脫離聯合。

分區放置

假設分區 102027 與有問題的資料列相關聯。 資料列是在其中一個背景工作角色中稱為 github_events_102027 的資料表中讀取或寫入。 使用儲存在中繼資料表中的資訊,擴充功能會決定該特定背景工作角色的內容。 分區與背景工作角色的對應稱為分區放置。

節點會將查詢重寫成參考特定資料表的片段,例如 github_events_102027,並在適當的背景工作角色上執行這些片段。 以下是在幕後執行的查詢範例,以尋找具有識別碼 102027 之分區的節點。

SELECT
    shardid,
    node.nodename,
    node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
  ON placement.groupid = node.groupid
 AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;
┌─────────┬───────────┬──────────┐
│ shardid │ nodename  │ nodeport │
├─────────┼───────────┼──────────┤
│  102027 │ localhost │     5433 │
└─────────┴───────────┴──────────┘