Citus 11 for Postgres 完全开源，可从任何节点查询(Citus 官方博客)

Citus 11.0 来了！ Citus 是一个 PostgreSQL 扩展，它为 PostgreSQL 添加了分布式数据库的超能力。使用 Citus，您可以创建跨 PostgreSQL 节点集群透明分布或复制的表。 Citus 11.0 是一个新的主版本，这意味着它带有一些非常令人兴奋的新功能，可以实现更高级别的可扩展性。

https://www.youtube.com/watch?v=X-aAgXJZRqM

Citus 11.0 中最大的改进是您现在可以始终从集群中的任何节点运行分布式查询，因为schema & metadata 是自动同步的。我们已经在 Citus 11.0 测试版博客文章中分享了一些细节，但对于那些使用不属于初始测试版的 Citus 开源的人来说，我们也有很大的惊喜。

Citus 11.0 中最大的增强是，您现在可以始终从集群中的任何节点运行分布式查询，因为 schema 和 metadata 是自动同步的。我们已经在 Citus 11.0 beta博客中分享了一些细节，并对于那些使用 Citus 开源的人来说，我们也有很大的惊喜，而 Citus 开源的并不是最初 beta 版的一部分。

当我们发布新的 Citus 版本时，我们通常会发布 2 个版本：开源版本和包含一些额外功能的企业版本。但是，Citus 11.0 将只有一个版本，因为 Citus 扩展中的所有内容现在都是完全开源的！

https://github.com/citusdata/citus

这意味着您现在可以在不阻塞写入的情况下重新平衡分片、管理整个集群的角色、将租户隔离到他们自己的分片等等。所有这一切都建立在 Citus 11.0 中已经大规模增强的基础之上：您可以从任何节点查询您的 Citus 集群，从而创建真正分布式的 PostgreSQL 体验。

在这篇博文中，我们将重点介绍：

正在成为开源的 Citus 企业版功能
从任何节点查询分布式 Postgres 表
隐藏预览功能：触发器！

如果您想了解所有新功能，可以查看 Citus 11.0 的更新页面，其中包含所有新功能和其他改进的详细分类。

https://www.citusdata.com/updates/v11-0/

其余 Citus Enterprise 功能现已开源

很久以前，Citus Data是一家企业软件公司。随着时间的推移，我们团队的重点转向开源，成为云供应商，然后成为 Azure 不可或缺的一部分。有了新的关注点，我们的团队开发了所有新功能，作为 Citus GitHub开源项目的一部分。使 Citus 开源使您能够直接与开发人员和社区交互，了解您运行的代码，避免锁定问题，并为每个人创造更好的开发人员体验。

去年，作为 Citus 10 版本的一部分，我们已经开源了分片重新平衡器，这是 Citus 的一个重要组件，它允许您通过将数据移动到新节点来轻松扩展集群。出于性能原因，分片重新平衡功能也很有用，可以在集群中的所有节点之间平衡数据。

https://www.citusdata.com/blog/2021/03/13/scaling-out-postgres-with-citus-open-source-shard-rebalancer/

现在，作为 Citus 11.0 的一部分，其余的企业功能也成为开源的：

我最喜欢的新开源功能是非阻塞分片重新平衡器

也许新开源功能中最令人兴奋的是非阻塞分片移动。虽然我们在 Citus 10 中开源了分片重新平衡器，但在开源版本的分片移动期间，对正在移动的分片的写入被阻止。现在在 Citus 11 中，Citus 通过使用逻辑复制来移动分片。这样，当通过将现有数据移动到新节点来扩展集群时，您的应用程序只会遇到短暂的写入延迟。一个先决条件是所有 Postgres 表都有主键。

https://www.citusdata.com/blog/2021/03/13/scaling-out-postgres-with-citus-open-source-shard-rebalancer/

现在分片重新平衡器的非阻塞方面已经开源，当您在本地、内部部署、CI 环境或 Azure 中的托管服务中运行 Citus 时，您可以获得完全相同的分片重新平衡功能。

从任何节点查询分布式 Postgres 表

Citus 11 还带有一个重要的新功能：自动 schema 和 metadata 同步。

在典型的 Citus 部署中，您的应用程序通过协调器执行分布式查询。从应用程序的角度来看，通过协调器连接使得 Citus 在很大程度上与单节点 PostgreSQL 没有区别。

图 1：Citus 10.2 或更早版本中的 Citus 集群，其中 users 和 items 是分布式表，它们的元数据仅在协调器上。

