確定應(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ù)庫(kù)擴(kuò)展到數(shù)百萬租戶，而無需重新構(gòu)建應(yīng)用程序。您可以保留所需的關(guān)系語義，例如 聯(lián)接、外鍵約束、事務(wù)、ACID 和一致性。

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

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

實(shí)時(shí)分析應(yīng)用

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

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

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

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

選擇分布列

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

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

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

多租戶應(yīng)用

多租戶架構(gòu)使用一種分層數(shù)據(jù)庫(kù)建模形式在分布式集群中的節(jié)點(diǎn)之間分布查詢。數(shù)據(jù)層次結(jié)構(gòu)的頂部稱為 tenant id，需要存儲(chǔ)在每個(gè)表的列中。Citus 檢查查詢以查看它們涉及的 tenant id，并將查詢路由到單個(gè) 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)。它包含兩個(gè)表，Accounts 和 Campaigns，每個(gè)表都由 account_id 分配。陰影框代表分片，每個(gè)分片的顏色代表哪個(gè) worker 節(jié)點(diǎn)包含它。綠色分片一起存儲(chǔ)在一個(gè) worker 節(jié)點(diǎn)上，藍(lán)色分片存儲(chǔ)在另一個(gè)節(jié)點(diǎn)上。請(qǐng)注意，當(dāng)將兩個(gè)表限制為相同的 account_id 時(shí)，Accounts 和 Campaigns 之間的 join 查詢?nèi)绾螌⑺斜匾臄?shù)據(jù)放在一個(gè)節(jié)點(diǎn)上。

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

最佳實(shí)踐

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

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

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

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

實(shí)時(shí)應(yīng)用

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

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

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

最佳實(shí)踐

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

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

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

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

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

最佳實(shí)踐

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

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

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

表共置

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

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

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

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

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

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

共置的實(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’開頭的頁(yè)面在過去一周的訪問次數(shù)?！?/p>

使用常規(guī) PostgreSQL 表

如果我們的數(shù)據(jù)位于單個(gè) 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)用程序的合適解決方案，因?yàn)樗峁┝俗畲蟮撵`活性。但是，即使您還不需要擴(kuò)展，考慮擴(kuò)展數(shù)據(jù)模型的影響也會(huì)很有用。

按 ID 分布表

隨著租戶數(shù)量和為每個(gè)租戶存儲(chǔ)的數(shù)據(jù)的增長(zhǎng)，查詢時(shí)間通常會(huì)增加，因?yàn)楣ぷ骷辉龠m合內(nèi)存或 CPU 成為瓶頸。在這種情況下，我們可以使用 Citus 跨多個(gè)節(jié)點(diǎn)分片數(shù)據(jù)。分片時(shí)我們需要做出的第一個(gè)也是最重要的選擇是分布列。讓我們從一個(gè)天真的選擇開始，將 event_id 用于事件表，將 page_id 用于頁(yè)表：

-- 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 中，我們不能像在單個(gè) PostgreSQL 節(jié)點(diǎn)上那樣簡(jiǎn)單地執(zhí)行 join。相反，我們需要發(fā)出兩個(gè)查詢：

跨頁(yè)表的所有分片(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)用程序需要組合這兩個(gè)步驟的結(jié)果。

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

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

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

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

按租戶分布表

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

在 Citus 中，具有相同分布列值的行保證在同一個(gè)節(jié)點(diǎn)上。分布式表中的每個(gè)分片實(shí)際上都有一組來自其他分布式表的位于同一位置的分片，這些分片包含相同的分布列值(同一租戶的數(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 可以回答您將在單個(gè) 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ù)的一組位于同一位置的分片來回答整個(gè)查詢，而 PostgreSQL 節(jié)點(diǎn)可以在一個(gè)步驟中回答該查詢，從而支持完整的 SQL 支持。

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

雖然上面的示例只查詢一個(gè)節(jié)點(diǎn)，因?yàn)橛幸粋€(gè)特定的 tenant_id = 6 過濾器，但共置還允許我們?cè)谒泄?jié)點(diǎn)上有效地執(zhí)行對(duì) tenant_id 的分布式 join，盡管存在 SQL 限制。

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

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

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

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

查詢性能

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

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

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

我們?cè)谖臋n的查詢性能調(diào)優(yōu)部分討論了相關(guān)的性能調(diào)優(yōu)步驟。