確定應(yīng)用程序類型

在 Citus 集群上運(yùn)行高效查詢要求數(shù)據(jù)在機(jī)器之間正確分布。這因應(yīng)用程序類型及其查詢模式而異。

大致上有兩種應(yīng)用程序在 Citus 上運(yùn)行良好。數(shù)據(jù)建模的第一步是確定哪些應(yīng)用程序類型更接近您的應(yīng)用程序。

概覽

示例和特征

多租戶應(yīng)用

這些通常是為其他公司、帳戶或組織服務(wù)的 SaaS 應(yīng)用程序。大多數(shù) SaaS 應(yīng)用程序本質(zhì)上是關(guān)系型的。它們具有跨節(jié)點(diǎn)分布數(shù)據(jù)的自然維度：只需按 tenant_id 分片。

Citus 使您能夠?qū)?shù)據(jù)庫擴(kuò)展到數(shù)百萬租戶，而無需重新構(gòu)建應(yīng)用程序。您可以保留所需的關(guān)系語義，例如 聯(lián)接、外鍵約束、事務(wù)、ACID 和一致性。

• 示例：為其他企業(yè)托管店面的網(wǎng)站，例如數(shù)字營銷解決方案或銷售自動化工具。
• 特征：與單個租戶相關(guān)的查詢，而不是跨租戶加入信息。這包括為 Web 客戶端提供服務(wù)的 OLTP 工作負(fù)載，以及為每個租戶提供分析查詢的 OLAP 工作負(fù)載。在您的數(shù)據(jù)庫模式中擁有數(shù)十或數(shù)百個表也是多租戶數(shù)據(jù)模型的一個指標(biāo)。

使用 Citus 擴(kuò)展多租戶應(yīng)用程序還需要對應(yīng)用程序代碼進(jìn)行最少的更改。我們支持流行的框架，如 Ruby on Rails 和 Django。

實時分析應(yīng)用

需要大規(guī)模并行性、協(xié)調(diào)數(shù)百個內(nèi)核以快速獲得數(shù)值、統(tǒng)計或計數(shù)查詢結(jié)果的應(yīng)用程序。通過跨多個節(jié)點(diǎn)對 SQL 查詢進(jìn)行分片和并行化，Citus 可以在一秒鐘內(nèi)對數(shù)十億條記錄執(zhí)行實時查詢。

示例: 需要亞秒級響應(yīng)時間的面向客戶的分析儀表板。

特征: 幾張表，通常以設(shè)備、站點(diǎn)或用戶事件的大表為中心，并且需要大量攝取大部分不可變的數(shù)據(jù)。涉及多個聚合和 GROUP BY 的相對簡單(但計算量大)的分析查詢。

如果您的情況類似于上述任何一種情況，那么下一步就是決定如何在 Citus 集群中對數(shù)據(jù)進(jìn)行分片。如概念部分所述，Citus 根據(jù)表分布列的哈希值將表行分配給分片。數(shù)據(jù)庫管理員對分布列的選擇需要與典型查詢的訪問模式相匹配，以確保性能。

選擇分布列

Citus 使用分布式表中的分布列將表行分配給分片。為每個表選擇分布列是最重要的建模決策之一，因為它決定了數(shù)據(jù)如何跨節(jié)點(diǎn)分布。

如果正確選擇了分布列，那么相關(guān)數(shù)據(jù)將在相同的物理節(jié)點(diǎn)上組合在一起，從而使查詢快速并添加對所有 SQL 功能的支持。如果列選擇不正確，系統(tǒng)將不必要地緩慢運(yùn)行，并且無法支持跨節(jié)點(diǎn)的所有 SQL 功能。

本節(jié)提供兩種最常見的 Citus 方案的分布列提示。最后，它深入探討了 共置(co-location)，即節(jié)點(diǎn)上理想的數(shù)據(jù)分組。

多租戶應(yīng)用

多租戶架構(gòu)使用一種分層數(shù)據(jù)庫建模形式在分布式集群中的節(jié)點(diǎn)之間分布查詢。數(shù)據(jù)層次結(jié)構(gòu)的頂部稱為 tenant id，需要存儲在每個表的列中。Citus 檢查查詢以查看它們涉及的 tenant id，并將查詢路由到單個 worker 節(jié)點(diǎn)進(jìn)行處理，特別是保存與 tenant id 關(guān)聯(lián)的數(shù)據(jù)分片的節(jié)點(diǎn)。運(yùn)行將所有相關(guān)數(shù)據(jù)放置在同一節(jié)點(diǎn)上的查詢稱為 Table Co-Location。

