Apuri she ji_gaido_puroziekushiyonshe_ji__v1.0
•Download as PPTX, PDF•
0 likes•16 views
vertica, dwh, データウェアハウス
Recommended
More Related Content
More from Kaito Tonooka
More from Kaito Tonooka (7)
Apuri she ji_gaido_puroziekushiyonshe_ji__v1.0
- 2. 更新履歴 版 日付 変更者 変更内容 備考 1.0 2018年7月3日 大林 加奈子 初版発行 ※注意点 社外に提示する際は、本スライド(更新履歴)を削除し、PDF化 してお渡しください
- 3. Agenda プロジェクション設計に関するチェックポイント プロジェクションの概要説明 初期構築時のプロジェクション最適化 追加でのプロジェクション最適化 データベースデザイナーでの最適化手順 手動でのプロジェクション最適化 プロジェクション関連のモニタリング 関連ページ
- 4. プロジェクション設計に関するチェックポイント • YESの場合：次のチェックポイントへ • NOの場合：「プロジェクションの概要説明」へ プロジェクションの概要を理解し ていますか？ • YESの場合：次のチェックポイントへ • NOの場合：「初期構築時のプロジェクション最適化」へ 初期構築時のプロジェクションの 最適化の方法が分かりますか？ • YESの場合：次のチェックポイントへ • NOの場合：「追加でのプロジェクション最適化」へ 追加のプロジェクションの最適化 の方法が分かりますか？
- 5. プロジェクション設計に関するチェックポイント • YESの場合：「データベースデザイナーでの最適化手順」 • NOの場合：次のチェックポイントへ 実際の最適化の手順についての情報 が必要ですか？ • YESの場合：「手動でのプロジェクション最適化」へ • NOの場合：次のチェックポイントへ 手動でのプロジェクションの最適化 の情報が必要ですか？ • YESの場合：「プロジェクション関連のモニタリング」へ • NOの場合：終了 プロジェクション関連のモニタリン グについての情報が必要ですか？
- 7. プロジェクションとは？ 一言でいうと、「マテリアライズドビュー」の概念に近いもの テーブル 論理的 プロジェクション 物理的 Sales_fact_p1 Sales_fact 日付 顧客ID 売上高 0701 10000000001 100 10000000002 480 10000000003 2,500 日付 エリア 店舗 顧客ID 売上高 0701 東京 新宿 10000000001 100 : : : : : 0707 大阪 梅田 10000000005 1,300 Sales_fact_p2 日付 顧客ID 店舗 エリア 売上高 date int varchar(10) varchar(10) Int
- 8. Projection-3 create table table1 (日付 date ,顧客ID(int),店舗 varchar(10),エリアvarchar(10) , 売上高(int)）; プロジェクションとは？ Verticaでは、テーブルは論理スキーマとして定義（実体は持たない） 日付 顧客ID 店舗 エリア 売上高 date int varchar(10) varchar(10) Int 日付 売上高 0701 100 1,000 0702 1,0000 0703 2,400 1,600 6,400 0705 1,000 0706 1,100 1,300 Projection-1 Projection-2 エリア 店舗 日付 売上高 顧客ID 大阪 梅田 0703 2,400 10004 0706 1,100 10008 東京 池袋 0703 1,600 10005 品川 0705 1,000 10007 新宿 0701 100 10001 1,000 10002 0703 6,400 10006 名古屋 名古屋 0702 1,0000 10003 0706 1,300 10009 大阪梅田の平均売上高 7/6の売上 プロジェクションは物理スキーマとして定義（自動ツールによりチューニング） クエリー毎に最適化を事前に行うことも可能 店舗 売上高（SUM) 名古屋 11,300 新宿 7,500 梅田 3,500 池袋 1,600 品川 1,000 店舗別売上ランキング (事前集計プロジェクション)
- 9. 1256678 1254038 1278858 1230807 Student_ID 1210466 1249290 1244262 1252490 1267170 1248100 1243483 1230382 1240224 1222781 1231806 1246648 Cappiello, Emilia Dalal, Alana Orner, Katy Frigo, Avis Name Stober, Saundra Borba, Milagros Sosnowski, Hillary Nibert, Emilia Popovic, Tanisha Schreckengost, Max Porcelli, Darren Sinko, Erik Tarvin, Julio Lessig, Elnora Thon, Max Trembley, Allyson F F F M Gender F F F F F M M M M F M F Sophomore Senior Junior Senior Class Junior Freshman Junior Sophomore Freshman Senior Junior Freshman Sophomore Junior Sophomore Junior 62 92 76 64 Score 90 96 68 59 95 76 67 91 85 63 82 100 D A C D Grade A A D F A C D A B D B A プロジェクション：ツールを使い最適なデータ配置を作成 Example query: select avg( Score ) from example where Class = ‘Junior’ and Gender = ‘F’ and Grade = ‘A’
- 10. 1256678 1254038 1278858 1230807 Student_ID 1210466 1249290 1244262 1252490 1267170 1248100 1243483 1230382 1240224 1222781 1231806 1246648 Cappiello, Emilia Dalal, Alana Orner, Katy Frigo, Avis Name Stober, Saundra Borba, Milagros Sosnowski, Hillary Nibert, Emilia Popovic, Tanisha Schreckengost, Max Porcelli, Darren Sinko, Erik Tarvin, Julio Lessig, Elnora Thon, Max Trembley, Allyson F F F M Gender F F F F F M M M M F M F Sophomore Senior Junior Senior Class Junior Freshman Junior Sophomore Freshman Senior Junior Freshman Sophomore Junior Sophomore Junior 62 92 76 64 Score 90 96 68 59 95 76 67 91 85 63 82 100 D A C D Grade A A D F A C D A B D B A Queryに最適化されたカラム配置に並び替え データ保持イメージ①
- 11. 1256678Cappiello, EmiliaF Sophomore 62D 1254038Dalal, AlanaF Senior 92A 1278858Orner, KatyF Junior 76C 1230807Frigo, AvisM Senior 64D 1210466Stober, SaundraF Junior 90A 1249290Borba, MilagrosF Freshman 96A 1244262Sosnowski, HillaryF Junior 68D 1252490Nibert, EmiliaF Sophomore 59F 1267170Popovic, TanishaF Freshman 95A 1248100Schreckengost, MaxM Senior 76C 1243483Porcelli, DarrenM Junior 67D 1230382Sinko, ErikM Freshman 91A 1240224Tarvin, JulioM Sophomore 85B 1222781Lessig, ElnoraF Junior 63D 1231806Thon, MaxM Sophomore 82B 1246648Trembley, AllysonF Junior 100A Student_IDNameScoreClassGender Grade 並び 替え S O R T データ保持イメージ②
- 12. A D B A Junior Senior Freshman Junior Sophomore Sophomore Junior Junior F F F M F F F F M M M F M F 1256678Cappiello, EmiliaSophomore 62D 1254038Dalal, AlanaSenior 92A 1278858Orner, Katy76C 1230807Frigo, Avis64D 1210466Stober, SaundraJunior 90 1249290Borba, Milagros96 1244262Sosnowski, Hillary68 1252490Nibert, Emilia59F 1267170Popovic, TanishaF Freshman 95A 1248100Schreckengost, MaxSenior 76C 1243483Porcelli, DarrenJunior 67D 1230382Sinko, ErikM Freshman 91A 1240224Tarvin, Julio85 1222781Lessig, Elnora63D 1231806Thon, MaxSophomore 82B 1246648Trembley, Allyson100 Student_IDNameScoreClassGender Grade A 圧縮 エン コー ド データ保持イメージ③
- 13. A D B A Junior Senior Freshman Junior Sophomore Sophomore Junior Junior F F F M F F F F M M M F M F 1256678Cappiello, Emilia62 1254038Dalal, Alana Sophomore Senior 92 1278858Orner, Katy76 1230807Frigo, Avis64 1210466Stober, SaundraJunior 90 1249290Borba, Milagros96 1244262Sosnowski, Hillary68 1252490Nibert, Emilia59 1267170Popovic, TanishaF Freshman 95A 1248100Schreckengost, MaxSenior 76 D C 1243483Porcelli, Darren67 1230382Sinko, ErikM 91 1240224Tarvin, Julio85 1222781Lessig, Elnora63 C D 1231806Thon, Max Junior Freshman Sophomore 82 D A F D A B 1246648Trembley, Allyson100 Student_IDNameScoreClassGender F Grade AJunior Junior Junior Junior Junior A A 90 100 1st I/O Reads entire column 2nd I/O 3rd I/O 4th I/O offset offset 少ないIOで効率的に検索 Example query: select avg( Score ) from example where Class = ‘Junior’ and Gender = ‘F’ and Grade = ‘A’
- 14. プロジェクション最適化ツール：データベースデザイナー（DBD） 最高のパフォーマンスが出せる物理デザインをVerticaが自動で作成 自動で最適なデータ圧縮、列の並び替えを行い、検索を高速化 定型検索に最適なデータ配置を追加で作成することが可能 INDEXの作成は不要 データベースデザイナー による自動チューニングDB管理者 SQL1 SQL2 チューニングを意識して設計 する必要はなく、従来通りの テーブル設計、SQL作成にて 管理が可能となります。 Webベース 対話形式のチューニングツール 圧縮分散 ソート列の並び替え抽出 全てのクエリー向け comprehensiveモード 特定のクエリー向け incremental モード データベースデザイナーにより、データの分散、 必要な列の抽出、列の並び替え、データのソー ティング、最適な圧縮方法選択、を行います。
- 15. プロジェクションの種類 アドホッククエリーから特定のクエリーまでさまざまなクエリに対応 テーブルA テーブルB クエリースペシフィックプロジェクション 特定のクエリーに特化したプロジェクション • データベースデザイナーがクエリーを解析し、クエ リーに最適なプロジェクションを追加作成 １ ２ ３ スーパープロジェクション 全クエリーに汎用的に対応可能なプロジェクション • 初回ロード実行時、自動生成（最適化前） • すべての列を含み、列の型やカーディナリティーを 考慮して、データベースデザイナーが最適化したも のを自動作成 圧 縮 圧 縮 圧 縮 最適な並び替え 最適な並び替え 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 圧 縮 クエリスペシフィックプロジェクション ライブアグリゲートプロジェクション 事前に集計したプロジェクション • 手動で追加作成する必要あり • データロード実行時にGROUP BY処理を実施 ライブアグリゲート プロジェクション Id 毎 Sum Count Max Min Top-K 圧縮 圧縮 ほとんどのお客様のケースでは、スーパープロジェ クションのみで運用いただくケースが多いです。
- 18. デフォルトのデータベースの状態 18 customer （論理的） テーブル （物理的） プロジェクション A B C D customer_p0 最適化されていない スーパープロジェクション CA B D
- 19. 最適化されたデータベースの状態 19 （論理的） テーブル （物理的） プロジェクション customer_p1 最適化されたスーパー プロジェクション customer_p2 クエリスペシフィッ クプロジェクション customer_p3 クエリスペシフィッ クプロジェクション ACCDB customer A B C D customer_p0 最適化された スーパープ ロジェクション C B D A A B C D
- 20. データベースデザイナー 20 サンプルデータ データベース デザイナー デザイン スクリプト デプロイ スクリプト • マネージメントコンソール • admintools • コマンドライン クエリ
- 21. コンプリヘンシブ vs. インクリメンタル デザイン コンプリヘンシブデザイン インクリメンタルデザイン 全テーブルのサン プルデータ データベー スデザイ ナー 複数クエリ（または指定なし） AC CDB C B D A 複数のプロジェクション 関連テーブルのみ のサンプルデータ データベー スデザイ ナー 特定クエリ CDB 特定のプロジェクション
- 23. Comprehensiveチューニング 全てのクエリーを高速化するためのデータベース全体へのチューニング 各列のカーディナリティーなどを考慮して、列の並び替え 性別 クラス 得点 識別番号 名前 男 A 100 00001 AAAAA 男 B 90 00002 BBBBB 女 C 95 00003 CCCCCC 男 A 80 00004 DDDDD 女 B 60 00005 EEEEEE 女 C 70 00006 FFFFFF 女 A 90 00007 GGGGG 男 B 66 00008 HHHHH
- 24. Comprehensiveチューニング カーディナリティーの低いものからソーティング 性別 クラス 得点 識別番号 名前 男 A 100 00001 AAAAA 男 A 80 00004 DDDDD 男 B 90 00002 BBBBB 男 B 66 00008 HHHHH 女 A 90 00007 GGGGG 女 B 60 00005 EEEEEE 女 C 70 00006 FFFFFF 女 C 95 00003 CCCCCC
- 25. Comprehensiveチューニング エンコーディング・圧縮 性別 クラス 得点 識別番号 名前 男 4 A 2 100 00001 AAAAA 80 00004 DDDDD B 2 90 00002 BBBBB 66 00008 HHHHH 女 4 A 1 90 00007 GGGGG B 1 60 00005 EEEEEE C 2 70 00006 FFFFFF 95 00003 CCCCCC
- 26. Comprehensiveチューニング 必要最低限のI/Oで検索の高速化 性別 クラス 得点 識別番号 名前 男 4 A 2 100 00001 AAAAA 80 00004 DDDDD B 2 90 00002 BBBBB 66 00008 HHHHH 女 4 A 1 90 00007 GGGGG B 1 60 00005 EEEEEE C 2 70 00006 FFFFFF 95 00003 CCCCCC
- 27. データベースデザイナー（1/2） 1. データベースデザイナーを実行する前の準備 - テーブルの作成 - サンプルデータのロード - サンプルクエリを1ファイルに集約 2. データベースデザイナーの実行 - コンプリヘンシブ（Comprehensive）モード – 全テーブルに対する最適化されたスーパープロジェク ションと必要に応じてクエリスペシフィックプロジェクションを作成する際に選択 あるいは - インクリメンタル（Incremental）モード – 特定のクエリもしくは一連のクエリで最善のプロジェク ションを作成する際に選択
- 28. データベースデザイナー（2/2） 3. DBD の出力ディレクトリ以下に生成されたファイルの内容を確認 - [デザイン名]_deploy.sql - [デザイン名]_design.sql - [デザイン名]_params.txt - designer.log 4. 最適化されたプロジェクションのデプロイ - [design name]_deploy.sql ファイル内容（DBD が自動設計したプロジェクションの DDL）を確認し、手 動でデプロイ - あるいは - オプションを選択し、 DBD に、 [design name]_deploy.sql ファイルを DBD 実行中に実行することにより、 自動でデザインをデプロイさせる Admintoolsから実行した際の出力ファイルになります。マネー ジメントコンソール上から実行した場合の詳細については 「データベースデザイナーでの最適化手順」を参照ください。
- 29. サンプルデータ 代表的なサンプルデータで DBD 実行 - テーブル毎に最大 10GB 程度を推奨 - データ量と DBD 実行時間は比例の関係 - DBD はデプロイ中に多くの一時領域を使用 - プロジェクション毎に、新規のプロジェクションが作成され、データが投入され、その後に元のプロジェクショ ンが削除される DBD に含ませるサンプルデータは正確に下記の特徴を表す必要あり： - カーディナリティ - 比例関係（テーブルの相対的なサイズ） - 最小値 - 最大値 最初のデータの塊だけ、１ヶ月分のみのデータ、１顧客のみのデータ等を使うというのは避 ける
- 30. サンプルクエリ 様々なタイプのステートメントを含む： - Select - Delete - クエリは構文エラーの解析がされる クエリはグループ化され、類似性に基づいて重み付けされる - 任意のクエリが、 DBD で同じ結果になる場合、それらのクエリはグループ化される - DBD が、より少ない全体的なクエリを処理することを可能にする - 重要なクエリ／述語は比重を重くする
- 31. データベースデザイナー adminTools > Configuration Menu から実行
- 32. データベースデザイナー Optimize for query performance（クエリ性能に最適化） - 各テーブルに候補のプロジェクションのセットを生成 - オプティマイザを呼び出し、候補のプロジェクションのクエリ実行コストを決定し、最小コストのプ ロジェクションを選択 Optimize storage footprint（ストレージ容量に最適化） - 全列において、全エンコーディングと圧縮の組み合わせを試行 - 各列について、最もデータサイズを小さくするエンコーディングと圧縮のタイプを選択 Balanced design（バランスのとれた設計）
- 33. テーブル毎のプロジェクション数は？ プロジェクションは多いほうがいいのか、あるいは、少ない方がいいのか？ - プロジェクション数を増やす－クエリ性能を最適化 - プロジェクション数を減らす－データロードの高速化 - プロジェクション数を減らす－ストレージ容量の縮小 バランスがいいのは？ - テーブルにつき、2～5程度のプロジェクションが最も一般的 - 1もしくは2つのスーパープロジェクション - 1から3つのクエリスペシフィックプロジェクション - より多くのプロジェクションを持つ場合もあり
- 34. DBD を使うメリット 手動チューニングの手間を最小限におさえる スクリプト生成が推奨。必要に応じて変更し、デプロイする クエリを実行する際と同じオプティマイザがプロジェクションを生成する
- 37. Incrementalチューニング 必要な列だけ抽出して、並び替え、エンコーディング・圧縮 クラス 得点 A 100 A 90 A 80 B 90 B 66 B 60 C 95 C 70 クラス 得点 A 3 100 90 80 B 3 90 66 60 C 2 95 70
- 38. Incrementalチューニング 必要な列だけ抽出して、並び替え、圧縮 クラス 得点 A 3 100 90 80 B 3 90 66 60 C 2 95 70 クラス 得点 A 2 100 80 B 2 90 66 A 1 90 B 1 60 C 2 70 95
- 39. インクリメンタルデザイン 追加のクエリチューニングのために、インクリメンタル（Incremental）デザインを実行 - 更に最適化を必要とするクエリを適用 - 適用された各クエリに対して、最適化された追加のプロジェクションが作成されうる
- 40. サンプルクエリ 様々なタイプのステートメントを含む： - Select - Delete クエリは構文エラーの解析がされる クエリの重み付け – 任意の述語のためにプロジェクションを作成する可能性を高めるべく同 様のクエリの述語を繰り返し記載 クエリはグループ化され、類似性に基づいて重み付けされる
- 41. 出力ディレクトリ DBD の出力ディレクトリ以下に生成されたファイルの内容を確認 - [デザイン名]_deploy.sql - [デザイン名]_design.sql - [デザイン名]_params.txt - designer.log Admintoolsから実行した際の出力ファイルになります。マ ネージメントコンソール上から実行した場合の詳細について はAppendixを参照ください。
- 42. デプロイメントスクリプトの手動実行 必要に応じて、デプロイメント DDL スクリプトを変更し、手動でスクリプトを実行する - vsql 上で実行した場合 => i /filepath/[design name]_deploy.sql - Linux のコマンドライン上で実行した場合 $ vsql –f "/filepath/[design name]_deploy.sql" マネージメントコンソール上から実行した場合の詳細についてはAppendix を参照ください。スクリプトを別途保存する必要があります。
- 43. サンプル 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 KSAFE; 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;
- 44. ロギングによる情報 DBDのロギング機能は下記情報を提供 - DBD実行中にオプティマイザが提案したプロジェクション - デザインがデプロイされた際にDBDが作成したプロジェクション - 全プロジェクションを作成するために使われるDDL - 列の最適化 - 下記でロギング開始 => SELECT SET_CONFIG_PARAMETER('DBDLogInternalDesignProcess','1'); 情報を参照するデータコレクター（DC）テーブル - DC_DESIGN_PROJECTION_CANDIDATES - DC_DESIGN_QUERY_PROJECTION_CANDIDATES
- 46. 手順例一覧 1. Management ConsoleでのComprehensiveモードでの実行手順例 2. Management ConsoleでのIncrementalモードでの実行手順例 3. AdmintoolsでのComprehensiveモードでの実行手順例 4. AdmintoolsでのIncrementalモードでの実行手順例
- 48. Management ConsoleでのComprehensiveモードでの実行手順例 1. ブラウザを立ち上げ、マネージメントコンソールのIPアドレスを入力する。（例： https://10.10.10.1:5450/webui/login） 2. マネージメントコンソールのユーザー、パスワードを入力し、ログインする。
- 49. Management ConsoleでのComprehensiveモードでの実行手順例 3. 該当データベースの「Go to database」をクリックする。
- 53. Management ConsoleでのComprehensiveモードでの実行手順例 7. 「Balance Load and Performance」を選択し、「Next」をクリックする。
- 55. Management ConsoleでのComprehensiveモードでの実行手順例 9. K-Safetyが期待する値（1もしくは2）になっていることを確認し、必要に応じて、「Propose Unsegmented Projections」にチェックを入れ、「Next」をクリックします。
- 57. Management ConsoleでのComprehensiveモードでの実行手順例 11. 「Analyze Statistics」にチェックを入れ、「Auto-build」にチェックを入れます。自動で最適 化のプロジェクションを再作成したい場合は、「Auto-deploy」にチェックを入れ、 「Next」をクリックします。 本手順例では、「Auto-deploy」にチェック を入れずに進めます。
- 58. Management ConsoleでのComprehensiveモードでの実行手順例 12. サマリー情報を確認し、問題がなければ、「Submit Design」をクリックします。
- 60. Management ConsoleでのComprehensiveモードでの実行手順例 14. 最適化プロジェクションのデプロイスクリプトをファイル出力するために「Export Design」 をクリックします。
- 61. Management ConsoleでのComprehensiveモードでの実行手順例 15. ダウンロードしたファイルの内容に問題ないか確認後、そのファイルをvsql実行サーバーに 配置し、下記コマンドなどでデプロイを実行します。 $ vsql –f comp_design.sql
- 63. Management ConsoleでのIncrementalモードでの実行手順例 1. ブラウザを立ち上げ、マネージメントコンソールのIPアドレスを入力する。（例： https://10.10.10.1:5450/webui/login） 2. マネージメントコンソールのユーザー、パスワードを入力し、ログインする。
- 64. Management ConsoleでのIncrementalモードでの実行手順例 3. 該当データベースの「Go to database」をクリックする。
- 66. Management ConsoleでのIncrementalモードでの実行手順例 5. 「New Design」をクリックする。
- 69. Management ConsoleでのIncrementalモードでの実行手順例 8. 必要に応じて、「Propose Unsegmented Projections」にチェックを入れ、「Next」をクリッ クします。
- 71. Management ConsoleでのIncrementalモードでの実行手順例 10. 「Analyze Statistics」にチェックを入れ（すでに取得済みの場合は外す）、「Auto-build」に チェックを入れます。自動で最適化のプロジェクションを再作成したい場合は、「Auto- deploy」にチェックを入れ、「Next」をクリックします。 本手順例では、「Auto-deploy」にチェック を入れずに進めます。
- 72. Management ConsoleでのIncrementalモードでの実行手順例 11. サマリー情報を確認し、問題がなければ、「Submit Design」をクリックします。
- 74. Management ConsoleでのIncrementalモードでの実行手順例 13. 最適化プロジェクションのデプロイスクリプトをファイル出力するために「Export Design」 をクリックします。
- 75. Management ConsoleでのIncrementalモードでの実行手順例 14. ダウンロードしたファイルの内容に問題ないか確認後、そのファイルをvsql実行サーバーに 配置し、下記コマンドなどでデプロイを実行します。 $ vsql –f incr_design.sql
- 77. AdmintoolsでのComprehensiveモードでの実行手順例 1. エミュレータで、dbadminユーザーで、ノード#1にSSH接続する。 2. データベースデザイナーのログファイル等の出力ディレクトリを作成し、作成したディレ クトリに移動する。 3. AdminToolsを起動する。 $ mkdir –p /home/dbadmin/DBD/comp $ cd /home/dbadmin/DBD/comp $ /opt/vertica/bin/admintools
- 78. AdmintoolsでのComprehensiveモードでの実行手順例 4. 「6 Configuration Menu」を選択する。 5. 「2 Run Database Designer」を選択する。
- 79. AdmintoolsでのComprehensiveモードでの実行手順例 6. スペースキーを使って、データベースデザイナーを実行す るデータベースを選択する。 7. データベースのパスワードを入力する。 8. データベースデザイナーのアウトプットの出力先ディレク トリを指定する。
- 80. AdmintoolsでのComprehensiveモードでの実行手順例 9. 任意のデザイン名を入力する。 10. 矢印キーとスペースキーを使って、Design Typeに「Comprehensive」を選択する。
- 81. AdmintoolsでのComprehensiveモードでの実行手順例 11. 矢印キーとスペースキーを使って、データベースデザイナーを 実行する対象のスキーマを選択する。（サンプルスキーマを使 用している場合は、「online_sales」「public」「store」を選択 する。） 12. 全てのオプションをチェックしたままにする。（最適化するク エリが存在しない場合は、スペースキーを使って、「Optimize with queries」のチェックを外します。） デプロイスクリプトの内容を確認してからvsqlなどで デプロイしたい場合は、「Deploy design」のチェッ クを外します。
- 83. AdmintoolsでのComprehensiveモードでの実行手順例 15. 矢印キーとスペースキーを使って、「Balanced query/load performance」を選択する。 16. 矢印キーで「Proceed」を選択し、データベースデザイ ナーの実行を開始する。
- 84. AdmintoolsでのComprehensiveモードでの実行手順例 17. データベースデザイナーの実行が終了したら、Enterを押して完了する。 18. AdminToolsを終了する。
- 86. AdmintoolsでのIncrementalモードでの実行手順例 1. エミュレータで、dbadminユーザーで、ノード#1にSSH接続する。 2. データベースデザイナーのログファイル等の出力ディレクトリを作成し、作成したディレ クトリに移動する。 3. AdminToolsを起動する。 $ mkdir –p /home/dbadmin/DBD/incr $ cd /home/dbadmin/DBD/incr $ /opt/vertica/bin/admintools
- 87. AdmintoolsでのIncrementalモードでの実行手順例 4. 「6 Configuration Menu」を選択する。 5. 「2 Run Database Designer」を選択する。
- 88. AdmintoolsでのIncrementalモードでの実行手順例 6. スペースキーを使って、データベースデザイナーを実行す るデータベースを選択する。 7. データベースのパスワードを入力する。 8. データベースデザイナーのアウトプットの出力先ディレク トリを指定する。
- 89. AdmintoolsでのIncrementalモードでの実行手順例 9. 任意のデザイン名を入力する。 10. 矢印キーとスペースキーを使って、Design Typeに「Incremental」を選択する。
- 90. AdmintoolsでのIncrementalモードでの実行手順例 11. 矢印キーとスペースキーを使って、データベースデザイナー を実行する対象のスキーマを選択する。（最適化したいクエ リが参照するスキーマを選択する。） 12. 全てのオプションをチェックしたままにする。 デプロイスクリプトの内容を確認してからvsqlなどで デプロイしたい場合は、「Deploy design」のチェッ クを外します。
- 92. AdmintoolsでのIncrementalモードでの実行手順例 15. 矢印キーとスペースキーを使って、「Balanced query/load performance」を選択する。 16. 矢印キーで「Proceed」を選択し、データベースデザイ ナーの実行を開始する。
- 94. 手動プロジェクション設計概要 データの定義 - 列をリスト ストレージフットプリントを最小化 - エンコーディングもしくは圧縮を適用 クエリパフォーマンスに最適化 - ランレングス符号化（RLE）を適用 - ソート順の最適化 並列処理できるようにデータを分散化 - セグメンテーションの定義 SEGMENTED BY CREATE ORDER BY SELECT
- 95. 含めるべき列 クエリに必要とされる全ての列を含む - Deleteの述語も含む ソーステーブルの列のサブセットである可能性あり クエリが実行された際、テーブルごとに1つのプロジェクションのみクエリ応答に使われる SEGMENTED BY CREATE projection snmp_p1 ( host encoding rle, interface encoding rle… ORDER BY SELECT
- 96. エンコーディング 対 圧縮 エンコーディング - あるフォーマットから別のフォーマットへ情報を変換する処理 - エンコード済データは、ディスク容量を節約 - 最初にデコードせずに、エンコード済データを処理可能 圧縮 - より少ないビット情報で符号化情報を処理 - 圧縮済データは、ディスク容量を節約 - 処理前に解凍される必要あり SEGMENTED BY CREATE projection snmp_p1 ( host encoding rle, interface encoding rle… ORDER BY SELECT
- 97. 一般的な圧縮とエンコーディングの種類 圧縮 ／エンコーディング形式 使用タイミング 例 ランレングス符号化 （RLE） 低いカーディナリティの値を並び替え （値毎に少なくとも10個連続したレ コード） 郵便番号、記号、市外局番 差分符号化 （DELTAVAL） 高いカーディナリティの整数を並び替 え シーケンス番号、プライマリーキー ブロック符号化 （BLOCK_DICT） 未ソート、低いカーディナリティの整 数、日付、タイムスタンプ、浮動小数 （ORDER BYの前にはない） 在庫量 デルタ圧縮 （COMMONDELTA_COMP） 一定の期間毎に増加する値 周期 可逆データ圧縮アルゴリズム （LZO） 高いカーディナリティ、部分的に並び 替えもしくは並び替えられていない文 字列／可変長の文字列 値段 RLEはストレージフットプリントを最小化し、クエリパフォーマンスを最適 化するために有効であるため、できる限りRLE設定を検討する
- 98. プロジェクションのソート順の決定 ORDER BY 文で： 1. クエリの述語から開始 - カーディナリティの低いものから高いものへ述語を並び替え - ソート順で列をランレングス符号化（RLE） 2. JOIN、かつ／または、GROUP BY に基づき列を並び替え - カーディナリティの低いものから高いものへ JOIN、かつ／または、GROUP BY の列を並び替え 3. 平均ランレングスが10未満になるまで残りの列を並び替え SEGMENTED BY CREATE SELECT ORDER BY host, interface, metric, time
- 99. プロジェクションのセグメンテーション サイズの大きいテーブルを分散化し、サイズの小さいテーブルを複製 ランダムなデータ分散のためにセグメンテーション用の列の選択 - 相対的に一意の値を含む列 - クエリの述語での使用頻度が低い列 JOINがローカルで処理されるように分散 - 最も一般的なのは、分散化されたファクトテーブルを複製されたディメンションテーブルにJOIN - サイズの大きいディメンションテーブル、ファクト同士のJOIN、自己結合については、Identically Segmented プロジェクション（ISP）を使うことを検討 SEGMENTED BY hash (host, interface) ALL NODES OFFSET 0; CREATE SELECT ORDER BY
- 100. セグメンテーション句 SEGMENTED BY HASH - ノード間でデータを均等に分 散 - 一意の値が80%より多く、ラン ダムであるべき - クエリの述語に出てくる列に は使用しない - セグメンテーションに適した 列もしくは列の組み合わせが ない場合、新たにセグメン テーション用に列を作成 ALL NODES {OFFSET N} - ALL NODES - ALL NODES OFFSET 1 ALL NODES KSAFE - ALL NODES OFFSET 0の プロジェクションとALL NODES OFFSET 1のプロ ジェクションを作成することと 等価（k=1の場合） - 全く同じバディープロジェク ションを作成するために使用 SEGMENTED BY hash (host,interface,time,metric) ALL NODES KSAFE;
- 101. ハッシュ関数 ノードは、セグメンテーション式の値の範囲を格納 SEGMENTED BY hash (host, interface, time, metric) 0 264 ノード 1 ノード 2 ノード 3 = 4718658032094123622 ノード 2へマップ hash ("vertica.com", "eth0", 6300000, "184.106.12.19")
- 103. ランレングス符号化 – どう処理されるか？ 同じ値が連続するように、ランレングス符号化済の列を並び替え 各「バケット」が、以降の列の行のセットにマッピング 一つの列のクエリ述語は、他の列のデータ読み込みを限定 F M Fresh Junior Senior Soph Fresh Junior Senior Soph F F F F T T T T F F F F T T T T Gender Class Pass Name SELECT Name FROM Students WHERE Class='Junior' and Gender='M' and Pass='T'
- 104. ランレングス符号化 – 停止タイミング ソート順に列を追加し、平均繰り返し回数が10未満になるまで、RLEの適用を継続 バケット毎に繰り返し回数を決定するために： - プロジェクションの定義： … ORDER BY gender, class, pass; - SELECT count(*) FROM students GROUP BY gender, class, pass; RLEでこれ以上の効果が望めないと判断した場合、他の列に対しての他のエンコーディングや 圧縮のオプションを検討
- 105. ランレングス符号化 – 停止タイミング RLEの繰り返し回数が10未満 375 93.7 46.8 2.5 (350) (400) (50) (100) (100) (100) (100) (100) (100) (100) (25) (50) (50) (50) (25) (50) (50) (50) (50) (50) (50) (50) (50) (50) (50) (50) Gender Class Pass Name SELECT Name FROM Students WHERE Class='Junior' and Gender='M' and Pass='T' 平均:
- 107. ライブアグリゲートプロジェクションとは アンカーテーブル内の列を用いて計算された列の値を含むプロジェクション アンカーテーブルより、Delete、Update、Merge不可 デフォルトで有効 データロード時に更新される
- 111. ライブアグリゲートプロジェクションの階層（4/4） A B C CAB 集計されたプロジェクション のベースとなる通常のプロ ジェクションは最低一つ必要 アンカーテーブ ルは必須 CAB 7.2以前：LAPに対してのみクエリ実行可能 7.2以降：テーブルに対してもクエリ実行可能 ライブアグリゲートプロジェ クションは1つの通常のプロ ジェクションをベースとして 作成される E = A G G D = A G G アンカーテーブル ベースプロジェクション ライブアグリゲートプロジェクション
- 112. ライブアグリゲートプロジェクションの作成 1. アンカーテーブルを作成する。 CREATE TABLE clicks(user_id INTEGER, page_id INTEGER, click_time TIMESTAMP NOT NULL; 2. アンカープロジェクションを作成する。 CREATE PROJECTION clicks_anchorp AS SELECT * FROM clicks SEGMENTED BY HASH(user_id) ALL NODES KSAFE; 3. ライブアグリゲートプロジェクションを作成する。 CREATE PROJECTION clicks_agg AS SELECT user_id, page_id, click_time::DATE click_date, COUNT(*) num_clicks FROM clicks GROUP BY user_id, page_id, click_time::DATE;
- 113. ライブアグリゲートプロジェクションの要件 アンカープロジェクションは、アンカーテーブルのすべての列を含む必要があり、k-safeが維 持される必要あり アンカープロジェクションのセグメンテーションは、ライブアグリゲートプロジェクション のセグメンテーションのサブセットである必要あり ライブアグリゲートプロジェクションのSELECTリスト内にある列のリストは、GROUP BY句に ある列のリストの並び順と同一である必要あり ライブアグリゲートプロジェクションのSELECTリストの始めにGROUP BYの列を配置する必要 あり GROUP BYとPARTITION BY句は、アンカープロジェクションのセグメンテーションに含まれる 必要あり GROUP BY句が含まれ、CREATE PROJECTION文の最後にある必要あり ORDER BY句や、サブクエリ、OFFSET句は使用不可
- 114. サポートされる集計関数 ライブアグリゲートプロジェクションでは、下記集計関数のみ利用可能 - SUM [Aggregate] - MAX [Aggregate] - MIN [Aggregate] - COUNT [Aggregate]
- 115. Top-K プロジェクション Top-Kプロジェクションは、ライブアグリゲートプロジェクションの一種 選択された行のパーティション毎に上位k個の行を取得するクエリのパフォーマンスを向上さ せるために使用
- 116. Top-K プロジェクションの例 Top-K のクエリ例 SELECT meter_id, reading_date, reading_value FROM readings LIMIT 5 OVER (PARTITION BY meter_id ORDER BY reading_date DESC); meter_idで構成されるTop-Kプロジェクションを作成し、各ガスメーター用の最新の5つのメー ター測定値を格納 CREATE PROJECTION readings_topk (meter_id, recent_date, recent_value) AS SELECT meter_id, reading_date, reading_value FROM readings LIMIT 5 OVER (PARTITION BY meter_id ORDER BY reading_date DESC);
- 117. Top-K プロジェクションの要件 ライブアグリゲートプロジェクションの要件に順ずる Top-Kプロジェクションは、LIMIT、OVER、PARTITION BY、ORDER BY句を含む必要あり OVER()句内で、PARTITION BY句にORDER BY句のみ使用可能 SELECTリストに、PARTITION BYとORDER BY句の列も含まれる必要あり PARTITION BY句は、アンカープロジェクションのセグメンテーションに含まれる必要あり Top-Kプロジェクションは、ORDER BY NULLS FIRST/LASTをサポート
- 119. JOIN の最適化 オプティマイザが理想的な JOIN 演算子を選択するようにプロジェクションを設計 - ハッシュ結合もしくはマージ結合するようにプロジェクションを作成 ネットワークオペレーションの最小化 - 各 JOIN がローカルで実行できるように、結合キーでプロジェクションを分散 JOIN の実行時間を完全に排除 - フラッタンテーブルの使用 - 外部で非正規化 11 9
- 120. ハッシュ結合演算子 最も一般的な JOIN 演算子 – 特別な最適化は不要 ハッシュテーブルはディメンション（内部）テーブル上に構築される ファクト（外部）テーブルがスキャンされ、ディメンションテーブルの行と一致する行は結 果セットとして出力される purchases_fact_p (date, item列でソート) customer_dim_p (last_nameでソート) last_name cust_id Adams 10202 Benn 10201 Cobb 10203 ハッシュテーブル (メモリ上) タプルを出力 不一致 date Item cust_id 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
- 121. ハッシュ結合 – Join Spill ハッシュテーブルがメモリに収まらない場合、結合処理はディスクに書き込みを開始 - ファクトとディメンションの両方がディスクに書き込まれる 初めはクエリはメモリに収まるようにするが、収まらない場合、 Join Spill が有効化され、ク エリを自動的に再実行 クエリがスピルされることが想定される場合、ヒント文を追加し、メモリへのハッシングを スキップ SELECT /*+add_vertica_options(EE,ENABLE_JOIN_SPILL)*/ … 再試行を検出するために、 PROFILE 文の実行もしくは vertica.log のチェック 12 1
- 122. マージ結合演算子 ディメンションテーブルがメモリに収まらない場合、マージ結合の使用を推奨 両テーブルがメモリを介してストリーミングされるため、大きいテーブル同士の 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 Eraser 10/6/14 Benn10202 Fork 10/5/14 Adams10203 Cup 10/7/14 Cobb
- 123. マージ結合の要件 JOIN している両側のデータが結合キーとなる列でソートされている必要あり - プロジェクションにおいて、結合キーで並び替え - ORDER BY 句でサブクエリ内で並び替え 等価の述語は、マージ結合のサイズを減らすために、最初に実行される（JOIN を下に押し下 げ） - オプティマイザは、最初に、クエリの述語に使われている列にあわせて設計されたプロジェクション を探す - クエリが列に対して単一の値の等価の述語を持つ場合にのみ、述語の列は、プロジェクションの ORDER BY で最初に配置される ディスクへの書き込みを避けるために、大きいディメンションテーブルに対して推奨 12 3
- 124. マージ結合の最適化 ファクトとディメンションの両プロジェクションを JOIN 句の列で並び替え サンプルクエリ SELECT * FROM Fact F, Dim D WHERE F.id = D.id; サンプルプロジェクション 12 4 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;
- 125. Predicate Pushdown を伴うマージ結合 述語で列をフィルターすることにより、ファクトのプロジェクションを並び替え 続いて、ファクトとディメンションの両プロジェクションの JOIN 句の列で並び替え サンプルクエリ SELECT * FROM Fact F, Dim D WHERE F.id = D.id AND f.a = 10; サンプルプロジェクション 12 5 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;
- 126. 結合演算子の確認 クエリの実行計画で、 結合演算子を探す - JOIN HASH - JOIN MERGEJOIN vertica.log ファイルを確認する - ハッシュテーブルがメモリに収まらない場合、 vertica.log で ENABLE_JOIN_SPILL 付きのクエリが再実行 されていることを確認する 12 6
- 127. クエリの最適化 – ネットワークオペレーション ローカル結合の要件 - ファクトとディメンションテーブルで一致する行が同じノード上にある 分散化されたファクトと複製されたディメンションの結合 - ファクト： SEGMENTED BY HASH (id) ALL NODES; - ディメンション： UNSEGMENTED ALL NODES; Identically Segmented プロジェクション - 両プロジェクションが結合キーで分散化されている イニシエーターノード上で、最終結果が集計される 12 7
- 128. ローカル結合の設計 小さなディメンションのプロジェクションを複製し、大きなファクトのプロジェクションを 分散化 12 8 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 複製された ／分散化されていない プロジェクション
- 129. 分散化されたプロジェクションと複製されたプロジェクション ファクトを分散化、ディメンションを複製 サンプルクエリ SELECT * FROM fact F JOIN dim D ON F.id = D.id; サンプルプロジェクション 12 9 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;
- 130. Identically Segmented プロジェクション（ISP） ファクトとディメンションテーブルのどちらもサイズが大きい場合、両プロジェクションの 結合キーで分散化すると、主キー／外部キーで結合された行が同じノードに格納される 13 0 FK1 FK2 FK3 FKでハッシュ分散された 大きいファクト FK1 FK2 FK3 PKでハッシュ分散された 大きいディメンション 大きいディメン ション 大きいファクト Node1 Node2 Node3 PK1 PK2 PK3 PK2PK1 PK3
- 131. ISP の例 ファクトとディメンションテーブルのどちらもサイズが大きい場合、両プロジェクションの 結合キーで分散化すると、主キー／外部キーで結合された行が同じノードに格納される 13 1 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
- 132. Identically Segmented プロジェクション ファクトとディメンションの JOIN 句の列で分散化 サンプルクエリ SELECT * FROM fact F JOIN dim D ON F.id = D.id; サンプルプロジェクション 13 2 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;
- 133. ネットワーク演算子 結合対象のデータがローカルで利用できない場合、データはネットワークオペレーションを必要とし、実行時に再 分散される 該当するネットワークオペレーションを実行計画から探す - 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 13 3
- 135. GROUP BY の最適化 最適化された GROUP BY 演算子の設計 - GROUP BY PIPE もしくは GROUP BY HASH のプロジェクションの作成 LOCAL GROUP BY の設計 - 各 GROUP が一つのみのノードで実行されるように分散化 13 5
- 136. GROUP BY HASH 演算子 SELECT count(*) FROM cust GROUP BY cust.state; ハッシュテーブルは、結果セットがユーザーに返される前に、完全に構築される必要あり 13 6 CA MA AL CA DE AL MA DE 値 Count ハッシュマップ （メモリ上に格納） cust.state （未ソート） CA 12 MA AL DE 1 1 1 2 2 2 ユーザーへ返す
- 137. GROUP BY PIPE 演算子 SELECT count(*) FROM cust GROUP BY cust.state; 使用メモリが少なく、 GROUP BY HASH より高速 13 7 cust.state （ソート済） C 12BCount( ) = ユーザーへ返す AL AL CA CA DE DE MA MA
- 138. GROUP BY PIPE GROUP BY PIPE は、大量のデータもしくは多数のグループを集計するために必要不可欠 - タプルの数を無限にストリーミング可能 - グループの合計数は問題ではない - 選択的な述語がある場合、代わりにその述語を最適化 - 等価の述語は GROUP BY PIPE の前に実行される GROUP BY PIPE の出力はソート済 クエリの実行計画で、 GROUP BY 演算子を探す - GROUP BY HASH もしくは GROUP BY PIPELINED 13 8
- 139. 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; 13 9
- 140. DISTRIBUTED GROUP BY データがノード間でランダムに分散されている場合、 GROUP BY 実行のためにデータを再分 散する必要あり - GROUP BY の列で際分散 各グループが一つのノードのみに存在する場合、どうなるか？ - GROUP BY の列で再分散することにより達成される クエリの実行計画が再分散を表示 - Distributed Group By の場合、 RESEGMENT GROUP を表示 14 0
- 141. 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; 14 1
- 142. 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 の式により、再分散が必要 14 2
- 144. 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; 14 4
- 145. Approximate Count Distinct 誤差は +/-1% であり、97 %の時間短縮 ユーザーが指定した精度を保持 結果はロールアップ可能。たとえば、時間毎のものを日毎に 個別の値は、各ノードに存在する必要なし より効率的にメモリを使用し、結果がより速く返される SELECT a, APPROXIMATE_COUNT_DISTINCT (b) FROM cust GROUP BY a; 14 5
- 147. フラッタンテーブル（Flattened Tables）とは 非正規化したテーブルの作成やメンテナンスを簡素化 スタースキーマのJOIN処理と比較し、高速パフォーマンスを実現 フラッタンテーブルへのクエリ処理はJOIN処理無しで実行可能 ディメンションテーブルへの更新が頻繁でない環境に最適 非正規化したデータは、ライセンス量としてはカウントされない 14 7 A B Fact C D Fact_ABDC 正規化された列 非正規化列 正規化されたスタースキーマ 正規化されていないフラッタンテーブル
- 150. チューニング：非正規化したテーブルを作成 15 0 多くのJoin処理 処理コストが高く、遅い！ 高度なチューニングが必要！ Join処理の削減 処理コストが低く、高速！ チューニング不要あるいは削減！ 非正規化 正規化スキーマ 非正規化テーブル＋
- 151. チューニング：非正規化したテーブルを作成 15 1 正規化スキーマ 非正規化テーブル＋ 課題 1. 2ステップのロードが必要 2. D、E、I、Rテーブルで更新があった場合、手動更新が必要
- 153. フラッタンテーブルとは 1. 1ステップのロード 2. D、E、I、Rテーブルに更新があった場合、refresh_columnコマンドで一括更新可能 3. ディメンション（マスター）のカラムとファクトのカラムの関連付けは動的にON/OFF可能 15 3 ディメンション（マスター）群 非正規化テーブル＋
- 154. 従来のテーブル定義 15 4 Cid Name Age 1 Alice 25 2 Bob 30 3 Eve 28 Order_id Cust_id Amount 100 1 15.00 200 1 1000.00 300 2 -50.00 400 3 100.00 500 2 200.00 CREATE TABLE custDim ( cid int PRIMARY KEY, name varchar(20), age int ); CREATE TABLE orderFact ( order_id int PRIMARY KEY, cust_id int, amount numeric; ); ディメンション(マスター） ファクト
- 155. フラッタンテーブルの作成方法（１）Default句 15 5 CREATE TABLE orderFact ( order_id int PRIMARY KEY, cust_id int, cust_name varchar(20) DEFAULT ( SELECT name FROM custDim WHERE custDim.cid = cust_id ), amount numeric; ); Order_id Cust_id Cust_name Amount 100 1 Alice 15.00 200 1 Alice 1000.00 300 2 Bob -50.00 400 3 Eve 100.00 500 2 Bob 200.00 Cid Name Age 1 Alice 25 2 Bob 30 3 Eve 28 • カラムを追加してデフォルト 値を定義 • データロード時に反映される ディメンション(マスター） ファクト CREATE TABLE custDim ( cid int PRIMARY KEY, name varchar(20), age int );
- 156. フラッタンテーブルの作成方法（２）SET USING句 15 6 CREATE TABLE orderFact ( order_id int PRIMARY KEY, cust_id int, cust_name varchar(20) SET USING ( SELECT name FROM custDim WHERE custDim.cid = cust_id ), amount numeric; ); Order_id Cust_id Cust_name Amount 100 1 Alice 15.00 200 1 Alice 1000.00 300 2 Bob -50.00 400 3 Eve 100.00 500 2 Bob 200.00 Cid Name Age 1 Alice 25 2 Bob 30 3 Eve 28 • カラムを追加してSET USING句を 定義 • ロード完了後、 REFRESH_COLUMNSコマンドで 反映する必要あり ディメンション(マスター） ファクト CREATE TABLE custDim ( cid int PRIMARY KEY, name varchar(20), age int );
- 158. プロジェクション作成 DDL（例） SELECT EXAMPLE. gendar , EXAMPLE.class , EXAMPLE.grade , EXAMPLE.score FROM EXAMPLE CREATE PROJECIOTN student_table_P1( gendar ENCODING RLE , class ENCODING RLE , grade ENCODING RLE , score ENCODING DELTVAL ) AS 列の選択＆ 圧縮タイプの指定 実データの指定 ORDER BY EXAMPLE.gendar , EXAMPLE.class , EXAMPLE.grade 列の並び替え SEGMENTED BY HASH(EXAMPLE.class , EXAMPLE.score) ALL NODES; ノードに分散する HASH KEYの指定
- 159. プロジェクションの追加方法 1. プロジェクション作成のためのDDLを実行する。 - i <projection_ddl>.sql - vsql –f <projection_ddl>.sql 2. 新規作成したプロジェクションにデータを投入する。（リフレッシュコマンドの実行） - SELECT start_refresh(); （バックグラウンド） - SELECT refresh(); （フォアグラウンド） リフレッシュの状態の確認方法 - SELECT get_projection_status ('projection_name'); - SELECT * FROM v_monitor.projection_refreshes; リフレッシュが完了すると、新規作成したプロジェクションは自動的にクエリ実行時にオプティ マイザによって選択されるようになる 15 9
- 161. ROSコンテナ数のモニタリング ノード、プロジェクション毎に1024の制限値を超えないようにする => SELECT node_name, projection_schema, projection_name, SUM(ros_count) AS ros_count FROM v_monitor.projection_storage GROUP BY node_name, projection_schema, projection_name ORDER BY ros_count DESC; node_name | projection_schema | projection_name | ros_count -----------------+-------------------+-----------------------------+----- v_vmart_node0001 | public | t11_super | 3 v_vmart_node0001 | public | tab3_super | 2 v_vmart_node0001 | public | tab3_ukcol2 | 2 v_vmart_node0001 | public | shipping_dimension_super | 1 v_vmart_node0001 | public | small_input_impute_super | 1 v_vmart_node0001 | store | store_dimension_super | 1 v_vmart_node0002 | public | small_input_impute_super | 1 v_vmart_node0002 | public | shipping_dimension_super | 1 v_vmart_node0001 | public | small_input_impute1_super | 1 ・・・ 16 1
- 162. データスキュー（データの偏り）のモニタリング データスキューが発生している場合分散キーを見直す必要あり => SELECT ps.node_name, ps.projection_schema, ps.projection_name, ps.row_count FROM v_monitor.projection_storage ps INNER JOIN v_catalog.projections p ON ps.projection_schema = p.projection_schema AND ps.projection_name = p.projection_name WHERE p.is_segmented ORDER BY ps.projection_schema, ps.projection_name, ps.node_name; node_name | projection_schema | projection_name | row_count ----------------+-------------------+------------------------+---------- v_demo_node0001 | online_sales | online_sales_fact_b0 | 5001927 v_demo_node0002 | online_sales | online_sales_fact_b0 | 4999302 v_demo_node0003 | online_sales | online_sales_fact_b0 | 4998771 ・・・ 16 2
- 163. 関連システムテーブル PROJECTIONS: プロジェクション情報のリスト PROJECTION_CHECKPOINT_EPOCHS: チェックポイントエポックがリフレッシュされた際の詳細 情報 PROJECTION_COLUMNS: エンコーディングタイプ、ソート順、統計のタイプ、統計が最後に更 新されたカラムなどのプロジェクションのカラムに関する情報 PROJECTION_DELETE_CONCERNS: データを削除する際にデザインがパフォーマンスの問題を引 き起こす可能性があるプロジェクションのリスト
- 164. 関連ページ Best Practices for Projection Optimization （英語） Query Tuning with Vertica: Dos and Don‘ts （英語） Query Optimization Using Projections （英語） Troubleshooting Vertica Query Performance with System Tables （英語） Physical Schema （英語） Creating a Database Design （英語） 16 4
Editor's Notes
- Facilitator Keys The next 3 slides will walk through step by step the DBD and the importance of the DBD in the overall structure of your database. When preparing to run the DBD, data should be loaded (it is not required but makes more sense to load data) and be a truly representative of all activities including typical insert, select and delete statements. Make sure queries are solid. DBD outputs a sql file containing scripts to create the projections it has decided are needed to optimize the database. You can run DBD against a full data set or sample data set. Run Comprehensive Mode – Can have unlimited queries Incremental Mode – recommend about 100 queries DBD does take a fair amount of resource allocation. Deploying projections – You can review the DBD projections in output or have DBD automatically deploy.
- Facilitator Keys Let's review the files generated in the DBD output directory and what you need to be aware of. The output directory files include: design name]_deploy.sql: contains DDL statements that: Creates new optimized projections for the design you are deploying Refreshes new projections with initial data Drops unused/unoptimized projections being replaced [design name]_design.sql: contains the new design projection definitions [design name]_params.txt file: contains the parameters used in the DBD when creating a specific design designer.log: locate details on any errors or other output generated while running the DBD
- Facilitator Keys Create a representative sample of your data. Sample data should have tables with no more than 10G so if have a 100G table and a 10G table a representative amount would be 10 for the 100G and 1G for the 10G. When loading sample data into Vertica, data should be representative when presenting it to the DBD. Vertica specs dictate 40% free disk space on each node. One of the reasons is a lack of disk space will create issues with the database design through the DBD as it will not have enough disk space to first generate the replacement projection before dropping the replaced projection.
- Facilitator Keys When providing sample queries to the database, it is important to include various statements. The DBD will ignore queries if syntax is incorrect. The comprehensive DBD - unlimited queries. Query specific - About 100 queries. Important to include predicates, it doesn’t matter if A=15, it is simply important that A is searched on. Queries are grouped and assigned a weighted balance for similarity. In the DBD, queries will be clustered that are similar to each other. (It picks one representative from each cluster.) It will give the representative query a weight equal to the cardinality/size of the cluster it belongs to. This allows the DBD to process fewer overall queries making the process faster. NOTE: when using DBD in MC you can choose to use a sample set of queries in a file or choose the option to use the Query Request Table.
- Facilitator Keys The Database designer is accessed through adminTools. In admin tools, select the configuration menu then select run database designer from that menu. You can also use the management console in 7.0. This is a web based interface Comprehensive Design Good idea after initial load of data into Vertica. If your data fundamentally changes over time, it is ideal to run the DBD again. If you rerun a comprehensive design on pre-existing DBD projections, doing so is faster than the first comprehensive design phase. The Database Designer does not encode any data that it already encoded, and it does not optimize projections that it has already optimized for storage. Comprehensive mode allows for, but does not require, a file of commonly run queries. If provided, DBD can also create query specific projections and will optimize superprojections for query and storage performance. DBD in comprehensive mode will drop old projections and replace with newer projections. Incremental Design DBD must be provided with a file containing one or more queries to optimize against. Only adds projections, does not drop projections. (This may affect overall storage footprint because you may have old projections stored in the database that are not used.) If users run the DBD query specific mode many times, it may result in a build up of projections. (DBD does not drop old projections when run in query specific mode.) When the DBD is run, you must select a database, and then one or more schemas within that database to use for analysis. If you want to run the DBD against a single table, you can For Comprehensive or Incremental design, put that table into a new schema and run the DBD against just that schema For Incremental design only, select the schema that currently contains the table and pass select * from <table>; as the query
- Facilitator Keys There are two things to be aware of when you run the DBD. You may want the DBD to optimize for query performance or perhaps optimize the storage footprint. We recommend that you run a balanced design. When optimizing for query performance the DBD creates more query specific projections for each table. (The queries will run faster, but loads will take longer and footprint will be larger.) If you are optimizing or storage footprint, the DBD creates very few projections. (Queries will be slower, loads faster.) Balanced design is recommended. Adjustments can be made by running in query specific mode to improve performance on a select set of queries. Ask How does Vertica optimize the storage footprint when running the DBD? – Answer: Tries every possible encoding and compression type on every column. For each column, selects the encoding and compression type that most reduces the data size. How does Vertica optimize for query performance when running the DBD? – Answer: Generates a set of candidate projections for each table. Invokes the optimizer to determine the query cost of candidate projections and picks the projection with the lowest query cost.
- Facilitator Keys Let's discuss now how many projections per table are ideal. As the slide indicates, the more projections you have the more optimal for query performance, if you have fewer projections the load rates are faster and there is a smaller storage footprint. On the flip slide, the more projections you have, the load rates may be slower and the footprint will be larger. As indicated 2-5 projections per table is common (1-2 superprojections and 1-2 query specific projections)
- Facilitator Keys So what are some of the advantages of utilizing the DBD You do not have to do a lot of the manual tuning that you may have had to do in your old environment. You do not have to deploy what the DBD tells you. You have the ability to add columns, change order by, replicate vs. segment, you have that flexibility. It's a major benefit that the Optimizer runs the DBD and queries. This means that the DBD will truly evaluate your sample queries the exact way the real queries will run.
- 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');
- To build a projection, we will assume we are designing this projection with a specific query or groups of queries in mind. First you will need to choose the columns and then consider the sort order and encoding types that will minimize the projection storage footprint and allow for an efficient query. Finally you will define the projection segmentation, will the projection be segmented or replicated and if its segmented what columns will you segment on. Optional Exercise: using the graphic have students tell you where in the DDL these steps are specified.
- 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.
- Vertica prepends "agg_" to the projection name. DBD does not create live aggregate projections when optimizing for queries. Live aggregated queries must be manually created. Limit to the number of aggregate projections per anchor table since the aggregations are done at load time: Practical limit, but no declared limit. May not need to say anything Requirements You must include a GROUP BY clauses and it must appear at the end of the CREATE PROJECTION statement. When you create a live aggregate projection for a table, HP Vertica automatically aggregates the data from the anchor table and loads it into the live aggregate projection. On subsequent loads through the anchor table, HP Vertica updates both any regular projections and any live aggregate projections associated with the anchor table.
- An anchor table must exist to perform any DML. To create a live aggregate projection, an anchor table must be created through which data can be queried and loaded.
- At least one regular projection must exist to serve as the base for the aggregated projection. Then, a base projection must be created to serve as the anchor projection for the live aggregate projection.
- Finally, the live aggregate projection can be created. It will use a base projection as the source of its data. The live aggregate projection will have some or all of the columns from the base projection. In addition, it will contain one or more aggregate columns. The query in the DDL will contain some type of aggregation SQL to generate the columns and aggregate the data in the aggregated columns.
- Queries containing aggregates are made directly to the Live Aggregate Projection (not the table) Unlike regular projections, queries against live aggregate projections are made directly against the live aggregate projection. Normally, a query is run against a table and the optimizer chooses the projection to be used. In the case of live aggregated queries the table name must be replaced with the name of the live aggregated projections.
- Important: You must create an anchor table and an anchor projection before you create a live aggregate projection. The anchor projection must specify a segmentation that is a subset of the live aggregate projection's segmentation. NOTE: In the DDL, you do not specify this is an anchor table in the conventional way. The query in the DDL of the live aggregate projection (see step 3) is an aggregation query. If you do not specify the segmentation for the anchor projection, HP Vertica creates a projection that is segmented by all columns. If the anchor projection is segmented on all columns, you cannot create a live aggregate projection. You cannot use the ORDER BY clause when you create a live aggregate projection. Internally, the data is ordered on the GROUP BY column. However, when you retrieve the data, the results do not necessarily display in that order. Use the ORDER BY clause to sort the results of querying the live aggregate projection:
- Before you create a live aggregate projection, you must create an anchor projection. The anchor projection's segmentation must be a subset of the live aggregate projection's segmentation. The anchor table cannot be unsegmented. The GROUP BY and PARTITION BY clauses must be supersets of the anchor projection segmentation. Live aggregate projections are only stored in the ROS. Live aggregate projections must be segmented. The list of columns in the SELECT list for a live aggregate projection must be in the same order as the list of columns in the GROUP BY clause.
- HP Vertica supports the following aggregations for live aggregate projections: SUM [Aggregate] Computes the sum of an expression over a group of rows. It returns a DOUBLE PRECISION value for a floating-point expression. Otherwise, the return value is the same as the expression data type. MAX [Aggregate] Returns the greatest value of an expression over a group of rows. The return value is the same as the expression data type. MIN [Aggregate] Returns the smallest value of an expression over a group of rows. The return value is the same as the expression data type. COUNT [Aggregate] Returns the number of rows in each group of the result set for which the expression is not NULL. The return value is a BIGINT. The COUNT() aggregate function is different from the COUNT() analytic function. The COUNT() analytic function returns the number over a group of rows within a window. Live aggregate projections cannot contain DISTINCT aggregates.
- Another type of Live Aggregate projection is a Top K projections. For optimal performance of Top-K queries, create a Top-K projection that aggregates the data in the table for fast access. Querying the pre-aggregated data directly from the Top-K projection is usually faster than querying the data from the anchor table and then calculating the top k rows. Top-K projections are a type of live aggregate projection. All the requirements and limitations for live aggregate projections apply to Top-K projections as well.
- In this slide, we see a top-K query that will bring back meter readings for the past five reading dataes. With a regular projection, the query would need to go into a table that contains all reading dates, then filter out the irrelevant dates. By creating a top-k projection, the data in the projection only contains the data needed by the query. Because the question literally only contains the data needed by the query, the query can simply lift the tuples from the top-k projection without having to do any processing. This will make the query run more quickly. Note: Normally customers may use aggregate queries to get their top k, Vertica recommends an analytical query as it is an analytical database.
- The following considerations are unique to Top-K projections: Top-K projections must include LIMIT, OVER, PARTITION BY, and ORDER BY clauses. In other words, top-k projections inherently are designed to contain a sub-set of the total data in a table. So, you must use one of these organization characteristics to group and limit the data in the projection. When creating a Top-K projection, you can only use an ORDER BY clause on the PARTITION BY clause inside an OVER() clause. The columns in the PARTITION BY and ORDER BY clauses must also be in the SELECT list. The PARTITION BY clause must be a superset of the anchor projection segmentation. In other words, if segmenting the top-k projection, you must only segment the anchor projection to the higher columns in the segmentation clause of the top-k projection. You cannot use a PARTITION AUTO clause when creating a Top-K projection. Partitioning of top-k projection must indicate a specific column or expression. You cannot use the DISTINCT keyword in a Top-K projection definition. Top-K projections support ORDER BY NULLS FIRST/LAST.
- 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.