6

結合された 10 個のテーブルからの大きなクエリに問題があります。ワイド ファクト テーブル (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

このエラーを回避するために私が行ったこと...

  • クエリを書き直す
    最初のクエリが最適化されていない場合があります。これにアプローチする方法の 1 つは、サブクエリを使用することです。
  • 一時テーブルの使用
    これまで生成しなければならなかったレポートのいくつかは、一時テーブルを使用することで非常にうまく機能しました。これは、サブクエリを使用するより「極端な」バージョンです。
  • 追加のフィルター 追加のフィルター
    を追加したり、それらが結合されたテーブルに確実にプッシュされるようにするなどの小さなことで、5 分間の OOM クエリと 30 秒間の作業クエリの違いが生じることがあります。
  • データの制限 複数のステップでデータの複数のサブセットを実行します。追加のフィルタと同様に、データのサブセットを実行すると、Vertica が使用するリソースの量が減り、正常に実行できるようになります。私はこれを日付ベースの集計に対して頻繁に行います。日→月→年でやってます。このサブセットは一度も失敗したことがなく、単純に年を集計するだけではうまくいかない場合でも、正確な年次集計が得られます。
  • プロジェクション
    これに合わせたクエリ固有のプロジェクションを使用すると、Vertica が使用するリソースを減らすことができます。
  • 説明計画 説明計画
    に目を通すことで得られる主な利点は 2 つあります。
    A) Vertica が予想されるプロジェクションを使用していることを確認します。たとえば、特定のプロジェクションをクエリして、パフォーマンスを最適化します。そうでないことがわかった場合は、クエリに関連する私の期待と仮定を確認できます。
    B) すべてのテーブルに最大のフィルターが適用されていることを確認します。より複雑なサブクエリのいくつかで、Date 列がすべてのテーブルに正しくプッシュされていないことがわかりました。これを修正すると、パフォーマンスが桁違いに速くなりました (上記の 5 分から 30 秒を参照)。

これらの手順を使用して、結果を得ることができなかった状況に遭遇したことはありません. 時間がかかる場合もあります。非常に小さな結果セットで終わる一連の 14 個の一時テーブルに送り込む一連のクエリがあります。ただし、実行する必要がある生の量のクランチが原因で、実行に 15 分以上かかります。

于 2012-10-18T19:38:39.927 に答える
0

Nija の答えはより良い答えですが、考慮すべき提案があります。メモリを増やしてください。場合によっては、システムが大きくなりすぎることがあります。

一時テーブルを使用するという彼の提案は、私が過去に使用したものですが、かなり長い間問題に遭遇していません。しかし、それは私たちのシステムが多くの結合を行わないためです.

于 2012-10-19T19:56:52.357 に答える