下圖說明了多租戶數(shù)據(jù)模型中的共置(co-location)。它包含兩個表，Accounts 和 Campaigns，每個表都由 account_id 分配。陰影框代表分片，每個分片的顏色代表哪個 worker 節(jié)點(diǎn)包含它。綠色分片一起存儲在一個 worker 節(jié)點(diǎn)上，藍(lán)色分片存儲在另一個節(jié)點(diǎn)上。請注意，當(dāng)將兩個表限制為相同的 account_id 時，Accounts 和 Campaigns 之間的 join 查詢?nèi)绾螌⑺斜匾臄?shù)據(jù)放在一個節(jié)點(diǎn)上。

要在您自己的 schema 中應(yīng)用此設(shè)計，第一步是確定在您的應(yīng)用程序中構(gòu)成租戶的內(nèi)容。常見實例包括公司(company)、帳戶(account)、組織(organization)或客戶(customer)。列名稱類似于 company_id 或 customer_id。檢查您的每個查詢并問自己：如果它有額外的 WHERE 子句將所有涉及的表限制為具有相同 tenant id 的行，它會起作用嗎?多租戶模型中的查詢通常以租戶為范圍，例如銷售或庫存查詢將在某個商店內(nèi)進(jìn)行。

最佳實踐

按公共 tenant_id 列對分布式表進(jìn)行分區(qū)。 例如，在租戶是公司的 SaaS 應(yīng)用程序中，tenant_id 可能是 company_id。

將小型跨租戶表轉(zhuǎn)換為引用表。 當(dāng)多個租戶共享一個小信息表時，將其作為參考表分布。

限制按 tenant_id 過濾所有應(yīng)用程序查詢。 每個查詢應(yīng)一次請求一個租戶的信息。

閱讀多租戶應(yīng)用程序指南，了解構(gòu)建此類應(yīng)用程序的詳細(xì)示例。

實時應(yīng)用

雖然多租戶架構(gòu)引入了分層結(jié)構(gòu)并使用數(shù)據(jù)共置(data co-location)來路由每個租戶的查詢，但實時架構(gòu)依賴于其數(shù)據(jù)的特定分布屬性來實現(xiàn)高度并行處理。

我們在實時模型中使 “entity id” 作為分布列的術(shù)語，而不是多租戶模型中的租戶 ID。典型的實體是用戶(users)、主機(jī)(hosts)或設(shè)備(devices)。

實時查詢通常要求按日期(date)或類別(category)分組的數(shù)字聚合。Citus 將這些查詢發(fā)送到每個分片以獲得部分結(jié)果，并在 coordinator 節(jié)點(diǎn)上組裝最終答案。當(dāng)盡可能多的節(jié)點(diǎn)做出貢獻(xiàn)并且沒有單個節(jié)點(diǎn)必須做不成比例的工作時，查詢運(yùn)行速度最快。

最佳實踐

• 選擇具有高基數(shù)的列作為分布列。 為了比較，訂單表上的 status 字段具有 新(new)、已付款(paid) 和 已發(fā)貨(shipped) 值，是分布列的一個糟糕選擇，因為它只假設(shè)這幾個值。不同值的數(shù)量限制了可以保存數(shù)據(jù)的分片數(shù)量以及可以處理數(shù)據(jù)的節(jié)點(diǎn)數(shù)量。在具有高基數(shù)的列中，最好另外選擇那些經(jīng)常用于 group-by 子句或作為 join 鍵的列。
• 選擇分布均勻的列。 如果您將表分布在偏向某些常見值的列上，則表中的數(shù)據(jù)將傾向于在某些分片中累積。持有這些分片的節(jié)點(diǎn)最終會比其他節(jié)點(diǎn)做更多的工作。
• 將事實表和維度表分布在它們的公共列上。 您的事實表只能有一個分布 key。在另一個 key 上 join 的表不會與事實表位于同一位置。根據(jù) join 的頻率和 join 行的大小，選擇一個維度來共同定位。
• 將一些維度表更改為引用表。 如果維度表不能與事實表共存，您可以通過將維度表的副本以引用表的形式分發(fā)到所有節(jié)點(diǎn)來提高查詢性能。

閱讀實時儀表板指南，了解構(gòu)建此類應(yīng)用程序的詳細(xì)示例。

時間序列數(shù)據(jù)

在時間序列工作負(fù)載中，應(yīng)用程序在歸檔舊信息的同時查詢最近的信息。