协调器可以处理高分布式查询吞吐量（100k/秒），但是有些应用程序仍然需要更高的吞吐量，或者有查询需要在协调器上进行相对大量的处理（例如，使用大型结果集进行搜索）。幸运的是，Citus 11 中的分布式查询可以由任何节点处理，因为分布式表 schema 和 metadata 从协调器同步到所有节点。您仍然可以通过协调器执行 DDL 命令和集群管理，但可以选择跨工作节点负载均衡繁重的分布式查询工作负载。

https://www.citusdata.com/blog/2022/03/26/test-drive-citus-11-beta-for-postgres/#section3

图 2：Citus 11.0 集群，其中 users 和 items 是分布式表 - 使用新的自动元数据同步功能，他们的元数据会同步到所有节点。

虽然元数据同步在 Citus 11 之前已经作为一种特殊模式存在，但存在一些限制（我们有时将其称为“Citus MX”），但它现在是通用且自动的。任何 Citus 集群都将始终在所有节点上具有分布式表元数据，以及您的所有视图、函数等，这意味着任何节点都可以执行分布式查询。

Citus 11 beta 博客文章详细介绍了在从任何节点查询时如何操作集群。博客文章描述了如何查看所有节点的活动，以及如何使用全局进程标识符 (GPID) 将内部查询与分布式查询相关联。这篇文章还介绍了如何在 Citus 节点之间对来自应用程序的连接进行负载均衡。

https://www.citusdata.com/blog/2022/03/26/test-drive-citus-11-beta-for-postgres/

最重要的是，这个新的元数据同步/从任何节点查询功能对您和您的应用意味着什么？

无需更改应用程序： 您的应用程序可以继续将您的 Postgres 查询路由到 Citus 协调器，就像您一直做的那样，并让 Citus 确定如何分发查询。
现在最苛刻的数据密集型应用程序可以选择从任何节点进行查询： 如果您愿意并且需要，您可以在 Citus 工作节点之间对 Postgres 查询进行负载均衡。请务必遵循有关如何根据最大连接数和负载平衡配置集群的说明。
- https://www.citusdata.com/blog/2022/03/26/test-drive-citus-11-beta-for-postgres/#section2

升级到 Citus 11

如果您当前正在运行 Citus 集群，升级到 Citus 11 很简单。安装新包并重启 PostgreSQL 后，第一步是在所有节点上运行以下命令：

https://docs.citusdata.com/en/stable/admin_guide/upgrading_citus.html

ALTER EXTENSION citus UPDATE;

然后当所有节点都升级后，第二步是连接到协调器并运行：

CALL citus_finish_citus_upgrade();

上面的第二步是 Citus 11 中的新步骤。citus_finish_citus_upgrade 函数将确保所有节点都有元数据，这样您现有的集群的行为就与全新的 Citus 11 集群相同。我们建议在以后的任何 Citus 升级之后调用 citus_finish_citus_upgrade，因为我们可能会添加额外的步骤。

切换到 Citus 11 时无需更改应用程序。 您可以通过协调器继续运行所有查询，这对于大多数应用程序来说仍然是最简单的方法。升级后，您可以选择通过工作节点运行部分或全部查询，当然也可以使用所有新功能，例如非阻塞重新平衡器。

升级到 Citus 11 时要考虑的一件事是，一些很少使用的功能已被弃用：

分片放置失效用于处理使用基于语句的分片复制复制的分片的写入失败。当分片放置上的写入失败时，它将失效，以便系统可以继续使用剩余的副本。虽然这种行为有一些可用性优势，但它也有许多缺点。 Citus 仍然支持基于语句的分片复制来扩展读取，因此可以升级使用分片复制的现有分布式表，但升级后分片放置将不再因失败而失效。虽然这种行为有一些可用性优势，但它也有许多缺点。 Citus 仍然支持基于语句的分片复制来扩展读取，因此可以升级使用分片复制的现有分布式表，但升级后分片放置将不再因失败而失效。
追加分布式表是在加载新数据时需要频繁创建新分片的分布式表。这种方法的缺点是表的分片过多，并且由于没有明确定义的分布列，许多关系特性不可用。从 Citus 11.0 开始，现有的附加分布式表将是只读的。我们建议切换到哈希分布表。
分布式 cstore_fdw 表是分布式表，其中分片是使用 cstore_fdw 扩展的外部表。由于 Citus 具有内置的列访问方法，因此现在不推荐使用分布式表与 cstore_fdw 的组合。我们建议在升级到 Citus 11.0 之前转换为列访问方法。
- https://github.com/citusdata/cstore_fdw
- https://www.citusdata.com/blog/2021/03/06/citus-10-columnar-compression-for-postgres/

