vertica教程_tuple里面tuple「建议收藏」

本博文翻译整理自：
https://www.vertica.com/kb/Tuple-Mover-Best-Practices/Content/BestPractices/Tuple-Mover-Best-Practices.htm

之前的博客也介绍过，vertica中带有写优化存储WOS和读优化存储ROS，tuple_mover操作就是用于处理这两种优化存储的。函数do_tm_task有两个参数：moveout和mergeout，分别用于周期性的将WOS中的数据刷入ROS；合并ROS容器并清除已删除的记录。
下面将详细介绍这两种操作：

moveout

检测wos spillover

WOS内存由名为WOSDATA的内置资源池控制，其默认最大内存大小为每个节点2GB（9.1版本最大内存设置为主机内存的25%）。如果将数据加载到WOS的速度快于元组移动器将数据移出的速度，则数据会溢出到ROS中，直到WOS中的空间可用为止。溢出不会发生数据丢失，但是溢出会比预期更快地创建ROS容器并减慢moveout操作。

可以通过运行以下查询来检测数据库是否正在发生WOS溢出：

=>SELECT node_name, count(*) from dc_execution_engine_events  WHERE event_type = 'WOS_SPILL'  group by node_name;

moveout最佳实践

使用COPY DIRECT加载大数据文件

如果加载大数据文件（每个节点超过100 MB），则将COPY语句转换为COPY DIRECT语句。这使您可以绕过WOS的加载，而直接将文件加载到ROS。

配置参数： MoveOutInterval

将此参数设置为小于填充一半WOS所花费的时间的值。此参数确定在检测到没有要从WOS移出的元组移动器移出操作休眠的时间（以秒为单位）。该参数的默认值为300秒，减小该值可以更频繁地将数据从WOS移到ROS中。

WOS中未提交的数据

不要将未提交的数据留在WOS中的时间超过必要的时间，因为元组移动器仅移出已提交的数据。如果WOS充满了来自未提交事务的数据，则移出无法将数据移出。这可能导致WOS溢出到ROS中。

不要将WOS用于大型临时表

不要使用WOS加载具有大型数据集（每个节点超过50 MB）的临时表。移出操作不会移出临时表数据，并且在事务或会话结束时将删除数据。

WOSDATA资源池的maxMemorySize

如果您同时将负载trickle load到10个以上的表中，并且经历了WOS溢出，则以前的一种或多种最佳实践应有助于解决您的问题。您可以通过增加WOS资源池的maxMemorySize大小来增加WOS内存的大小。除非您将数据主动地加载到许多表中并且每个投影中的WOS中的数据不超过几百兆字节，否则不要增加WOS内存的大小。如果每个投影的WOS中有数百MB，则可能会遇到查询性能不一致的情况。

配置参数： MoveOutSizePct

设置此参数可设置基于空间利用的资格标准来触发moveout。如果将数据trickle load到几个表中，则设置此参数将很有帮助。在这些情况下，移出操作可能会从WOS主动移出数据，这会创建频繁的小型ROS容器。例如，如果将此值设置为40，则在WOS占满40％之前，移出操作不会移出投影，并且可以在移出数据之前帮助批处理数据。

配置参数： MoveOutMaxAgeTime

TM强制把WOS写入到磁盘的时间间隔。该参数的默认值为1800。如果更改MoveOutSizePct参数的值，则可以将此参数的值更改为600。

moveout常见问题

1.是否可以增加moveout的线程数
不可以。moveout线程的默认值为1且无法更改。
2.如何更改MoveOutInterval参数以及它何时生效？
您可以通过set_config_parameter函数来更改此配置参数。更改此参数会影响将来的moveout睡眠状态。
下面的示例将此参数的值更改为120秒：

=>select set_config_parameter（'MoveOutInterval'，120）;

3.如何检查Moveout是否在节点上运行？
您可以通过运行以下SQL语句来检查元组移动器操作的进度：

=> SELECT * from tuple_mover_operations where is_executing;

4.moveout需要哪些锁？
将数据移出投影时，移出需要在表上使用U锁。在管理删除标记或重放删除时，移出将在表上使用T锁。
5.什么会导致moveout失败？

