警告

多节点支持已停止.

TimescaleDB v2.13 是最后一个包含对 PostgreSQL 13、14 和 15 版本多节点支持的版本。

分布式超表是跨多个节点的超表。使用分布式超表，您可以将数据存储扩展到多台机器。数据库还可以并行处理部分插入和查询。

分布式超表仍然表现得像一个单表。您可以像使用标准超表一样使用它。要了解有关超表的更多信息，请参阅超表部分。

某些细微之处可能会影响分布式超表的性能。本节解释了分布式超表的工作原理，以及在采用之前需要考虑的事项。

分布式超表与多节点集群一起使用。每个集群都有一个访问节点和多个数据节点。您使用访问节点连接到数据库，数据存储在数据节点上。有关多节点的更多信息，请参阅多节点部分。

您在访问节点上创建分布式超表。其块存储在数据节点上。当您插入数据或运行查询时，访问节点与相关数据节点通信，并在可能的情况下下推任何处理。

分布式超表始终按时间分区，就像标准超表一样。但与标准超表不同，分布式超表也应该按空间分区。这允许您在数据节点之间平衡插入和查询，类似于传统分片。如果没有空间分区，同一时间范围内的所有数据将写入单个节点上的同一个块。

默认情况下，Timescale 会创建与数据节点数量相同的空间分区。您可以更改此数字，但过多的空间分区会降低性能。它会增加某些查询的规划时间，并在将项映射到分区时导致较差的平衡。

数据通过哈希分配到空间分区。空间维度中的每个哈希桶对应一个数据节点。一个数据节点可以包含多个桶，但每个桶在每个时间间隔内只能属于一个节点。

当启用空间分区时，使用 2 个维度将数据划分为块：时间维度和空间维度。您可以指定沿空间维度的分区数量。数据通过对其在该维度上的值进行哈希分配到分区。

例如，假设您使用 `device_id` 作为空间分区列。对于每一行，`device_id` 列的值都会进行哈希。然后将该行插入到该哈希值对应的正确分区中。

展开图片

空间分区维度可以是开放的或封闭的。封闭维度具有固定数量的分区，通常使用哈希将值与分区匹配。开放维度没有固定数量的分区，通常每个块覆盖一定的范围。在大多数情况下，时间维度是开放的，空间维度是封闭的。

如果您使用 `create_hypertable` 命令创建超表，则空间维度是开放的，无法调整。要创建具有封闭空间维度的超表，请首先仅使用时间维度创建超表。然后使用 `add_dimension` 命令显式添加一个开放设备。如果将范围设置为 `1`，则每个设备都有自己的块。这可以帮助您解决常规空间维度的一些限制，并且在您希望使某些块易于排除时特别有用。

您可以通过添加额外的数据节点来扩展分布式超表。如果您现在拥有的空间分区少于数据节点，则需要增加空间分区的数量以利用您的新节点。新的分区配置仅影响新块。在此图中，在第三个时间间隔期间添加了一个额外的数据节点。第四个时间间隔现在包含四个块，而之前的时间间隔仍包含三个。

展开图片

这可能会影响跨两种不同分区配置的查询。有关更多信息，请参阅关于查询下推限制的部分。

要在块级别复制分布式超表，请配置超表以将每个块写入多个数据节点。这种原生复制可确保分布式超表受到数据节点故障的保护，并提供了一种替代方案，无需使用流复制完全复制每个数据节点以提供高可用性。只有数据节点使用此方法进行复制。访问节点不被复制。

有关复制和高可用性的更多信息，请参阅多节点高可用性部分。

分布式超表水平扩展了您的数据存储，因此您不受任何一台机器存储的限制。它还提高了某些查询的性能。

您的性能是否以及提高多少取决于您的查询模式和数据分区。当访问节点可以将查询处理下推到数据节点时，性能会提高。例如，如果您使用 `GROUP BY` 子句进行查询，并且数据按 `GROUP BY` 列分区，则数据节点可以执行处理并将最终结果仅发送到访问节点。

如果处理无法在数据节点上完成，则访问节点需要拉取原始或部分处理的数据并在本地进行处理。有关更多信息，请参阅查询下推的限制。

访问节点可以使用完全或部分方法下推查询。可以下推的计算包括排序和分组。数据节点上的连接目前不支持。

要查看查询如何下推到数据节点，请使用 `EXPLAIN VERBOSE` 检查查询计划以及发送到每个数据节点的远程 SQL 语句。

