共用方式為

在 Azure Cosmos DB for PostgreSQL 中選擇散發資料行

  • 發行項

適用於： Azure Cosmos DB for PostgreSQL (由 Citus 資料庫延伸模組支援 PostgreSQL)

選擇每個資料表的散發資料行是您要做的其中一個最重要的模型化決策。 Azure Cosmos DB for PostgreSQL 會根據資料列散發資料行的值，將資料列儲存於分區中。

正確的選擇會將相同實體節點上的相關資料群組在一起，讓查詢變得快速，並新增對所有 SQL 功能的支援。 不正確的選擇會讓系統執行變慢。

一般提示

以下是針對分散式資料表選擇理想散發資料行的四個準則。

  1. 挑選應用程式工作負載中心部分的資料行。

    您可以將此資料行視為用於分割資料的「心臟」、「中心部分」或「自然維度」。

    範例：

    • IoT 工作負載中的 device_id
    • security_id 適用於可追蹤證券的財務應用程式
    • 使用者分析中的 user_id
    • tenant_id 適用於多租用戶 SaaS 應用程式

  2. 挑選具有良好基數且平均統計分佈的資料行。

    此資料行應具有許多值，且徹底平均分佈於所有分區之間。

    範例：

    • 超過 1000 的基數
    • 請勿在大部分資料列上挑選具有相同值的資料行 (資料扭曲)
    • 在 SaaS 工作負載中，讓一個租用戶遠大於其餘租用戶，可能導致資料扭曲。 在此情況下，您可以使用租用戶隔離，建立專用分區來處理租用戶。

  3. 挑選可從您現有查詢受益的資料行。

    對於交易式或操作性工作負載 (其中大多數查詢只需花費數毫秒)，挑選會在至少 80% 查詢的 WHERE 子句中顯示為篩選的資料行。 例如，SELECT * FROM events WHERE device_id=1 中的 device_id 資料行。

    對於分析工作負載 (大部分查詢需要 1-2 秒)，挑選可讓查詢跨背景工作節點平行處理的資料行。 例如，經常出現在 GROUP BY 子句中的資料行，或一次查詢多個值。

  4. 挑選存在於大多數大型資料表中的資料行。

    超過 50 GB 的資料表應進行散發。 針對這些所有資料表挑選相同的散發資料行，可讓您在背景工作節點上共置該資料行的資料。 共置可讓您有效率地執行聯結和彙總，並強制執行外部索引鍵。

    其他 (較小型) 資料表可以是本機資料表或參考資料表。 如果較小型資料表需要與分散式資料表聯結，將它設為參考資料表。

使用案例範例

我們已看過適合用來挑選散發資料行的一般準則。 現在讓我們看看它們如何套用到常見使用案例。

多租用戶應用程式

多租用戶架構會使用階層式資料庫模型化的形式，在叢集的節點之間散發查詢。 資料階層的頂端稱為「租用戶識別碼」，而且必須儲存於每個資料表的資料行中。

Azure Cosmos DB for PostgreSQL 會檢查查詢，以查看其涉及的租用戶識別碼，並尋找相符的資料表分區。 它會將查詢路由傳送到包含分區的單一背景工作節點。 使用放置於相同節點上的所有相關資料執行查詢稱為共置。

下圖說明多租用戶資料模型中的共置。 其包含兩個資料表：Accounts (帳戶) 和 Campaigns (行銷活動)，每個資料表都由 account_id 散發。 陰影方塊代表分區。 綠色分區會一起儲存於一個背景工作節點上，而藍色分區會儲存於另一個背景工作節點上。 請注意，當 Accounts 與 Campaigns 資料表均限制為相同的 account_id 時，這兩個資料表之間的聯結查詢在一個節點上同時擁有所有必要資料的方式。

多租使用者共置

