Tuple mover

• 1: 合并
• 1.1: 合并请求类型和优先级
• 1.2: 计划的合并
• 1.3: 用户调用的合并
• 1.4: 分区合并
• 1.5: 删除标记合并
• 1.6: 针对特定表禁用合并
• 1.7: 清除 ROS 容器
• 1.8: 合并分层算法
• 2: 管理 Tuple Mover

=> ALTER RESOURCE POOL TM FOR SUBCLUSTER dashboard MEMORYSIZE '0%'
   MAXMEMORYSIZE '0%';

1 - 合并

“合并”是用于合并 ROS 容器并清除已删除记录的Tuple Mover 进程。 DML 活动（例如 COPY 和数据分区）会生成新的 ROS 容器，这些容器通常需要整合，而删除数据和对数据重新分区则需要重组现有容器。Tuple Mover 持续监控这些活动，并根据需要执行合并以整合和重组容器。这样做，Tuple Mover 为的是避免两个问题：

• 当列数据分散在多个 ROS 容器中时，性能会下降。

• 当给定投影的 ROS 容器的增长速度超过 Tuple Mover 的处理速度时，存在 ROS 推回的风险。一个投影最多可以有 1024 个 ROS 容器；当达到该限制时，Vertica 开始在所有的投影查询尝试中返回 ROS 推回错误。

1.1 - 合并请求类型和优先级

Tuple Mover 持续监控所有生成新 ROS 容器的活动。这样做时，它会创建合并请求并根据类型对它们进行排队。这些类型如下所示，按优先级降序排列：

1. RECOMPUTE_LIMITS：设置 Tuple Mover 用于确定何时对投影的新合并请求进行排队的标准。此请求类型在以下两种情况下排队：

   • 创建投影时。

   • 当现有投影发生更改时（例如添加或删除列），或者影响该投影的 ROS 存储的配置参数（如 ActivePartitionCount）发生更改时。

2. MERGEOUT：整合新容器。这些容器通常包含来自最近加载活动或表分区的数据。

3. DVMERGEOUT：整合具有删除标记（或删除向量）的数据。

4. PURGE：从容器中清除过期的删除向量。

Tuple Mover 还监控为每个投影创建容器的频率，以确定哪些投影可能面临 ROS 推回的风险。投影上的密集 DML 活动通常会导致容器创建速率很高。Tuple Mover 监控 MERGEOUT 和 DVMERGEOUT 请求，并在每个集合中根据请求的投影活动级别确定请求的优先级。对具有最高容器创建速率的投影的合并请求将获得立即执行的优先级。

1.2 - 计划的合并

Tuple Mover 定期检查合并队列中是否有待定请求，检查间隔由配置参数 MergeOutInterval 设置：

1. 如果队列包含合并请求，则 Tuple Mover 不执行任何操作并重新进入睡眠状态。

2. 如果队列为空，Tuple Mover：

   • 处理待处理的存储位置移动请求。

   • 检查新的未排队清除请求并将它们添加到队列中。

   然后它重新进入睡眠状态。

默认情况下，此参数设置为 600（秒）。

1.3 - 用户调用的合并

您可以随时通过调用 Vertica 元函数 DO_TM_TASK 来对一个或多个投影调用合并操作：

