02 kueri zui_shi_hua_notamenopuroziekushiyonshe_ji_
•Download as PPTX, PDF•
0 likes•4 views
vertica, dwh, データウェアハウス
Recommended
More Related Content
What's hot
What's hot (12)
Similar to 02 kueri zui_shi_hua_notamenopuroziekushiyonshe_ji_
Similar to 02 kueri zui_shi_hua_notamenopuroziekushiyonshe_ji_ (20)
More from Kaito Tonooka
More from Kaito Tonooka (15)
02 kueri zui_shi_hua_notamenopuroziekushiyonshe_ji_
- 1. クエリ最適化のための プロジェクション設計 HPE Vertica Advanced Performance Tuning April 27, 2016
- 2. 本章の概要 – インクリメンタルモードでのデータベースデザイナー – JOIN の最適化 – GROUP BY の最適化 – COUNT DISTINCT – 相関列 – カーディナリティが高い列 2
- 4. インクリメンタルデザイン – 追加のクエリチューニングのために、インクリメンタル（Incremental）デザインを実行 – 更に最適化を必要とするクエリを適用 – 適用された各クエリに対して、最適化された追加のプロジェクションが作成されうる
- 5. サンプルクエリ – 様々なタイプのステートメントを含む： – Select – Delete – クエリは構文エラーの解析がされる – クエリの重み付け – 任意の述語のためにプロジェクションを作成する可能性を高めるべく同様のクエリの述語を繰 り返し記載 – クエリはグループ化され、類似性に基づいて重み付けされる
- 6. 出力ディレクトリ – DBD の出力ディレクトリ以下に生成されたファイルの内容を確認 – [デザイン名]_deploy.sql – [デザイン名]_design.sql – [デザイン名]_params.txt – designer.log
- 7. デプロイメントスクリプトの手動実行 – 必要に応じて、デプロイメント DDL スクリプトを変更し、手動でスクリプトを実行する – vsql 上で実行した場合 => i /filepath/[design name]_deploy.sql – Linux のコマンドライン上で実行した場合 $ vsql –f "/filepath/[design name]_deploy.sql" マネージメントコンソールから DBD を 実行した場合は、スクリプトを保存し てください。
- 8. サンプル DDL – デプロイメントスクリプトを開き確認 – エンコーディング、ソーティング、セグメンテーションの確認 CREATE PROJECTION fact_p /*+basename(fact_p),createtype(D )*/ ( a ENCODING RLE, b ENCODING RLE, c, id ENCODING RLE ) AS SELECT a, b, c, id FROM Fact ORDER BY a,id, b SEGMENTED BY HASH(c) ALL NODES K SAFE; CREATE PROJECTION dim_p /*+basename(dim_p),createtype (D)*/ ( x ENCODING RLE, y ENCODING RLE, z, id ENCODING RLE ) AS SELECT x, y, z,id FROM Dim ORDER BY id, x, y UNSEGMENTED ALL NODES;
- 9. ロギングによる情報 – DBDのロギング機能は下記情報を提供 – DBD実行中にオプティマイザが提案したプロジェクション – デザインがデプロイされた際にDBDが作成したプロジェクション – 全プロジェクションを作成するために使われるDDL – 列の最適化 – 下記でロギング開始 => SELECT SET_CONFIG_PARAMETER('DBDLogInternalDesignProcess','1'); – 情報を参照するデータコレクター（DC）テーブル – DC_DESIGN_PROJECTION_CANDIDATES – DC_DESIGN_QUERY_PROJECTION_CANDIDATES
- 10. JOIN の最適化
- 11. JOIN の最適化 – オプティマイザが理想的な JOIN 演算子を選択するようにプロジェクションを設計 – ハッシュ結合もしくはマージ結合するようにプロジェクションを作成 – ネットワークオペレーションの最小化 – 各 JOIN がローカルで実行できるように、結合キーでプロジェクションを分散 – JOIN の実行時間を完全に排除 – プリジョインプロジェクションの使用 – 外部で非正規化 11
- 12. ハッシュ結合演算子 – 最も一般的な JOIN 演算子 – 特別な最適化は不要 – ハッシュテーブルはディメンション（内部）テーブル上に構築される – ファクト（外部）テーブルがスキャンされ、ディメンションテーブルの行と一致する行は結果セットとして出力される purchases_fact_p (date, item列でソート) customer_dim_p (last_nameでソート) last_nam e cust_i d Adams 10202 Benn 10201 Cobb 10203 ハッシュテーブル (メモリ上) タプルを出力 不一致 date Item cust_i d 10/4/14 Pencil 10201 10/5/14 Fork 10202 10/6/14 Eraser 10201 10/6/14 Soap 10206 10/7/14 Cup 10203 last_ name cust_ id Adams 10202 Benn 10201 Cobb 10203 Benn 10201 10/4/14 PencilAdams 10202 10/5/14 ForkBenn 10201 10/6/14 EraserCobb 10203 10/7/14 Cup
- 13. ハッシュ結合 – Join Spill – ハッシュテーブルがメモリに収まらない場合、結合処理はディスクに書き込みを開始 – ファクトとディメンションの両方がディスクに書き込まれる – 初めはクエリはメモリに収まるようにするが、収まらない場合、 Join Spill が有効化され、クエリを自動的に再実行 – クエリがスピルされることが想定される場合、ヒント文を追加し、メモリへのハッシングをスキップ SELECT /*+add_vertica_options(EE,ENABLE_JOIN_SPILL)*/ … – 再試行を検出するために、 PROFILE 文の実行もしくは vertica.log のチェック – プリジョインプロジェクションへのデータロードにおいて、ハッシュ結合テーブルがメモリ量を超える場合、 ENABLE_JOIN_SPILLが必要 13
- 14. マージ結合演算子 – ディメンションテーブルがメモリに収まらない場合、マージ結合の使用を推奨 – 両テーブルがメモリを介してストリーミングされるため、大きいテーブル同士の JOIN はより高速 – ディスクに移動する必要なし purchases_fact_ p (結合キーでソート) customer_dim_p (結合キーでソート)タプルを出力 不一致 cust_id item date 10201 Pencil 10/4/14 10201 Eraser 10/6/14 10202 Fork 10/5/14 10203 Cup 10/7/14 10206 Soap 10/6/14 cust_id last_name 10201 Benn 10202 Adams 10203 Cobb 10201 Pencil 10/4/14 Benn10201 Erase r 10/6/14 Benn10202 Fork 10/5/14 Adams10203 Cup 10/7/14 Cobb
- 15. マージ結合の要件 – JOIN している両側のデータが結合キーとなる列でソートされている必要あり – プロジェクションにおいて、結合キーで並び替え – ORDER BY 句でサブクエリ内で並び替え – 等価の述語は、マージ結合のサイズを減らすために、最初に実行される（JOIN を下に押し下げ） – オプティマイザは、最初に、クエリの述語に使われている列にあわせて設計されたプロジェクションを探す – クエリが列に対して単一の値の等価の述語を持つ場合にのみ、述語の列は、プロジェクションの ORDER BY で最初に配置 される – ディスクへの書き込みを避けるために、大きいディメンションテーブルに対して推奨 15
- 16. マージ結合の最適化 – ファクトとディメンションの両プロジェクションを JOIN 句の列で並び替え – サンプルクエリ SELECT * FROM Fact F, Dim D WHERE F.id = D.id; – サンプルプロジェクション 16 CREATE PROJECTION Fact_p ( a ENCODING RLE, b ENCODING RLE, c, id ENCODING RLE ) AS SELECT a, b, c, id FROM Fact ORDER BY id, b SEGMENTED BY HASH(c) ALL NODES; CREATE PROJECTION Dim_p ( x ENCODING RLE, y ENCODING RLE, z, id ENCODING RLE ) AS SELECT x, y, z,id FROM Dim ORDER BY id, x, y UNSEGMENTED ALL NODES;
- 17. Predicate Pushdown を伴うマージ結合 – 述語で列をフィルターすることにより、ファクトのプロジェクションを並び替え – 続いて、ファクトとディメンションの両プロジェクションの JOIN 句の列で並び替え – サンプルクエリ SELECT * FROM Fact F, Dim D WHERE F.id = D.id AND f.a = 10; – サンプルプロジェクション 17 CREATE PROJECTION Fact_p ( a ENCODING RLE, b ENCODING RLE, c, id ENCODING RLE ) AS SELECT a, b, c, id FROM Fact ORDER BY a,id, b SEGMENTED BY HASH(c) ALL NODES; CREATE PROJECTION Dim_p ( x ENCODING RLE, y ENCODING RLE, z, id ENCODING RLE ) AS SELECT x, y, z,id FROM Dim ORDER BY id, x, y UNSEGMENTED ALL NODES;
- 18. 結合演算子の確認 – クエリの実行計画で、 結合演算子を探す – JOIN HASH – JOIN MERGEJOIN – vertica.log ファイルを確認する – ハッシュテーブルがメモリに収まらない場合、 vertica.log で ENABLE_JOIN_SPILL 付きのクエリが再実行されていることを 確認する 18
- 19. クエリの最適化 – ネットワークオペレーション – ローカル結合の要件 – ファクトとディメンションテーブルで一致する行が同じノード上にある – 分散化されたファクトと複製されたディメンションの結合 – ファクト： SEGMENTED BY HASH (id) ALL NODES; – ディメンション： UNSEGMENTED ALL NODES; – Identically Segmented プロジェクション – 両プロジェクションが結合キーで分散化されている – イニシエーターノード上で、最終結果が集計される 19
- 20. ローカル結合の設計 – 小さなディメンションのプロジェクションを複製し、大きなファクトのプロジェクションを分散化 20 00034892 trial results 00034892 ABC's storm 01734984 rt Javier 01734984 This week 08092845 Go Broncos! 08092845 Pats-onside 分散化された プロジェクション 00034892 trial results 00034892 ABC's storm 01734984 rt Javier 01734984 This week 08092845 Go Broncos! 08092845 Pats-onside ファクトのデータ Node1 Node2 Node3 ディメンションのデータ 00034892 Carol 01734984 Jim 08092845 Kim 00034892 Carol 01734984 Jimmy 08092845 Kim 00034892 Carol 01734984 Jimmy 08092845 Kim 00034892 Carol 01734984 Jimmy 08092845 Kim 複製された ／分散化されていない プロジェクション
- 21. 分散化されたプロジェクションと複製されたプロジェクション – ファクトを分散化、ディメンションを複製 – サンプルクエリ SELECT * FROM fact F JOIN dim D ON F.id = D.id; – サンプルプロジェクション 21 CREATE PROJECTION fact_p ( a ENCODING RLE, b ENCODING RLE, c ENCODING RLE, id ) AS SELECT a, b, c, id FROM fact ORDER BY id, a, b, c SEGMENTED BY HASH(id) ALL NODES; CREATE PROJECTION dim_p ( x ENCODING RLE, y ENCODING RLE, z, id ) AS SELECT x, y, z,id FROM dim ORDER BY id, x, y UNSEGMENTED ALL NODES;
- 22. Identically Segmented プロジェクション（ISP） – ファクトとディメンションテーブルのどちらもサイズが大きい場合、両プロジェクションの結合キーで分散化すると、 主キー／外部キーで結合された行が同じノードに格納される 22 FK1 FK2 FK3 FKでハッシュ分散された 大きいファクト FK1 FK2 FK3 PKでハッシュ分散された 大きいディメンション 大きいディメンション 大きいファクト Node1 Node2 Node3 PK1 PK2 PK3 PK2PK1 PK3
- 23. ISP の例 – ファクトとディメンションテーブルのどちらもサイズが大きい場合、両プロジェクションの結合キーで分散化すると、 主キー／外部キーで結合された行が同じノードに格納される 23 00034892 trial results 00034892 ABC's storm 01734984 rt Javier 01734984 This week 08092845 Go Broncos! 08092845 Pats-onside FKでハッシュ分散された 大きいファクト 00034892 trial results 00034892 ABC's storm 01734984 rt Javier 01734984 This week 08092845 Go Broncos! 08092845 Pats-onside PKでハッシュ分散された 大きいディメンション 大きいディメンション 大きいファクト Node1 Node2 Node3 00034892 Carol 01734984 Jim 08092845 Kim 01734984 Jim00034892 Carol 08092845 Kim
- 24. Identically Segmented プロジェクション –ファクトとディメンションの JOIN 句の列で分散化 –サンプルクエリ SELECT * FROM fact F JOIN dim D ON F.id = D.id; –サンプルプロジェクション 24 CREATE PROJECTION fact_p ( a ENCODING RLE, b ENCODING RLE, c ENCODING RLE, id ) AS SELECT a, b, c, id FROM fact ORDER BY id, a, b, c SEGMENTED BY HASH(id) ALL NODES; CREATE PROJECTION dim_p ( x ENCODING RLE, y ENCODING RLE, z, id ) AS SELECT x, y, z,id FROM dim ORDER BY id, x, y SEGMENTED BY HASH(id) ALL NODES;
- 25. ネットワーク演算子 – 結合対象のデータがローカルで利用できない場合、データはネットワークオペレーションを必要とし、実行時に再 分散される – 該当するネットワークオペレーションを実行計画から探す – BROADCAST（各ノードにデータの完全な一時コピーを配布） Access Path: +-JOIN HASH [LeftOuter] [Cost: 40K, Rows: 10K (NO STATISTICS)] (PATH ID: 1) Inner (BROADCAST) | Join Filter: (T1.a > T2.y) | Materialize at Output: T1.b | Execute on: All Nodes – RESEGMENT（各ノードに ISP の一時セグメントを配布） Access Path: +-JOIN HASH [Cost: 639, Rows: 10K (NO STATISTICS)] (PATH ID: 1) Inner (RESEGMENT) | Join Cond: (T1.a = T2.y) | Materialize at Output: T1.b | Execute on: All Nodes 25
- 26. GROUP BY の最適化
- 27. GROUP BY の最適化 – 最適化された GROUP BY 演算子の設計 – GROUP BY PIPE もしくは GROUP BY HASH のプロジェクションの作成 – LOCAL GROUP BY の設計 – 各 GROUP が一つのみのノードで実行されるように分散化 27
- 28. GROUP BY HASH 演算子 – SELECT count(*) FROM cust GROUP BY cust.state; – ハッシュテーブルは、結果セットがユーザーに返される前に、完全に構築される必要あり 28 CA MA AL CA DE AL MA DE 値 Count ハッシュマップ （メモリ上に格納） cust.state（未ソート） CA 12 MA AL DE 1 1 1 2 2 2 ユーザーへ返す
- 29. GROUP BY PIPE 演算子 – SELECT count(*) FROM cust GROUP BY cust.state; – 使用メモリが少なく、 GROUP BY HASH より高速 29 cust.state（ソート済） C 12BCount( ) = ユーザーへ返す AL AL CA CA DE DE MA MA
- 30. GROUP BY PIPE – GROUP BY PIPE は、大量のデータもしくは多数のグループを集計するために必要不可欠 – タプルの数を無限にストリーミング可能 – グループの合計数は問題ではない – 選択的な述語がある場合、代わりにその述語を最適化 – 等価の述語は GROUP BY PIPE の前に実行される – GROUP BY PIPE の出力はソート済 – クエリの実行計画で、 GROUP BY 演算子を探す – GROUP BY HASH もしくは GROUP BY PIPELINED 30
- 31. GROUP BY PIPE の最適化 – GROUP BY 句に指定される全ての列は、プロジェクションで最初に ORDER BY 句に指定される必要あり – サンプルクエリ SELECT count(*) FROM cust GROUP BY a, b, c; – サンプルプロジェクション CREATE PROJECTION cust_p ( a ENCODING RLE, b ENCODING RLE, c ENCODING RLE, d, e ) AS SELECT a, b, c, d, e FROM cust ORDER BY a, b, c SEGMENTED BY HASH(d) ALL NODES; 31
- 32. DISTRIBUTED GROUP BY – データがノード間でランダムに分散されている場合、 GROUP BY 実行のためにデータを再分散する必要あり – GROUP BY の列で際分散 – 各グループが一つのノードのみに存在する場合、どうなるか？ – GROUP BY の列で再分散することにより達成される – クエリの実行計画が再分散を表示 – Distributed Group By の場合、 RESEGMENT GROUP を表示 32
- 33. LOCAL GROUP BY の最適化 – Group By の列で分散化 – サンプルクエリ SELECT count(*) FROM cust GROUP BY a, b, c; – サンプルプロジェクション CREATE PROJECTION cust_p ( a ENCODING RLE, b ENCODING RLE, c ENCODING RLE, d, e ) AS SELECT a, b, c, d, e FROM cust ORDER BY a, b, c SEGMENTED BY HASH(a, b, c) ALL NODES; 33
- 34. GROUP BY の再分散 – SEGMENTED BY HASH(a,b) ALL NODES と指定されたプロジェクションで、下記 GROUP BY がクエリに指定 されている場合 – GROUP BY a – Group By に指定されていないセグメンテーションの値があることにより、再分散が必要 – GROUP BY a,b – 実行時に再分散は必要なし – GROUP BY a,b,c – 実行時に再分散は必要なし – GROUP BY a+1,b – 列 a の式により、再分散が必要 34
- 35. COUNT DISTINCT
- 36. Count Distinct の最適化 – GROUP BY PIPE と同様 – サンプルクエリ SELECT a, count(distinct b) FROM cust GROUP BY a; – サンプルプロジェクション CREATE PROJECTION cust_p ( a ENCODING RLE, b ENCODING RLE, c ENCODING RLE ) AS SELECT a, b, c FROM cust ORDER BY a, b SEGMENTED BY HASH(a, b) ALL NODES; 36
- 37. Approximate Count Distinct – 誤差は +/-1% であり、97 %の時間短縮 – ユーザーが指定した精度を保持 – 結果はロールアップ可能。たとえば、時間毎のものを日毎に – 個別の値は、各ノードに存在する必要なし – より効率的にメモリを使用し、結果がより速く返される SELECT a, APPROXIMATE_COUNT_DISTINCT (b) FROM cust GROUP BY a; 37
- 38. 相関列
- 39. 相関列 – 別の列のデータへの相対出現頻度が高い場合、列の相関関係は、2つの列の位置関係で決まる – これらの列をプロジェクションのソート順で隣り合わせにすることにより、列の相関を実装する 39
- 40. 相関列：最適化されていない場合 40 zipcode lastname firstname state 30004 James Eliza GA 33126 Baker Hubert FL 33126 Bhatnagar Gadin FL 55303 Olivier Alice MN 55343 Flint William MN 77050 Cunningham Theodore TX 77070 Dasgupta Ekanta TX 77070 Quian Cheng TX 94304 Venkatesan Nadish CA 97002 Huang Daoming OR 97006 Lin Liang OR
- 41. 相関列：最適化されている場合 41 state zipcode lastname firstname GA 30004 James Eliza FL 33126 Baker Hubert FL 33126 Bhatnagar Gadin MN 55303 Olivier Alice MN 55343 Flint William TX 77050 Cunningham Theodore TX 77070 Dasgupta Ekanta TX 77070 Quian Cheng CA 94304 Venkatesan Nadish OR 97002 Huang Daoming OR 97006 Lin Liang
- 42. カーディナリティが高い列
- 43. カーディナリティが高い列の参照 – SELECT Address FROM cdr_table WHERE Number='978-263-4563'; 43 問題： 列 Number は、カーディナリティが高い ため、RLEが有効でない
- 44. カーディナリティが高い列の分割（1/3） – Area_Code と呼ばれる新しい列を作成し、並べる – SELECT COUNT (distinct Number)=1,300万 の場合、 SELECT COUNT (distinct Area_Code)=約3,600件 となるような 新しい列を作成 44
- 45. カーディナリティが高い列の分割（2/3） – プロジェクションのソート順に新しい列を追加 – ORDER BY Area_Code, Number . . . – SQL文の述語に追加した列を追加 – 元のクエリ SELECT Address FROM cdr_table WHERE Number='978-263-4563'; – 新しいクエリ SELECT Address FROM cdr_table WHERE Number='978-263-4563' and Area_Code='978'; 45
- 46. カーディナリティが高い列の分割（3/3） – 良い点 – カーディナリティの低い列は、ソート順の最初の方で他のカーディナリティの低い述語に使われている列と混合可能 – 悪い点 – テーブル、プロジェクション、クエリを編集する必要あり 46
- 47. 本章のまとめ – インクリメンタルモードでのデータベースデザイナー – JOIN の最適化 – GROUP BY の最適化 – COUNT DISTINCT – 相関列 – カーディナリティが高い列 47
Editor's Notes
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.
- An incremental design type may be employed some time after the Comprehensive design to provide additional queries to Vertica that should be considered for optimization. インクリメンタルデザインは、コンプリヘンシブデザインを実行した後に、最適化した方がよいと考えられるクエリを Vertica に追加したい場合に、実行されるのがよいでしょう。 This process may (but not always) result in additional incremental projections being created when the existing design does not provide optimal query performance. この処理において、既存のプロジェクションでは最適なクエリパフォーマンスを出せない場合に、（常にではないですが）追加のクエリスペシフィックプロジェクションが作成されます。 There is not always a one-to-one ratio between new queries and new projections. Sometimes the DBD may create a single new incremental projection that may serve several new queries, if they use the same table. 新規の各クエリに対して、1対1でプロジェクションが必ずしも新規作成されるわけではありません。時には、いくつかのクエリが同じテーブルを参照している場合、 DBD はいくつかの新規クエリに対応する1つの新規クエリスペシフィックプロジェクションを作成するかもしれません。 Encourage experimentation in a test environment to see what happens, so that they can consider the tradeoff between performance and the extra file space required for any extra projections created to meet the needs of the newly added query optimizations. パフォーマンスと、クエリ最適化のニーズを満たすために新たに追加作成された任意の余分なプロジェクションに必要な余分なディスク容量との間のトレードオフを考慮するために、テスト環境で実験して起こりうる内容を確認することをお勧めします。 Note: A good rule-of-thumb is to provide no more than 10-15 queries in the list for an incremental optimization. However, up to 100 queries may be provided. 注意： 経験則として、インクリメンタルデザインの最適化のリストには、10～15以下のクエリを適用するのがよいとされています。しかしながら、最大100程度までのクエリは適用されうるでしょう。
- The query file provided to the DBD will be parsed for syntax errors, but not other errors, so make sure the queries are solid. DBD に与えられたクエリファイルは、クエリが均質であることを確認するために、文法エラーがチェックされます。 Theoretically, a comprehensive run can take an unlimited number of queries, but it is best to keep it around 100 or less. For incremental, go with around 10 or less. 理論的には、コンプリヘンシブモードで実行する際のクエリ数の上限はありませんが、100本以下におさえるのが最善です。インクリメンタルモードの場合、10以下におさえるのがよいでしょう。 You can cheat the DBD by repeating important queries so that the DBD identifies a common pattern and is more likely to optimize against that. DBD が共通のパターンを識別し、そのパターンに対してより最適化するように、重要なクエリを繰り返すことにより、 DBD を誤魔化すことが可能です。 It is very important to include predicates. It doesn't matter if A = 15, it is simply important that A is searched on. 述語を含むことが非常に重要です。A=15 などでも問題ありません。A で検索されているということが大切です。
- Encourage backups of all these scripts after each run of the DBD for archival purpose. This can provide a way to restore to a previous design if there are deployment issues with new design or for any other reason that it might be desirable to get back to previous design. アーカイブ目的で、 DBD の各実行後に全てのこれらのスクリプトをバックアップすることを奨励します。これをすることにより、新しいデザインでデプロイメントに問題があった場合や、他の理由で以前のデザインに戻したいという場合に、過去のデザインにリストアすることが可能になります。 There are three deployment-related scripts at this location: このディレクトリ以下に、デプロイに関連する3つのスクリプトが作成されます： [designName]_deploy.sql: Contains entire Comprehensive design script. Creates new projections Refreshes the new projections Drops projections from previous design [designName]_ design.sql: Contains a the DDL to create the new projections only. It does not refresh or drop any projections. Included as the create portion of the deploy script [designName]_ projection_backup_[sequencNumber].sql: Contains a script to re-create the design that existed prior to running the deploy script. Created projections in the backup script are the ones being dropped in the deploy script. [designName]_deploy.sql: コンプリヘンシブデザインのスクリプト 新規プロジェクションの作成 新規プロジェクションのリフレッシュ 以前のデザインからのプロジェクションの削除 [designName]_ design.sql: 新規プロジェクションの作成用の DDL のみ。Refresh コマンドや Drop コマンドは含まれません。 デプロイ用スクリプト内の Create 文のみ [designName]_ projection_backup_[sequencNumber].sql: デプロイ用スクリプトを実行する前に定義されていたデザインを再作成するためのスクリプト このバックアップスクリプト内で作成されるプロジェクションが、デプロイ用スクリプトで削除対象となります。
- This shows running the deployment script from vsql or a command prompt. このスライドは、 vsql あるいはコマンドプロンプトからのデプロイメントスクリプトの実行方法を示しています。 New Note added for 7.0 All nodes should be up when running the deployment script since this will allow creation of buddy projections. 7.0で追加された新しい注意点 デプロイメントスクリプトの実行時、バディープロジェクションの作成をするため、全ノードが起動していなければいけない。 When you run deployment script in MC, you must save it with Export Design button or Save button - otherwise when you deploy, the script gets deleted MC 上でデプロイメントスクリプトを実行する場合、 Export Design ボタン、あるいは、 Save ボタンを使って、それを保存する必要があります。さもなければ、デプロイすると、スクリプトは消去されてしまいます。
- It is possible that there were known issues with the sample data that you can resolve now. サンプルデータで、すぐに解決可能な既知の問題があるかもしれません。 The cardinality of the sample may have been off, causing DBD to make one decision about encoding, but you want to change it. DBD にエンコーディングに関して1つの決定をさせるために、サンプルのカーディナリティが有効でなかったかもしれません。そのため、それを変更したいとします。 Order by could be altered if you know of, but did not have examples of, additional queries that could be run. ORDER BY については、サンプルクエリには含まれなかったが実行されうる追加のクエリをあなたが分かっていれば変更できるでしょう。 Segmentation could be changed if you want to set up for local joins or group by. セグメンテーションについては、ローカル結合や Local Group By が実行されるように設定したい場合は、変更されうるでしょう。 These topics are covered later in the Advanced Query Performance Design topic and they will understand better why to look at these sections and how to detect where additional optimization may be possible before running the deployment script. これらのトピックについては、後半の上級クエリパフォーマンス設計でのトピックで説明されるでしょう。その際、これらのセクションを見る理由や、デプロイメントスクリプトが実行される前に追加の最適化の可能性がある箇所の特定の仕方について、よりよく理解するでしょう。 Notes: In general, for incremental optimization, the ORDER BY clause in projection DDL should follow the ORDER BY clause of a query to cause the data to be grouped on each node before being aggregated by the initiator to reduce processing time of the query by the initiator node. Keep in mind that the DDL being viewed may either the superprojection or an incremental projection design to support another query. So, be cautious when modifying the ORDER BY clause in the DDL to optimize for a specific query. By doing so, you may adversely impact the optimization of another query. Consider MODULARHASH to distribute data more evenly than HASH (which distributes data using a normal statistical distribution). Use MODULARHASH if you can hash segment your data using a column with a regular pattern, such as a sequential unique identifier. The DBD in 6.1.2 utilizes MODULARHASH. 注意： 一般的に、クエリ固有の最適化のために、イニシエーターノードによるクエリの処理時間を減らすために、イニシエーターによって集約される前に各ノード上でデータが集約されるように、プロジェクションの DDL の ORDER BY 句はクエリの ORDER BY 句に準ずるべきである。 表示されている DDL が、他のクエリをサポートするためのスーパープロジェクションもしくはクエリスペシフィックプロジェクションのいずれかであるということを覚えておいてください。そのため、特定のクエリを最適化するために、 DDL の ORDER BY 句を編集する際に注意が必要です。そうすることで、他のクエリの最適化に悪影響を与えるかもしれません。 HASH（通常の統計的分布を使用してデータを分散）よりもより均一にデータを分散させるために、 MODULARHASH を使うことを検討してください。連続した一意の識別子のような規則的なパターンを持つ列を使うデータをハッシュ分散する際に、 MODULARHASH を使ってください。6.1.2の DBD では、 MODULARHASH が使われるようになっています。
- Database Designer Logging Projection Data HP Vertica 7.1 allows you to log information about the projections that the Optimizer recommends. Database Designer considers these projections when creating a design. HP Vertica stores this information in two Data Collector (DC) tables: DC_DESIGN_PROJECTION_CANDIDATES DC_DESIGN_QUERY_PROJECTION_CANDIDATES When you enable logging and start Database Designer, the Optimizer proposes a set of ideal projections based on the options that you specify. The logs contain information about: Whether or not the projections are actually created when the design is deployed. How projections are optimized. Whether the projections are created with and without the ideal criteria that the Optimizer identified. If you do not deploy the design immediately, review the logs to determine if you want to change the design and proposed projections. If Database Designer deployed the design, you can still manually create some of the projections that Database Designer did not create in the deployed design. By default, logging the Database Designer design data is disabled. To enable it, turn on the configuration parameter DBDLogInternalDesignProcess: => SELECT SET_CONFIG_PARAMETER('DBDLogInternalDesignProcess','1');
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.
- In this example, we will look at joining the fact table purchases to the dimension table customers. The fact table projection purchases is not sorted on the cust_id column that we will use to join it with the dimension table customer. The dimension table projection customer is also not sorted on the join column cust_id . Because neither projection is sorted, Vertica will create the join by hashing the dimension projection customer into memory. It will then scan through the Fact (outer) projection purchases for matches and creating an output tuple as each match is found. When the join is complete, the entire contents of the join is sent to the Initiator node to be aggregated with the join results from the other nodes. For join in which the inner (dimension table) is small, a hash join can be OK. However, for joins between very large tables, the resulting hash table can be very large, using lots of memory…or even running out of memory and spilling to disk, which is even worse than just a memory-based hash.
- In this example, we have projections for the fact (outer) table purchases and the dimension (inner) table customers that we want to join on the cust_id. Because both projections have been ordered by the column cust_id, Vertica can join the individual tuples and send them to the initiator node as the joins are made. Vertica does not need to create a hash table to accomplish this. When this situation occurs, Vertica selects a MERGE JOIN as the operation used to bring the data together. This will be shown in the query plan on the join step. Additional Information: It is not possible to force Vertica to perform a MERGE JOIN using a hint or notation in the query. The Vertica optimizer must choose this more efficient join methodology based upon seeing optimally designed projections. If the dimension table is small and not sorted by the join column, Vertica may perform a SORT MERGE JOIN on the dimension data to sort it in memory by the join key. When, this happens, the optimizer may choose to do the join between the projections using a MERGE JOIN instead of a HASH JOIN.
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.
- Facilitator Keys Now, let's start to discuss the Vertica Analytics Platform. These are the 6 specific things that make Vertica, Vertica as we discussed earlier.