若要在您自己的結構描述中套用此設計，請識別應用程式中構成租用戶的內容。 常見的執行個體包括公司、帳戶、組織或客戶。 資料行名稱會類似 company_id 或 customer_id。 檢查每個查詢並詢問自己，如果有更多 WHERE 子句來將所有涉及的資料表限制為具有相同租用戶識別碼的資料列，是否可行？ 多租用戶模型中的查詢範圍會限定為一個租用戶。 例如，關於銷售或庫存的查詢範圍會限定於一家特定商店內。

最佳作法

  • 依通用 tenant_id 資料行散發資料表。 例如，在租用戶為公司的 SaaS 應用程式中，tenant_id 可能是 company_id。
  • 將小型跨租用戶資料表轉換成參考資料表。 當多個租用戶共用一個小型資訊資料表時，將它散發為參考資料表。
  • 限制依 tenant_id 篩選所有應用程式查詢。 每個查詢一次只能要求一個租用戶的資訊。

如需如何建置這類應用程式的範例，請閱讀多租用戶教學課程。

即時應用程式

多租用戶架構引進階層式結構，並使用資料共置來路由傳送每個租用戶的查詢。 相反地，即時架構會依據其資料的特定散發屬性來實現高度平行處理。

我們使用「實體識別碼」作為即時模型中散發資料行的詞彙。 一般實體是使用者、主機或裝置。

即時查詢通常要求依日期或類別分組的數值彙總。 Azure Cosmos DB for PostgreSQL 會將這些查詢傳送到每個分區以取得部分結果，並將協調器節點上的最終答案組合在一起。 有盡可能多的節點參與且沒有任何單一節點必須執行不成比例的工作量時，查詢執行速度最快。

最佳作法

  • 選擇具有高基數的資料行作為散發資料行。 為了進行比較，訂單資料表上的 [狀態] 欄位具有 [新增]、[付費] 和 [出貨] 值，對於散發資料行而言是個不良選擇。 它假設只有那幾個值，這會限制可保存資料的分區數目，以及可處理它的節點數目。 在具有高基數的資料行中，選擇經常在 GROUP BY 子句中使用或當成聯結索引鍵使用的資料行，也是個不錯的選擇。
  • 選擇平均散發的資料行。 如果您將資料表散發於偏移至特定通用值的資料行上，資料表中的資料往往會累積於特定分區中。 保留那些分區的節點最終會執行比其他節點更多的工作。
  • 在其通用資料行上散發事實和維度資料表。 事實資料表只能有一個散發索引鍵。 在另一個索引鍵上聯結的資料表將不會與事實資料表共置。 根據聯結頻率和聯結資料列的大小，選擇一個要共置的維度。
  • 將某些維度資料表變更為參考資料表。 如果維度資料表無法與事實資料表共置，您可以將維度資料表的複本散發到參考資料表格式的所有節點，以提高查詢效能。

如需如何建置這類應用程式的範例，請閱讀即時儀表板教學課程。

時間序列資料

在時間序列工作負載中，應用程式會在封存舊資訊時查詢最近資訊。

在 Azure Cosmos DB for PostgreSQL 中將時間序列資訊模型化時最常見的錯誤，就是使用時間戳記本身作為散發資料行。 以時間為基礎的雜湊散發看似會將時間隨機散發到不同分區，而不是將時間範圍一起保持在分區中。 涉及時間的查詢通常會參考時間範圍，例如最新資料。 這種類型的雜湊散發會導致網路額外負荷。

最佳作法

  • 請勿選擇時間戳記作為散發資料行。 選擇不同的散發資料行。 在多租用戶應用程式中使用租用戶識別碼，或在即時應用程式中使用實體識別碼。
  • 針對時間改用 PostgreSQL 資料表分割區。 使用資料表分割區，將依時間排序資料的大型資料表分成多個繼承的資料表，每個資料表都包含不同的時間範圍。 在 Azure Cosmos DB for PostgreSQL 中散發 Postgres 分割的資料表會為繼承的資料表建立分區。

下一步

  • 了解位於分散式資料之間的共置如何協助查詢快速執行。
  • 探索分散式資料表的散發資料行，以及其他有用的診斷查詢。