在 Citus 中建模時間序列信息的最常見錯誤是將時間戳本身用作分布列。基于時間的散列分布將看似隨機(jī)的時間分布到不同的分片中，而不是將時間范圍保持在分片中。但是，涉及時間的查詢通常會參考時間范圍(例如最近的數(shù)據(jù))，因此這樣的哈希分布會導(dǎo)致網(wǎng)絡(luò)開銷。

最佳實踐

不要選擇時間戳作為分布列。 選擇不同的分布列。在多租戶應(yīng)用程序中，使用租戶 ID，或在實時應(yīng)用程序中使用實體 ID。

改為使用 PostgreSQL 表分區(qū)。 使用表分區(qū)將一個按時間排序的數(shù)據(jù)大表分解為多個繼承表，每個表包含不同的時間范圍。在 Citus 中分發(fā) Postgres 分區(qū)的表會為繼承的表創(chuàng)建分片。

閱讀 Timeseries Data 指南，了解構(gòu)建此類應(yīng)用程序的詳細(xì)示例。

表共置

關(guān)系數(shù)據(jù)庫因其巨大的靈活性和可靠性而成為許多應(yīng)用程序的首選數(shù)據(jù)存儲。從歷史上看，對關(guān)系數(shù)據(jù)庫的一個批評是它們只能在一臺機(jī)器上運(yùn)行，當(dāng)數(shù)據(jù)存儲需要超過服務(wù)器改進(jìn)時，這會產(chǎn)生固有的限制?？焖贁U(kuò)展數(shù)據(jù)庫的解決方案是分發(fā)它們，但這會產(chǎn)生其自身的性能問題：join 等關(guān)系操作需要跨越網(wǎng)絡(luò)邊界。共置(Co-location) 是一種策略性地劃分?jǐn)?shù)據(jù)的做法，將相關(guān)信息保存在同一臺機(jī)器上以實現(xiàn)高效的關(guān)系操作，但利用整個數(shù)據(jù)集的水平可擴(kuò)展性。

數(shù)據(jù)共存的原理是數(shù)據(jù)庫中的所有表都有一個共同的分布列，并以相同的方式跨機(jī)器分片，使得具有相同分布列值的行總是在同一臺機(jī)器上，即使跨不同的表也是如此。只要分布列提供了有意義的數(shù)據(jù)分組，就可以在組內(nèi)執(zhí)行關(guān)系操作。

Citus 中用于 hash 分布表的數(shù)據(jù)共存

PostgreSQL 的 Citus 擴(kuò)展在能夠形成數(shù)據(jù)庫的分布式數(shù)據(jù)庫方面是獨(dú)一無二的。Citus 集群中的每個節(jié)點(diǎn)都是一個功能齊全的 PostgreSQL 數(shù)據(jù)庫，Citus 在頂部添加了單個同構(gòu)數(shù)據(jù)庫的體驗。雖然它沒有以分布式方式提供 PostgreSQL 的全部功能，但在許多情況下，它可以通過托管在單臺機(jī)器上充分利用 PostgreSQL 提供的功能，包括完整的 SQL 支持、事務(wù)和外鍵。

在 Citus 中，如果分布列中值的哈希值落在分片的哈希范圍內(nèi)，則將一行存儲在分片中。為了確保共置，即使在重新平衡操作之后，具有相同哈希范圍的分片也始終放置在同一個節(jié)點(diǎn)上，這樣相等的分布列值始終位于跨表的同一個節(jié)點(diǎn)上。

我們發(fā)現(xiàn)在實踐中運(yùn)行良好的分布列是多租戶應(yīng)用程序中的租戶 ID。例如，SaaS 應(yīng)用程序通常有許多租戶，但它們所做的每個查詢都是特定于特定租戶的。雖然一種選擇是為每個租戶提供 database 或 schema，但它通常成本高昂且不切實際，因為可能有許多跨用戶的操作(數(shù)據(jù)加載、遷移、聚合、分析、schema 更改、備份等)。隨著租戶數(shù)量的增加，這變得更難管理。

共置的實際示例

考慮以下表格，這些表格可能是多租戶 Web 分析SaaS 的一部分：

CREATE TABLE event (
  tenant_id int,
  event_id bigint,
  page_id int,
  payload jsonb,
  primary key (tenant_id, event_id)
);

CREATE TABLE page (
  tenant_id int,
  page_id int,
  path text,
  primary key (tenant_id, page_id)
);