DO_TM_TASK('mergeout'[, '[[database.]schema.]{table | projection} ]')

该函数扫描指定范围内的数据库编录以确定待定的合并任务。如果未指定表或投影，则 DO_TM_TASK 扫描整个编录。与在 TM 资源池中运行的连续 TM 服务不同，DO_TM_TASK 在 GENERAL 池中运行。如果 DO_TM_TASK 执行合并请求队列中待定的合并任务，TM 服务会从队列中移除这些任务而不采取任何操作。

1.4 - 分区合并

Vertica 将来自不同表分区或分区组的数据在磁盘上分开保存。Tuple Mover 在整合 ROS 容器时遵循此分离策略。首次创建某个分区时，它通常会频繁加载数据，而且需要 Tuple Mover 的定期活动。随着分区的老化，它通常会转变为一个基本上只读的工作负载，并且需要的活动要少得多。

Tuple Mover 有两个不同的策略，用于管理这些不同的分区工作负载：

• 活动分区是最近创建的分区。Tuple Mover 使用基于层的算法，旨在最大限度减少各个元组进行合并的次数。表的活动分区计数确定该表有多少个处于活动状态的分区。

• 非活动分区是指那些不是最近创建的分区。Tuple Mover 将 ROS 容器整合至极小集，同时避免合并大小超过 MaxMrgOutROSSizeMB 的容器。

有关 Tuple Mover 如何确定活动分区的详细信息，请参阅活动和非活动分区。

分区合并线程分配

TM 资源池使用其 MAXCONCURRENCY 参数设置可用于合并的线程数。默认情况下，此参数设置为 7。Vertica 将一半线程分配给活动分区，其余一半分配给活动和非活动分区。如果 MAXCONCURRENCY 设置为奇整数，Vertica 会向上舍入以支持处于活动状态的分区。

例如，如果 MAXCONCURRENCY 设置为 7，则 Vertica 会将四个线程专门分配给活动分区，并根据需要将其余的三个线程分配给活动和非活动分区。如果需要额外的线程来避免 ROS 推回，请使用 ALTER RESOURCE POOL 增加 MAXCONCURRENCY。

1.5 - 删除标记合并

当您从数据库中删除数据时，Vertica 并未移除该数据，而是将其标记为已删除。如果使用许多 DELETE 语句标记少数几行（相对于表大小而言），则会导致创建许多小型容器（删除向量）来保存具有删除标记的数据。每一个删除向量容器都会消耗资源，因此这样的容器如果很多，则会对性能产生不利影响，尤其是在恢复期间。

在 Tuple Mover 执行合并后，它会查找包含少量条目的删除标记容器。如果存在这样的容器，Tuple Mover 会将它们合并到一个更大的容器中。此过程会释放多个容器所使用的资源，从而有助于降低跟踪已删除数据所需的开销。Tuple Mover 并不清除已删除的数据，也不对已删除的数据产生任何影响，只是整合删除向量以提高效率。

1.6 - 针对特定表禁用合并

默认情况下，对所有表及其投影启用合并。可以使用 ALTER TABLE 在表上禁用合并。例如：

=> ALTER TABLE public.store_orders_temp SET MERGEOUT 0;
ALTER TABLE

通常，对于为临时目的（例如，用于对旧分区数据进行存档或在表之间交换分区的临时表）而创建的表禁用合并很有用，在任务完成后，很快就会删除这些表。这样做，便可以避免与合并相关的表开销。

您可以查询系统表 TABLES 以确定已禁用合并的表：

=> SELECT table_schema, table_name, is_mergeout_enabled FROM v_catalog.tables WHERE is_mergeout_enabled= 0;
 table_schema |    table_name     | is_mergeout_enabled
--------------+-------------------+---------------------
 public       | store_orders_temp | f
(1 row)

1.7 - 清除 ROS 容器

Vertica 定期检查 ROS 存储容器以确定删除向量是否符合清除条件，如下所示：

1. 计算每个容器中过期删除向量的个数，即等于或早于 Ancient History Mark (AHM) 时期的删除向量。

2. 计算过期删除向量相对于同一 ROS 容器中记录总数的百分比。

3. 如果此百分比超过由配置参数 PurgeMergeoutPercent 设置的阈值（默认为 20%），Vertica 会自动对 ROS 容器执行合并，从而永久移除所有过期的删除向量。Vertica 使用 TM 资源池的 MAXCONCURRENCY 设置来确定可用于合并操作的线程数。

还可以使用两个 Vertica 元函数从 ROS 容器中手动清除所有过期的删除向量：

• DO_TM_TASK('mergeout')

• PURGE

这两个函数都从 ROS 容器中移除所有过期的删除向量，而与给定容器中有多少删除向量无关。

1.8 - 合并分层算法

合并操作使用基于层的算法来验证每个元组是否都经历少量恒定次数的合并操作，而不考虑用来加载数据的过程。合并操作使用此算法来选择要为非分区表和分区表中处于活动状态的分区合并哪些 ROS 容器。

Vertica 为每个处于活动状态的分区和锚定到非分区表的投影构建层。层数、每个层的大小和层中的最大 ROS 容器数根据磁盘大小、内存和投影中的列数计算得出。

先合并小 ROS 容器后合并大 ROS 容器可以在合并过程中获得最大的好处。该算法从第 0 层开始并向上移动。它检查层中的 ROS 容器数是否已达到等于或大于每个层允许的最大 ROS 容器数的值。默认值为 32。如果算法发现一个层已满，它会将投影和该层标记为满足合并条件。

2 - 管理 Tuple Mover

Tuple Mover 已预先配置为处理典型的工作负载。但是，某些情况可能需要您调整 Tuple Mover 行为。您可以通过多种方式执行此操作：

• [配置 TM 资源池](#Configur)。

• 管理处于活动状态的数据分区。

配置 TM 资源池

Tuple Mover 使用内置的 TM 资源池来处理其工作负载。可以调整此资源池的几个设置以方便处理大量负载：

• MEMORYSIZE

• MAXMEMORYSIZE

• MAXCONCURRENCY

• PLANNEDCONCURRENCY

MEMORYSIZE

指定为每个节点的 TM 池保留多少内存。TM 池可以通过从 GENERAL 池中借用内存而超过这个下限。默认情况下，此参数设置为可用内存的 5%。如果 GENERAL 资源池的 MEMORYSIZE 也设置为一定的百分比，则 TM 池会与 GENERAL 池争用内存。此值必须始终小于或等于 MAXMEMORYSIZE 设置。

MAXMEMORYSIZE

设置可分配给 TM 池的内存上限。TM 池可以通过从 GENERAL 池中借用内存而超过由 MEMORYSIZE 设置的值。此值必须始终等于或大于 MEMORYSIZE 设置。

在 Eon 模式数据库中，如果在子群集级别将此值设置为 0，则 Tuple Mover 在子群集上处于禁用状态。

MAXCONCURRENCY

在所有节点上设置 TM 池可用的最大并发执行槽数。在 Vertica ≥9.3 版本中创建的数据库中，默认值为 7。在早期版本中创建的数据库中，默认值为 3。此设置指定可以在多个线程上同时发生的最大合并数。

PLANNEDCONCURRENCY

指定要在资源池中跨所有节点并发执行的查询的首选数量，默认设置为 6。资源管理器使用 PLANNEDCONCURRENCY 来计算对于给定查询可用的目标内存：

TM-memory-size / PLANNEDCONCURRENCY

对于 TM 池，PLANNEDCONCURRENCY 设置必须与 RAM、CPU 和存储子系统的大小成比例。根据存储类型的不同，如果增加 Tuple Mover 线程的 PLANNEDCONCURRENCY，可能会产生存储 I/O 瓶颈。监控存储子系统；如果其充满长 I/O 队列、多于 2 个 I/O 队列以及读写延迟时间长，请调整 PLANNEDCONCURRENCY 参数以使存储子系统资源保持在饱和级别以下。

管理处于活动状态的数据分区

Tuple Mover 假定分区表的所有加载和更新都是针对一个或多个标识为活动的分区。通常，具有最大分区键的分区（通常是最近创建的分区）均视为活动分区。随着分区的老化，其工作负载通常会缩小，并大多变为只读状态。

您可以按优先级的升序指定两个级别的分区表的活动分区数：

• 配置参数 ActivePartitionCount 将确定数据库中分区表的活动分区数。默认情况下，ActivePartitionCount 设置为 1。Tuple Mover 会将此设置应用于自身未设置活动分区计数的所有表。

• 通过使用 CREATE TABLE 和 ALTER TABLE 设置各个表自身的活动分区计数，可以取代各个表的 ActivePartitionCount。

有关详细信息，请参阅活动和非活动分区。

另请参阅