等等，我的分片在哪里？

如果您以前使用过 Citus，您可能偶尔会连接到您的工作节点以查看将数据存储在分布式表和引用表中的分片。每个工作节点都会有一组不同的分片，例如：

\d

            List of relations

┌────────┬──────────────┬───────┬───────┐

│ Schema │     Name     │ Type  │ Owner │

├────────┼──────────────┼───────┼───────┤

│ public │ citus_tables │ view  │ marco │

│ public │ ref_102040   │ table │ marco │

│ public │ test_102105  │ table │ marco │

│ public │ test_102107  │ table │ marco │

└────────┴──────────────┴───────┴───────┘

在 Citus 11 中，当您连接到任何工作节点时，您会看到分布式表和引用表，但看不到分片：

\d

            List of relations

┌────────┬──────────────┬───────┬───────┐

│ Schema │     Name     │ Type  │ Owner │

├────────┼──────────────┼───────┼───────┤

│ public │ citus_tables │ view  │ marco │

│ public │ ref          │ table │ marco │

│ public │ test         │ table │ marco │

└────────┴──────────────┴───────┴───────┘

(3 rows)

很酷的是集群中的每个节点现在看起来都一样，但是分片在哪里？

我们发现用户和各种工具会因为看到分布式表和分片的混合而感到困惑。例如，pg_dump 将尝试转储分片和分布式表。因此，我们从目录查询中隐藏了分片，但它们仍然存在，如果需要，您可以直接查询它们。

对于需要在特定应用程序中查看分片的情况，我们引入了一个新设置：

-- show shards only to pgAdmin and psql (based on their application_name):

set citus.show_shards_for_app_name_prefixes to 'pgAdmin,psql';

-- show shards to all applications:

set citus.show_shards_for_app_name_prefixes to '*';

\d

            List of relations

┌────────┬──────────────┬───────┬───────┐

│ Schema │     Name     │ Type  │ Owner │

├────────┼──────────────┼───────┼───────┤

│ public │ citus_tables │ view  │ marco │

│ public │ ref          │ table │ marco │

│ public │ ref_102040   │ table │ marco │

│ public │ test         │ table │ marco │

│ public │ test_102105  │ table │ marco │

│ public │ test_102107  │ table │ marco │

└────────┴──────────────┴───────┴───────┘

(6 rows)

Citus 11 中的隐藏预览功能：分布式表上的触发器

触发器是一个重要的 Postgres 特性，用于维护复杂的数据模型——以及更广泛的关系数据库。当插入、更新或删除行时，触发器函数可以对数据库执行其他操作。由于所有 Citus 节点现在都有元数据，分布式表的分片上的触发器现在可以从存储分片的工作节点对其他分布式表执行操作。

Citus 的触发器方法可以很好地扩展，因为 Postgres 触发器调用被下推到每个分片。然而，Citus 目前无法知道触发器函数会做什么，这意味着它可以做一些导致事务问题的事情。例如，如果触发器函数尝试访问其他分片，它可能看不到一些未提交的写入。避免这种情况的方法是仅从触发函数访问位于同一位置的分片键。目前，我们要求用户使用 citus.enable_unsafe_triggers 设置显式启用触发器：

https://docs.citusdata.com/en/stable/sharding/data_modeling.html#table-co-location

CREATE TABLE data (key text primary key, value jsonb);

SELECT create_distributed_table('data','key');

CREATE TABLE data_audit (operation text, key text, new_value jsonb, change_time timestamptz default now());

SELECT create_distributed_table('data_audit','key', colocate_with := 'data');

-- we know this function only writes to a co-located table using the same key

CREATE OR REPLACE FUNCTION audit_trigger()

RETURNS trigger

AS $$

DECLARE

BEGIN

    INSERT INTO data_audit VALUES (TG_OP, Coalesce(OLD.key, NEW.key), NEW.value);

    RETURN NULL;

END;

$$ LANGUAGE plpgsql;

-- so, it is safe to enable triggers on distributed tables

SET citus.enable_unsafe_triggers TO on;

CREATE TRIGGER data_audit_trigger

AFTER INSERT OR UPDATE OR DELETE ON data

FOR EACH ROW EXECUTE FUNCTION audit_trigger();

只要您小心地只访问位于同一位置的键，使用 Citus 的触发器为您提供了一种利用自动 schema 和 metadata 同步的好方法，而不必在节点之间进行负载均衡查询。通过将更多工作推入触发函数，需要更少的分布式查询和网络往返，从而提高整体可伸缩性。