Citus 分布式 PostgreSQL 集群 – SQL Reference(SQL支持和变通方案)

由于 Citus 通过扩展 PostgreSQL 提供分布式功能,因此它与 PostgreSQL 结构兼容。这意味着用户可以使用丰富且可扩展的 PostgreSQL 生态系统附带的工具和功能来处理使用 Citus 创建的分布式表。

Citus 对它能够在单个工作节点上执行的任何查询具有 100% 的 SQL 覆盖率。在访问有关单个租户的信息时,此类查询在多租户应用程序中很常见。

  • https://docs.citusdata.com/en/v11.0-beta/use_cases/multi_tenant.html#mt-use-case

甚至跨节点查询(用于并行计算)也支持大多数 SQL 功能。但是,组合来自多个节点的信息的查询不支持某些 SQL 功能。

跨节点 SQL 查询的限制:

  • SELECT … FOR UPDATE 仅适用于单分片查询

https://www.postgresql.org/docs/current/static/sql-select.html#SQL-FOR-UPDATE-SHARE

  • TABLESAMPLE 仅适用于单分片查询

https://www.postgresql.org/docs/current/static/sql-select.html#SQL-FROM

  • 关联子查询仅当关联在分布列上时才受支持。

https://docs.citusdata.com/en/v11.0-beta/get_started/concepts.html#dist-column

  • 分布式表之间的外连接仅在分布列上受支持。

https://docs.citusdata.com/en/v11.0-beta/get_started/concepts.html#dist-column

  • 仅当分布式表在外侧时,才支持分布式表和引用表或本地表之间的外连接
  • 递归 CTE 仅适用于单分片查询

https://www.postgresql.org/docs/current/static/queries-with.html#idm46428713247840

  • 分组集仅适用于单分片查询

https://www.postgresql.org/docs/current/static/queries-table-expressions.html#QUERIES-GROUPING-SETS

要了解有关 PostgreSQL 及其功能的更多信息,您可以访问 PostgreSQL 文档。有关 PostgreSQL SQL 命令方言(可供 Citus 用户按原样使用)的详细参考,您可以查看 SQL 命令参考。

http://www.postgresql.org/docs/current/static/index.html

http://www.postgresql.org/docs/current/static/sql-commands.html

变通方案

在尝试变通方案之前,请考虑 Citus 是否适合您的情况。Citus 当前版本适用于实时分析和多租户用例。

  • https://docs.citusdata.com/en/v11.0-beta/get_started/what_is_citus.html#when-to-use-citus

Citus 支持多租户用例中的所有 SQL 语句。即使在跨节点查询的实时分析用例中,Citus 也支持大多数语句。 Citus 不支持的 PostgreSQL 特性中列出了几种不受支持的查询类型? 许多不受支持的功能都有变通方案;以下是一些最有用的。

  • https://docs.citusdata.com/en/v11.0-beta/faq/faq.html#unsupported

使用 CTE 解决限制

当 SQL 查询不受支持时,解决它的一种方法是使用 CTE,它使用我们所谓的 pull-push 执行。

SELECT * FROM ref LEFT JOIN dist USING (id) WHERE dist.value > 10;
/*
ERROR: cannot pushdown the subquery
DETAIL: There exist a reference table in the outer part of the outer join
*/

要解决此限制,您可以通过将分布式部分包装在 CTE 中来将查询转换为路由器查询

WITH x AS (SELECT * FROM dist WHERE dist.value > 10)
SELECT * FROM ref LEFT JOIN x USING (id);

请记住,coordinator 会将 CTE 的结果发送给所有需要它进行处理的 worker。因此,最好将最具体的过滤器和限制添加到内部查询中,或者聚合表。这减少了此类查询可能导致的网络开销。在子查询/CTE 网络开销中了解更多信息。

  • https://docs.citusdata.com/en/v11.0-beta/performance/performance_tuning.html#subquery-perf

临时表:不得已的解决方法

即使通过子查询使用推拉执行,仍有一些查询不受支持。其中之一是在分布式表上使用分组集。

https://docs.citusdata.com/en/v11.0-beta/faq/faq.html#unsupported

https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-GROUPING-SETS

在我们的实时分析教程中,我们创建了一个名为 github_events 的表,由 user_id 列分布。让我们查询它并找到一组预选的 repos 的最早事件,按事件类型和事件公开的组合分组。一种方便的方法是使用分组集。但是,如前所述,分布式查询尚不支持此功能:

https://docs.citusdata.com/en/v11.0-beta/get_started/tutorial_realtime_analytics.html#real-time-analytics-tutorial

-- this won't work
SELECT repo_id, event_type, event_public,
grouping(event_type, event_public),
min(created_at)
FROM github_events
WHERE repo_id IN (8514, 15435, 19438, 21692)
GROUP BY repo_id, ROLLUP(event_type, event_public);
ERROR:  could not run distributed query with GROUPING
HINT: Consider using an equality filter on the distributed table's partition column.

不过,有一个窍门。我们可以将相关信息作为临时表拉取到 coordinator:

-- grab the data, minus the aggregate, into a local table

CREATE TEMP TABLE results AS (
SELECT repo_id, event_type, event_public, created_at
FROM github_events
WHERE repo_id IN (8514, 15435, 19438, 21692)
);

-- now run the aggregate locally

SELECT repo_id, event_type, event_public,
grouping(event_type, event_public),
min(created_at)
FROM results
GROUP BY repo_id, ROLLUP(event_type, event_public);
 repo_id |    event_type     | event_public | grouping |         min
---------+-------------------+--------------+----------+---------------------
8514 | PullRequestEvent | t | 0 | 2016-12-01 05:32:54
8514 | IssueCommentEvent | t | 0 | 2016-12-01 05:32:57
19438 | IssueCommentEvent | t | 0 | 2016-12-01 05:48:56
21692 | WatchEvent | t | 0 | 2016-12-01 06:01:23
15435 | WatchEvent | t | 0 | 2016-12-01 05:40:24
21692 | WatchEvent | | 1 | 2016-12-01 06:01:23
15435 | WatchEvent | | 1 | 2016-12-01 05:40:24
8514 | PullRequestEvent | | 1 | 2016-12-01 05:32:54
8514 | IssueCommentEvent | | 1 | 2016-12-01 05:32:57
19438 | IssueCommentEvent | | 1 | 2016-12-01 05:48:56
15435 | | | 3 | 2016-12-01 05:40:24
21692 | | | 3 | 2016-12-01 06:01:23
19438 | | | 3 | 2016-12-01 05:48:56
8514 | | | 3 | 2016-12-01 05:32:54

在 coordinator 上创建临时表是最后的手段。它受节点的磁盘大小和 CPU 的限制。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/225667.html<

(0)
管理的头像管理
上一篇2025-04-17 00:27
下一篇 2025-04-17 00:28

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注