关于多节点

如果您有更大的 PB 级工作负载，您可能需要多个 TimescaleDB 实例。TimescaleDB 多节点允许您运行和管理数据库集群，这可以为您提供更快的数据摄取，以及针对大型工作负载更具响应性和效率的查询。

重要

在某些情况下，由于各个节点之间额外的网络通信，您的查询在多节点集群中可能会变慢。当查询处理在节点之间分布且结果集相对于查询数据集较小时，查询性能最佳。在开始之前，了解多节点架构并根据您的具体要求规划数据库非常重要。

多节点架构

多节点 TimescaleDB 允许您将多个数据库连接成一个逻辑分布式数据库，以结合多个物理 PostgreSQL 实例的处理能力。

其中一个数据库存在于访问节点上，并存储有关其他数据库的元数据。其他数据库位于数据节点上并保存实际数据。理论上，一个 PostgreSQL 实例可以在不同的数据库中同时作为访问节点和数据节点。但是，不建议进行混合设置，因为它可能很复杂，并且服务器实例通常根据其扮演的角色进行不同的配置。

对于自托管安装，创建一个可以作为访问节点的服务器，然后使用该访问节点在其他服务器上创建数据节点。

配置多节点 TimescaleDB 后，访问节点协调数据块在数据节点上的放置和访问。在大多数情况下，建议您使用多维分区将数据在时间和空间维度上分布到数据块中。本节中的图表展示了访问节点 (AN) 如何在多个数据节点（DN1、DN2 和 DN3）上将相同时间间隔的数据进行分区。

Diagram showing how multi-node access and data nodes interact

数据库用户连接到访问节点以发出命令和执行查询，这与连接到常规单节点 TimescaleDB 实例类似。在大多数情况下，无需直接连接到数据节点。

由于 TimescaleDB 作为特定数据库中的扩展存在，因此可以在同一个访问节点上同时拥有分布式和非分布式数据库。也可以有多个分布式数据库，它们使用不同的物理实例集作为数据节点。然而，在本节中，假设您有一个具有一致数据节点集的单一分布式数据库。

如果您在分布式数据库上使用常规表或超表，它们不会自动分布式。即使底层数据库是分布式的，常规表和超表仍照常工作。要启用多节点功能，您需要在访问节点上显式创建分布式超表以利用数据节点。分布式超表类似于常规超表，但区别在于数据块分布在数据节点上而不是本地存储上。通过分布式数据块，数据节点的处理能力相结合，以实现更高的摄取吞吐量和更快的查询。然而，实现良好性能的能力在很大程度上取决于数据如何在数据节点之间分区。

为了获得良好的摄取性能，请批量写入数据，每批数据包含可以在许多数据节点上分布的数据。为了获得良好的查询性能，请将查询分散到许多节点上，并使结果集相对于已处理数据量较小。为此，考虑适当的分区方法非常重要。

分区方法

摄取到分布式超表中的数据根据您选择的分区方法分布在数据节点上。可以从访问节点发送到多个数据节点并同时处理的查询通常比在单个数据节点上运行的查询更快，因此重要的是要考虑您拥有的数据类型以及您想要运行的查询类型。

TimescaleDB 多节点目前支持的功能使其最适合根据 `time` 和 `location` 等空间维度进行分区的大容量时序工作负载。如果您通常运行聚合许多位置和设备数据的宽查询，请选择此分区方法。例如，像这样的查询在按 `time,location` 分区的数据库上会更快，因为它将工作并行地分布到所有数据节点上


SELECT time_bucket('1 hour', time) AS hour, location, avg(temperature)
FROM conditions
GROUP BY hour, location
ORDER BY hour, location
LIMIT 100;

如果需要更快的插入性能，按 `time` 和 `location` 等空间维度进行分区也是最佳选择。如果只按时间分区，并且您的插入通常按时间顺序发生，那么您每次只会写入一个数据节点。按 `time` 和 `location` 分区意味着您的按时间顺序的插入将分布到多个数据节点，这可以带来更好的性能。

如果您主要在单个位置运行深度时间查询，那么仅按 `time` 维度或按 `location` 以外的空间维度进行分区可能会获得更好的性能。例如，像这样的查询在仅按 `time` 分区的数据库上会更快，因为单个位置的数据会分布到所有数据节点，而不是仅在一个节点上


SELECT time_bucket('1 hour', time) AS hour, avg(temperature)
FROM conditions
WHERE location = 'office_1'
GROUP BY hour
ORDER BY hour
LIMIT 100;

事务和一致性模型

分布式超表上发生的事务是原子的，就像常规超表上的事务一样。这意味着涉及多个数据节点的分布式事务保证要么在所有节点上成功，要么全部失败。这一保证由两阶段提交协议提供，该协议用于在 TimescaleDB 中实现分布式事务。

然而，分布式超表的读取一致性与常规超表不同。由于分布式事务是跨多个节点的单个事务集合，因此每个节点可能会由于网络传输延迟或其他小波动而在略微不同的时间提交其本地事务。因此，访问节点无法保证所有数据节点上的数据完全一致的快照。例如，当另一个并发写入事务处于其提交阶段并在某些数据节点上已提交而其他节点尚未提交时，分布式读取事务可能会开始。因此，读取事务可以使用一个节点上的快照，其中包含其他事务的修改，而另一个数据节点上的快照可能不包含这些修改。

如果您在分布式事务中需要更强的读取一致性，那么您可以使用所有数据节点上的一致快照。但是，这需要大量的协调和管理，可能会对性能产生负面影响，因此分布式超表默认不实现此功能。

在多节点环境中使用连续聚合

如果您在多节点环境中使用 Timescale，那么对于连续聚合有一些额外的考虑。

当您在多节点环境中创建连续聚合时，该连续聚合应该在访问节点上创建。虽然可以在数据节点上创建连续聚合，但这会干扰访问节点上的连续聚合并可能导致问题。

当您刷新访问节点上的连续聚合时，它会计算一个单一窗口来更新时间桶。如果实际更新的行数很少但分布广泛，这可能会减慢您的查询速度。如果网络延迟很高，例如您有远程数据节点，这种情况会加剧。

失效日志保留在数据节点上，旨在限制需要传输的数据量。但是，某些语句会直接向日志发送失效通知，例如，在删除数据块或截断超表时。与本地更新相比，此操作可能会降低性能。此外，如果您的刷新不频繁但超表发生大量更改，失效日志可能会变得非常大，从而导致性能问题。请确保维护失效日志的大小以避免此问题，例如，通过频繁刷新连续聚合。

有关多节点设置的更多信息，请参阅多节点部分