現(xiàn)在我們要回答可能由面向客戶的儀表板發(fā)出的查詢，例如：“返回租戶六中所有以‘/blog’開頭的頁面在過去一周的訪問次數(shù)?！?/p>

使用常規(guī) PostgreSQL 表

如果我們的數(shù)據(jù)位于單個 PostgreSQL 節(jié)點(diǎn)中，我們可以使用 SQL 提供的豐富的關(guān)系操作集輕松地表達(dá)我們的查詢：

SELECT page_id, count(event_id)
FROM
  page
LEFT JOIN  (
  SELECT * FROM event
  WHERE (payload->>'time')::timestamptz >= now() - interval '1 week'
) recent
USING (tenant_id, page_id)
WHERE tenant_id = 6 AND path LIKE '/blog%'
GROUP BY page_id;

只要此查詢的工作集適合內(nèi)存，這是許多應(yīng)用程序的合適解決方案，因為它提供了最大的靈活性。但是，即使您還不需要擴(kuò)展，考慮擴(kuò)展數(shù)據(jù)模型的影響也會很有用。

按 ID 分布表

隨著租戶數(shù)量和為每個租戶存儲的數(shù)據(jù)的增長，查詢時間通常會增加，因為工作集不再適合內(nèi)存或 CPU 成為瓶頸。在這種情況下，我們可以使用 Citus 跨多個節(jié)點(diǎn)分片數(shù)據(jù)。分片時我們需要做出的第一個也是最重要的選擇是分布列。讓我們從一個天真的選擇開始，將 event_id 用于事件表，將 page_id 用于頁表：

-- naively use event_id and page_id as distribution columns

SELECT create_distributed_table('event', 'event_id');
SELECT create_distributed_table('page', 'page_id');

鑒于數(shù)據(jù)分散在不同的 worker 中，我們不能像在單個 PostgreSQL 節(jié)點(diǎn)上那樣簡單地執(zhí)行 join。相反，我們需要發(fā)出兩個查詢：

跨頁表的所有分片(Q1)：

SELECT page_id FROM page WHERE path LIKE '/blog%' AND tenant_id = 6;

跨事件表的所有分片(Q2)：

SELECT page_id, count(*) AS count
FROM event
WHERE page_id IN (/*…page IDs from first query…*/)
  AND tenant_id = 6
  AND (payload->>'time')::date >= now() - interval '1 week'
GROUP BY page_id ORDER BY count DESC LIMIT 10;

之后，應(yīng)用程序需要組合這兩個步驟的結(jié)果。

回答查詢所需的數(shù)據(jù)分散在不同節(jié)點(diǎn)上的分片中，每個分片都需要被查詢：

在這種情況下，數(shù)據(jù)分布會產(chǎn)生很大的缺陷：

• 查詢每個分片的開銷，運(yùn)行多個查詢
• Q1 的開銷返回許多行給客戶端
• Q2 變得非常大
• 需要在多個步驟中編寫查詢，組合結(jié)果，需要在應(yīng)用程序中進(jìn)行更改

相關(guān)數(shù)據(jù)分散的一個潛在好處是查詢可以并行化，Citus 會這樣做。但是，這只有在查詢的工作量遠(yuǎn)遠(yuǎn)大于查詢許多分片的開銷時才有用。通常最好避免直接從應(yīng)用程序中進(jìn)行如此繁重的工作，例如通過預(yù)先聚合數(shù)據(jù)。

按租戶分布表

再次查看我們的查詢，我們可以看到查詢需要的所有行都有一個共同的維度：tenant_id。儀表板只會查詢租戶自己的數(shù)據(jù)。這意味著，如果同一租戶的數(shù)據(jù)始終位于單個 PostgreSQL 節(jié)點(diǎn)上，那么我們的原始查詢可以由該節(jié)點(diǎn)通過對 tenant_id 和 page_id 執(zhí)行 join 來一次性回答。

在 Citus 中，具有相同分布列值的行保證在同一個節(jié)點(diǎn)上。分布式表中的每個分片實際上都有一組來自其他分布式表的位于同一位置的分片，這些分片包含相同的分布列值(同一租戶的數(shù)據(jù))。從頭開始，我們可以創(chuàng)建以 tenant_id 作為分布列的表。

-- co-locate tables by using a common distribution column
SELECT create_distributed_table('event', 'tenant_id');
SELECT create_distributed_table('page', 'tenant_id', colocate_with => 'event');

在這種情況下，Citus 可以回答您將在單個 PostgreSQL 節(jié)點(diǎn)上運(yùn)行而無需修改 (Q1) 的相同查詢：