在完全下推方法中，访问节点将所有计算卸载到数据节点。它从数据节点接收最终结果并将其附加。要完全下推聚合查询，`GROUP BY` 子句必须包含以下任一内容：

• 所有分区列，或
• 仅第一个空间分区列

例如，假设您要计算每个位置的 `max` 温度

SELECT location, max(temperature)
  FROM conditions
  GROUP BY location;

复制

如果 `location` 是您唯一的空间分区，则每个数据节点可以在其自己的数据子集上计算最大值。

在部分下推方法中，访问节点将大部分计算卸载到数据节点。它从数据节点接收部分结果，并通过组合部分结果计算最终聚合。

例如，假设您要计算所有位置的 `max` 温度。每个数据节点计算一个局部最大值，访问节点通过计算所有局部最大值的最大值来计算最终结果。

SELECT max(temperature) FROM conditions;

复制

当分布式超表能够将查询下推到数据节点时，其性能会得到改善。但查询规划器可能无法下推每个查询，或者只能部分下推查询。这可能由以下几个原因导致：

• 您更改了分区配置。例如，您添加了新的数据节点并增加了空间分区的数量以匹配。这可能导致相同空间值的块存储在不同的节点上。例如，假设您按 `device_id` 分区。您从 3 个分区开始，`device_B` 的数据存储在节点 3 上。您稍后增加到 4 个分区。现在 `device_B` 的新块存储在节点 4 上。如果您跨重新分区边界查询，`device_B` 的最终聚合无法单独在节点 3 或节点 4 上计算。必须将部分处理的数据发送到访问节点进行最终聚合。Timescale 查询规划器动态检测此类重叠块并恢复到适当的部分聚合计划。这意味着您可以添加数据节点并重新分区数据以实现弹性，而无需担心查询结果。在某些情况下，您的查询性能可能会略有下降，但这很少见，并且受影响的块通常会很快超出您的保留窗口。
• 查询包含非不变函数和表达式。该函数无法下推到数据节点，因为根据定义，它不能保证在每个节点上具有一致的结果。一个非不变函数的例子是`random()`，它取决于当前的种子。
• 查询包含作业函数。访问节点假定数据节点上不存在该函数，因此不会将其下推。

Timescale 使用多种优化来避免这些限制，并尽可能多地向下推查询。例如，`now()` 是一个非不变函数。数据库将其在访问节点上转换为常量，并将常量时间戳下推到数据节点。

您可以在同一个数据库中使用分布式超表、标准超表和标准 PostgreSQL 表。这与拥有多个标准表的工作方式基本相同，但有一些区别。例如，如果您 `JOIN` 一个标准表和一个分布式超表，访问节点需要从数据节点获取原始数据并在本地执行 `JOIN`。

常规超表的所有限制也适用于分布式超表。此外，以下限制专门适用于分布式超表：

• 不支持后台作业的分布式调度。在访问节点上创建的后台作业将在此访问节点上进行调度和执行，而不会将作业分发到数据节点。
• 连续聚合可以聚合分布在数据节点上的数据，但连续聚合本身必须位于访问节点上。这可能会限制您安装的扩展程度，但由于连续聚合是数据的下采样，这通常不会造成问题。
• 不支持块重新排序。
• 表空间不能附加到访问节点上的分布式超表。仍然可以在数据节点上附加表空间。
• 分布式数据库的节点之间的角色和权限被假定为一致，但不强制执行一致性。
• 不支持数据节点上的连接。将分布式超表与另一个表连接时，要求另一个表位于访问节点上。这也会限制分布式超表上连接的性能。
• 分布式超表中外键约束引用的表必须存在于访问节点和所有数据节点上。这也适用于引用值。
• 不支持并行感知扫描和附加。
• 分布式超表不原生提供跨节点的备份和恢复一致恢复点。使用`create_distributed_restore_point`命令，并确保在将单个备份恢复到访问节点和数据节点时小心操作。
• 有关原生复制限制，请参阅原生复制部分。
• 用户定义函数必须手动安装在数据节点上，以便函数定义在访问节点和数据节点上都可用。这对于使用 `set_integer_now_func` 注册的函数尤为重要。

请注意，这些限制涉及从访问节点的使用。一些目前不支持的功能可能仍然在单个数据节点上工作，但此类用法既未经测试也未得到官方支持。Timescale 的未来版本可能会消除其中一些限制。