database - Vertica 中的 JOIN 失败，返回 "inner partition did not fit in memory"

Question

我在处理来自十个连接表的大查询时遇到问题。我正在将数据从宽事实表 (f1) 迁移到星型模式。我首先从 f1 填充维度表，然后填充新的事实表 (f2)，并连接到维度表以获得相应的 ID。

不幸的是，我得到一个错误，“内部分区不适合内存”。从日志中我看到:

2012-10-18 16:20:31.607 Init Session:0x2aac6c02b250 [EE] <INFO>   ENABLE_JOIN_SPILL may allow this query to run, with reduced performance 
2012-10-18 16:20:31.607 Init Session:0x2aac6c02b250 [EE] <INFO> Query Retry action: Setting add_vertica_options('EE','ENABLE_JOIN_SPILL');

但这也行不通，因为后来我得到:

2012-10-18 16:23:31.138 Init Session:0x2aac6c02b250 [EE] <INFO>   Join ((public.owa_search_term_dim x public.page_impressions_with_session) using owa_search_term_dim_projection_node0001 and previous join (PATH ID: 7)) inner partition did not fit in memory; value 
2012-10-18 16:23:31.138 Init Session:0x2aac6c02b250 [EE] <INFO> Query Retry action: Swapping join order with override: 1|7|0

这种情况持续了一段时间，而 Vertica 显然试图找到一种方法来执行连接，但最终因错误提示连接不适合内存而放弃。

是否有关于如何最小化执行连接所需的内存或为什么溢出到磁盘不起作用的提示？我可以处理性能问题，我只需要能够执行查询。

Answer 1

我为解决此错误所做的工作...

• 重写查询
  有时初始查询并没有尽可能地优化。我解决这个问题的方法之一是使用子查询。
• 使用临时表
  通过使用临时表，我不得不生成的一些报告工作得非常好。这是使用子查询的更“极端”版本。
• 其他过滤器
  有时一些小事，比如添加额外的过滤器并确保它们被下推到连接的表中，将在 5 分钟的 OOM 查询和 30 秒的工作查询之间产生差异。
• 限制数据 在多个步骤中处理多个数据子集。与附加过滤器非常相似，处理数据子集可减少 Vertica 将使用的资源量，从而实现成功执行.对于基于日期的聚合，我经常这样做；我按天->月->年做。这个子集从未失败过，当简单地汇总年份永远行不通时，我最终得到了准确的年度汇总。
• 预测
  使用为此定制的特定于查询的预测可以让 Vertica 使用更少的资源。
• 解释计划
  通过查看解释计划，我得到了 2 个主要好处。
  A) 确保 Vertica 使用预期的投影。例如，查询特定预测以优化性能。如果我发现它们不是，我可以检查我对查询的期望和假设。
  B) 检查是否所有表都应用了最大过滤器。在我的一些更复杂的子查询中，我发现日期列没有被正确地下推到所有的表。一旦我纠正了这个问题，性能就会提高一个数量级(见上文 5 分钟到 30 秒)。

使用这些步骤，我还没有遇到过出不来结果的情况。有时需要一段时间。我有一组查询注入(inject)到一系列 14 个临时表中，这些临时表以一个非常小的结果集结尾；但由于必须完成的原始处理量，运行需要超过 15 分钟。