SELECT page_id, count(event_id)
FROM
  page
LEFT JOIN  (
  SELECT * FROM event
  WHERE (payload->>'time')::timestamptz >= now() - interval '1 week'
) recent
USING (tenant_id, page_id)
WHERE tenant_id = 6 AND path LIKE '/blog%'
GROUP BY page_id;

由于使用了 tenantid 過濾器和 tenantid 上的 join，Citus 知道可以使用包含特定租戶數(shù)據(jù)的一組位于同一位置的分片來回答整個查詢，而 PostgreSQL 節(jié)點(diǎn)可以在一個步驟中回答該查詢，從而支持完整的 SQL 支持。

在某些情況下，查詢和表 schema 需要進(jìn)行少量修改，以確保 tenant_id 始終包含在唯一約束和 join 條件中。但是，這通常是一個簡單的更改，并且避免了在沒有共置的情況下所需的大量重寫。

雖然上面的示例只查詢一個節(jié)點(diǎn)，因為有一個特定的 tenant_id = 6 過濾器，但共置還允許我們在所有節(jié)點(diǎn)上有效地執(zhí)行對 tenant_id 的分布式 join，盡管存在 SQL 限制。

共置意味著更好的功能支持

Citus 通過共置解鎖的功能的完整列表如下：

• 對一組位于同一位置的分片上的查詢的完整 SQL 支持
• 多語句事務(wù)支持對一組位于同一位置的分片進(jìn)行修改
• 通過 INSERT..SELECT 聚合
• 外鍵
• 分布式外部聯(lián)接(outer join)
• Pushdown CTEs(要求 PostgreSQL >=12 )

數(shù)據(jù)共置是一種強(qiáng)大的技術(shù)，可以為關(guān)系數(shù)據(jù)模型提供水平擴(kuò)展和支持。使用分布式數(shù)據(jù)庫遷移或構(gòu)建應(yīng)用程序的成本(通過共置實現(xiàn)關(guān)系操作)通常大大低于遷移到限制性數(shù)據(jù)模型(例如 NoSQL)的成本，并且與單節(jié)點(diǎn)數(shù)據(jù)庫不同，它可以隨著規(guī)模的大小而橫向擴(kuò)展您的業(yè)務(wù)。有關(guān)遷移現(xiàn)有數(shù)據(jù)庫的更多信息，請參閱過渡到多租戶數(shù)據(jù)模型。

查詢性能

Citus 通過將傳入查詢分解為多個在工作分片上并行運(yùn)行的片段查詢(“任務(wù)”)來并行化傳入查詢。這使 Citus 可以利用集群中所有節(jié)點(diǎn)的處理能力以及每個節(jié)點(diǎn)上的單個核心的處理能力來進(jìn)行每個查詢。由于這種并行化，您可以獲得集群中所有核心的計算能力的累積性能，與單個服務(wù)器上的 PostgreSQL 相比，查詢時間顯著減少。

Citus 在規(guī)劃 SQL 查詢時采用了兩階段優(yōu)化器。第一階段涉及將 SQL 查詢轉(zhuǎn)換為它們的交換和關(guān)聯(lián)形式，以便它們可以下推并在工作線程上并行運(yùn)行。如前幾節(jié)所述，選擇正確的分布列和分布方法允許分布式查詢規(guī)劃器對查詢應(yīng)用多種優(yōu)化。由于網(wǎng)絡(luò) I/O 減少，這會對查詢性能產(chǎn)生重大影響。

Citus 的分布式執(zhí)行器然后將這些單獨(dú)的查詢片段發(fā)送到 PostgreSQL worker 實例。分布式規(guī)劃器和執(zhí)行器都有幾個方面可以調(diào)整以提高性能。當(dāng)這些單獨(dú)的查詢片段被發(fā)送給 worker 時，查詢優(yōu)化的第二階段就開始了。worker 只是運(yùn)行擴(kuò)展的 PostgreSQL 服務(wù)器，他們應(yīng)用 PostgreSQL 的標(biāo)準(zhǔn)計劃和執(zhí)行邏輯來運(yùn)行這些片段 SQL 查詢。因此，任何有助于 PostgreSQL 的優(yōu)化也有助于 Citus。PostgreSQL 默認(rèn)帶有保守的資源設(shè)置;因此優(yōu)化這些配置設(shè)置可以顯著縮短查詢時間。

我們在文檔的查詢性能調(diào)優(yōu)部分討論了相關(guān)的性能調(diào)優(yōu)步驟。