• 如果无法获得T锁，则移出操作将失败或被阻止。发生这种情况是由于长时间运行的事务在同一张表上持有X锁。
• 如果移出操作试图移出指向参与长期合并的ROS容器的已删除向量，则移出操作将失败或被阻止。
• 如果将表上的1024个以上的分区加载到WOS中，则移出操作也会失败。

mergeout

Tuple Mover的mergeout操作在后台运行并合并ROS容器。每个节点每个投影的最大ROS容器数为1024。如果在数据加载过程中遇到错误，提示“ TOO MANY ROS CONTAINERS”，则每个节点每个投影的最大ROS容器数已达到。mergeout将ROS容器合并为更少的容器，从而使数据库在正常使用情况下不会达到此限制。

megeout的最佳实践

使用WOS进行加载或直接批量加载

将数据加载到WOS中有助于在将数据移到磁盘之前批量处理数据，从而减少了创建的ROS容器的数量。对于较大的文件，请使用DIRECT HINT直接将其批量加载到ROS中。

TM资源池的内存大小

如果您的数据库有宽表（超过100列），请增加TM资源池的memorySize和maxMemorySize，以加快对宽表的操作。

表分区

每个表创建50个或更少的分区，因为Vertica不会跨分区合并ROS容器。因此，具有数百个分区的表可能会很快受到ROS的限制。您可以使用ALTER TABLE ALTER PARTITION命令更改表的分区方案。

如果您拥有不再访问的旧分区，则可以使用该MOVE_PARTITION_TO_TABLE功能将其移动到归档表中。

配置参数：ActivePartitionCount

如果您的表频繁接收到当前和最近的非活动分区中的数据，请将ActivePartitionCount参数从默认值1更改为2。Vertica希望该分区基于时间，其中一个活动分区接收数据，而其他非活动分区很少或从不接收数据。元组移动器将非活动分区的ROS容器合并到单个ROS容器中。修改方法为：

alter table tablename set ActivePartitionCount 2;

限制在同一表上的投影集

同一张表上固定的投影集不能超过两个。每个表具有两个以上的投影集会导致系统资源浪费。

投影排序顺序准则

排序的列要少于10列，并避免排序包含宽的VARCHAR列。这有助于减少合并操作运行所花费的时间。长时间运行的操作可能会阻塞合并线程，从而增加了ROS容器的数量。

优化投影以删除和重播删除

通过使用高基数列作为排序顺序的最后一列，优化删除投影。这可以帮助您避免由于重播删除而导致长时间的合并。如果合并停滞在执行重播删除，请使用该close_session(<session_id>)功能取消操作。然后运行该make_ahm_now功能以推进高级历史标记（AHM）。在AHM前进之后，删除不会重播，并且合并操作应该运行得更快。长时间运行的合并执行重播删除会导致ROS容器随时间累积。

验证reorganize操作成功完成

您可以通过检查PARTITION_STATUS系统表来检查重组操作的状态。如果分区表达式已更改，但重组表达式未启动或失败，则在重组表之前，更改之前已存在的锚定在表上的投影的ROS容器将不符合合并条件。您可以通过以下方法解决此问题：

ALTER TABLE <TABLE_NAME> REORGANIZE;

批量删除和更新

尽可能批量删除和更新。如果必须执行频繁的删除或更新，请使用WOS将删除合并到更少的删除向量中。这样可以防止每个投影的删除向量过多，从而导致ROS容器堆积。

配置参数： MergeOutInterval

该参数的默认值为600，可以调整此参数，以验证每个投影每个间隔创建的ROS容器数不超过ROS PUSHBACK限制。

TM资源池的MaxConcurrency和PlannedConcurrency

如果您考虑了前面列出的最佳实践，但是您的工作量需要更多的合并线程，请将TM资源池的MaxConcurrency和PlannedConcurrency参数从3增加到4。请勿将此值增加到大于6。

mergeout：常见问题

元组移动器合并STRATA算法如何工作？

元组移动器合并操作使用基于层次的算法。设计此算法的目的是确保加载过程中，每个元组都会经受少量恒定次数的合并。使用此算法，合并输出操作用于选择合并不带分区的表和已分区表中的活动分区的哪些ROS容器。

Vertica为每个活动分区以及锚定到未分区表的投影建立层次。根据磁盘大小，内存和投影中的列数来计算层数，每个层的大小以及层中ROS容器的最大数目。

