Azure Cosmos DB for PostgreSQL 中的節點和資料表

發行項
08/15/2024

適用於： Azure Cosmos DB for PostgreSQL (由 PostgreSQL 的超大規模 (Citus) 資料庫延伸模組提供)

節點

Azure Cosmos DB for PostgreSQL 可讓 PostgreSQL伺服器 (稱為節點) 在「不共用任何項目」架構中彼此協調。叢集中的節點會集體保留更多資料，並使用較單一伺服器所可能更多的 CPU 核心。該結構也會透過對叢集新增更多節點來允許調整資料庫規模。

協調員和背景工作角色

每個叢集都有一個協調員節點和多個背景工作角色。應用程式會將查詢傳送到協調員節點，而這個節點會將其轉送到相關背景工作角色，並累計其結果。

Azure Cosmos DB for PostgreSQL 可讓資料庫管理員散發資料表及/或結構描述，將不同的資料列儲存在不同的背景工作角色節點上。分散式資料表及/或結構描述是 Azure Cosmos DB for PostgreSQL 效能的關鍵。無法散發資料表及/或結構描述會使它們完全留在協調員節點上，而且無法利用跨機器平行處理原則。

對於分散式資料表上的每個查詢，協調員會將其路由傳送至單一背景工作角色節點，或跨數個節點將其平行處理，取決於所需的資料位於單一節點還是多個節點中。使用結構描述型分區化，協調員會將查詢直接路由傳送至裝載結構描述的節點。在結構描述型分區化和資料列式分區化中，協調員都會藉由參考中繼資料表來決定該怎麼做。這些資料表會追蹤背景工作角色節點的 DNS 名稱和健康情況，以及跨節點的資料散發情況。

資料表類型

叢集裡有五個類型的資料表，每一種都會以不同方式儲存在節點上，以及用於不同的用途。

類型 1：分散式資料表

第一個類型和最常見的類型是分散式資料表。這些資料表似乎是 SQL 陳述式的一般資料表，但會在背景工作角色節點之間水平分割。這表示資料表的資料列會儲存在不同的節點上，而在片段資料表中則稱為分區。

Azure Cosmos DB for PostgreSQL 不僅會執行 SQL，還會在整個叢集中執行 DDL 陳述式。變更分散式資料表串聯的結構描述，以更新背景工作角色的所有資料表分區。

散發資料行

Azure Cosmos DB for PostgreSQL 會使用演算法分區化，將資料列指派給分區。指派會根據稱為散發資料行的資料表資料行值，以決定性方式進行。叢集管理員必須在散發資料表時指定此資料行。對於效能和功能而言，做出正確的選擇很重要。

類型 2：參考資料表

參考資料表是分散式資料表的類型，其整個內容都會集中到單一分區。分區會在每個背景工作角色上進行複寫。任何背景工作角色的查詢都可以在本機存取參考資訊，而不需要向另一個節點要求資料列的網路額外負荷。參考資料表沒有散發資料行，因為不需要區分每個資料列的個別分區。

參考資料表通常很小，且會用來儲存與任何背景工作角色節點上所執行查詢相關的資料。例如，列舉值 (如訂單狀態或產品類別)。

類型 3：本機資料表

使用 Azure Cosmos DB for PostgreSQL 時，您所連線的協調員節點是一般 PostgreSQL 資料庫。您可以在協調員上建立一般資料表，並選擇不要將這些資料表分區化。

本機資料表的絕佳候選項目是未參與聯結查詢的小型系統管理資料表。例如，應用程式登入和驗證的 users 資料表。

類型 4：本機受控資料表

如果本機資料表與參考資料表之間有外部索引鍵參考存在，Azure Cosmos DB for PostgreSQL 可能會自動將本機資料表新增至中繼資料。此外，您可以對一般本機資料表執行 create_reference_table citus_add_local_table_to_metadata 函式，手動建立本機受控資料表。中繼資料中存在的資料表會被視為受控資料表，而且可以從任何節點查詢，Citus 知道要路由至協調員，以從本機受控資料表取得資料。這類資料表會在 citus_tables 檢視中顯示為本機。

類型 5：結構描述資料表

在 Citus 12.0 中引進結構描述型分區化之後，分散式結構描述會自動與個別共置群組產生關聯。在這些結構描述中建立的資料表會自動轉換成沒有分區索引鍵的共置分散式資料表。這類資料表被視為結構描述資料表，而且會在 citus_tables 檢視中顯示為結構描述。

分區

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

協調員上的 pg_dist_shard 中繼資料資料表包含系統中每個分散式資料表每個分區的資料列。資料列會比對分區識別碼與雜湊空間中的整數範圍 (shardminvalue、shardmaxvalue)。

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 │
└─────────┴───────────┴──────────┘

下一步

判斷應用程式的類型以準備資料模型化
使用實用的診斷查詢來檢查分區和放置。

共用方式為