在Vertica中加入失敗，並顯示「內部分區不適合內存」

我遇到來自十個連接表的大查詢問題。我將數據從廣泛的事實表（f1）遷移到星型模式。我首先填充來自f1的維度表，然後用維度表的連接填充新的事實表（f2）以獲取相應的ID。在Vertica中加入失敗，並顯示「內部分區不適合內存」

不幸的是我得到一個錯誤，「內部分區不適合內存」。從日誌我看到：

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的顯然是試圖找到執行的方式加入，但最終保留一個錯誤，說聯接不適合內存。

有沒有關於如何儘量減少執行連接所需的內存或爲什麼溢出到磁盤不工作的任何提示？我可以處理性能問題，我只需要能夠執行查詢。

來源

2012-10-18 user997904

我已經做了解決此錯誤的東西...

改寫有時初始查詢不優化的，因爲它可以查詢
。我採用的方法之一就是使用子查詢。
使用臨時表格
我必須通過使用臨時表格生成工作得很好。這是使用子查詢的更「極端」版本。
額外的過濾器
有時候一點之類的東西添加額外的過濾器，並確保他們得到下推到連接表會做出5分鐘OOM查詢和工作查詢30ses之間的差異。
限制數據在多個步驟中執行多個數據子集。與額外的過濾器非常相似，執行數據子集可減少Vertica將使用的資源數量，從而實現成功執行。我經常這樣做基於日期的聚合;我按日 - >月 - >年做。這個子集從來沒有失敗過，並且當簡單地彙總年份時，我最終會得到準確的年度彙總。
預測
使用爲此定製的查詢特定投影可能會使Vertica使用更少的資源。
解釋計劃
這兩個主要好處是我從通過解釋計劃看。
A）確保Vertica正在使用預期投影。例如，查詢特定預測以優化性能。如果我發現他們不是，我可以查看與查詢相關的期望和假設。
B）檢查所有表格是否應用了最大過濾器。在我的一些更復雜的子查詢中，我發現Date列沒有被正確地推到所有表中。一旦我糾正了這一點，性能提高了一個數量級（見上面5分鐘到30秒）。

使用這些步驟，我沒有遇到過任何我無法獲得結果的情況。有時需要一段時間。我有一系列的查詢被抽入一系列以臨時結果集爲結尾的14個臨時表中;但需要花費15分鐘才能完成，因爲需要完成大量的碾壓工作。

來源

2012-10-18 19:38:39 Nija

這些都是很好的建議。我已經在限制數據，每次做一天，而且我已經用很多不同的預測做了很多調整，但我不知道自己的目標是什麼。解釋給了我一個成本估算，但這只是速度而已，對吧？我不知道如何判斷我認爲是問題的內部連接的內存使用情況。 – user997904

尼佳的答案是更好的答案，但這裏有一個建議要考慮：獲得更多的記憶。有時你超出了你的系統。

他建議使用臨時表是我以前用過的東西，但我在一段時間內還沒遇到這個問題。但那是因爲我們的系統沒有多少連接。

來源

2012-10-19 19:56:52 geoffrobinson

在Vertica中加入失敗，並顯示「內部分區不適合內存」

回答

相關問題