下图显示了该算法如何根据ROS容器的大小将其分类为多个层次。0层中的任何ROS容器的ROS大小都可以忽略不计（每列1 MB或更小）。紫色点表示ROS容器：

在合并较大的ROS容器之前合并小ROS容器可为合并算法带来最大的好处。该算法从0层1个字节开始，到可忽略的ROS块大小，然后向上移动。它检查层中ROS容器的数量是否已达到等于或大于每个层允许的最大ROS容器的值（默认值为32）。如果算法发现层已满，则将投影和层标记为可合并。

合并操作会合并整个层中的ROS容器，并生成通常分配给下一个层的新ROS容器。除第0层之外，合并操作仅合并等于的值的ROS容器ROSPerStratum。对于第0层，mergeout操作会将在该层内存在的所有合格ROS容器合并到一个ROS容器中。

默认情况下，合并操作具有两个线程。通常，较高层中的大型ROS容器的合并比较低层中的ROS容器的合并需要更长的时间。只有合并线程0可以在较高的层和非活动分区上工作。此限制可防止ROS容器在较低层中累积，因为合并线程0需要花费更多时间在较高层中执行合并。合并线程1仅在较低的层次上运行。

注意：如果添加更多合并线程，则这些其他线程仅在层的下部运行。

在非活动分区上有多少个合并线程可以工作？
合并线程0仅在非活动分区上运行，并将ROS容器从非活动分区合并到单个ROS容器中。线程0仅在没有其他投影符合基于层算法的合并条件时，才在非活动分区上工作。

合并操作是否清除已删除的数据？
元组移动器仅清除在AHM之前已删除的数据，该数据已根据层次算法在符合合并条件的ROS容器中进行清除。在非活动分区中删除的数据也可以清除。但是，要有资格进行清除，具有不活动分区的ROS容器中已删除数据的百分比必须超过该PurgeMergeoutPercent参数的值。此参数的默认值为20。

如何找到给定投影的活动分区？

您可以使用以下命令找到给定投影的活动分区：

=>SELECT DISTINCT partition_key FROM strata WHERE projection_name <projection_name> AND schema_name <schema>;

如何找到每个节点的每个投影的容器数？

=>SELECT node_name, schema_name, projection_name,
 sum(delete_vector_count) delete_vector_count, count(*) ROS_container_count, sum(delete_vector_count) + count(*) total_container_count
 FROM storage_containers
 GROUP BY 1,2,3 ORDER BY 6 DESC;

Too Many ROS containers问题

产生原因：projection的数据文件太碎，一般与数据加载方法不当有关。
原理：

• partition划分越细，ROS container就会越多
• local segment会成倍增加ROS container数量
• 非Active partition会尽量合并成一个大文件而费时
• 合并过程中delete replay可能费时
• TM资源池缺省只使用100M内存(目前是5%)，仅用2个并行任务合并数据
• 数据文件太多，会影响所有操作性能。所以vertica限制每个节点每个projection的ROS container数不允许操作containerPerProjectionLimit(缺省为1024)

解决办法（按顺序逐步优化）

• 确认copy/DML方式是否合理。尽量批量操作。大批量操作才适合用direct，否则会快速产生大量数据文件
• 确认partition划分是否合理。一个表不易超过700个分区。如果实在太多，可以考虑使用分层分区。
• 确认local segment的scaling factory设置是否合理。表多、partition多，并且不经常扩展集群时，建议关闭local segment。
• 确认是否经常要同时DML操作多个partition的数据。如果是，增加Active partition，以免过度很行实际的活动分区浪费资源。
• 确认删除操作是否优化过（所有的projection都带删除条件列，并按他们排序，哪怕是排在最后）
• 增加WOSDATA资源池的内存，让Tuple Mover从WOS写出的文件更大、数量更少
• 降低MergeOutInterval参数，加快Tuple Mover执行文件合并的频度
• 逐渐增加1-2个TM资源池的MaxConcurrency和PlannedConcurrency值，执行更多的并行合并任务。
• 增加TM资源池的MemorySize，缩短Mergout操作的时间，尤其是宽表。
• 特定情况需要避免数据加载被中断，可以临时性地提高参数ContainerPerProjectionLimit，但在完成上述优化后一定要把它恢复为缺省值。

今天的文章vertica教程_tuple里面tuple「建议收藏」分享到此就结束了，感谢您的阅读。