6

我对来自十个连接表的大查询有疑问。我正在将数据从宽事实表 (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 显然试图找到一种方法来执行连接，但最终因错误说连接不适合内存而退出。

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

4

2 回答 2

7

我为解决这个错误所做的事情......

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

使用这些步骤，我没有遇到任何无法获得结果的情况。有时需要一段时间。我有一组查询泵入一系列 14 个临时表，这些表以非常小的结果集结束；但是由于必须进行大量的运算，因此需要超过 15 分钟才能运行。

于 2012-10-18T19:38:39.927 回答
0

Nija 的答案是更好的答案，但这里有一个建议要考虑：获取更多内存。有时你的系统已经超出了你的要求。

他对使用临时表的建议是我过去使用过的，但我已经有一段时间没有遇到这个问题了。但那是因为我们的系统没有做很多连接。

于 2012-10-19T19:56:52.357 回答