Vertica中的JOIN失败,"内部分区不适合内存"

use*_*904 5 database join vertica

我有十个连接表的大查询问题.我正在将数据从广泛的事实表(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');
Run Code Online (Sandbox Code Playgroud)

但这不起作用,因为后来我得到:

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
Run Code Online (Sandbox Code Playgroud)

这种情况持续了一段时间,而Vertica显然试图找到一种方法来执行连接,但最终会因为连接不适合内存而出现错误.

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

Qui*_*nnG 6

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

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

使用这些步骤,我没有遇到任何无法获得结果的情况.有时需要一段时间.我有一组查询泵入一系列14个临时表,结束于一个非常小的结果集; 但由于必须完成原始的运算量,因此需要15分钟才能运行.