Apuri she ji_gaido_detaxue_chu_she_ji__v1.2
•Download as PPTX, PDF•
0 likes•27 views
vertica, dwh, データウェアハウス
Recommended
More Related Content
Similar to Apuri she ji_gaido_detaxue_chu_she_ji__v1.2
Similar to Apuri she ji_gaido_detaxue_chu_she_ji__v1.2 (20)
More from Kaito Tonooka
More from Kaito Tonooka (13)
Apuri she ji_gaido_detaxue_chu_she_ji__v1.2
- 2. 更新履歴 版 日付 変更者 変更内容 備考 1.0 2017年10月16日 大林 加奈子 初版発行 1.1 2018年4月18日 大林 加奈子 関連ページにリンク先を更新 1.2 2018年7月4日 大林 加奈子 リンク更新 ※注意点 社外に提示する際は、本スライド(更新履歴)を削除し、PDF化 してお渡しください
- 3. Agenda データ削除・更新設計に関するチェックポイント VerticaでのDELETE処理の概要説明 データ削除処理の種類と最適なデータ削除設計 データ更新処理の種類と最適なデータ更新設計 デリートベクターのモニタリングと物理削除処理設計 DELETEに最適化するためのプロジェクション設計 Replay Deleteの仕組みと最適化設計 関連ページ
- 4. データ削除・更新設計に関するチェックポイント • YESの場合：次のチェックポイントへ • NOの場合：「データ削除処理の種類と最適なデータ削除設計」へ • 判断できない場合：「VerticaでのDELETE処理の概要説明」へ 大量のデリートベクターが生成されないア プリケーションの仕組みになっています か？ • YESの場合：次のチェックポイントへ • NOの場合：「データ削除処理の種類と最適なデータ削除設計」へ バッチ処理などで、DELETEのかわりに、 DROP_PARTITIONやTRUNCATE TABLEを効果的 に使えるシステムになっていますか？ • YESの場合：次のチェックポイントへ • NOの場合：「データ更新処理の種類と最適なデータ更新設計」へ 単一のUPDATE文・MERGE文が大量に発行さ れないように、バッチでデータを更新する 仕組みになっていますか？
- 5. データ削除・更新設計に関するチェックポイント • YESの場合：次のチェックポイントへ • NOの場合：「デリートベクターのモニタリングと物理削除処理設計」へ 手動発行のDELETE文などで意図せず大量のデリートベク ターが発生してしまうようにシステムの場合、デリートベ クター数をモニタリングし、PURGEの手動発行などでシス テムを正常化できるようになっていますか？ • YESの場合：次のチェックポイントへ • NOの場合：「DELETEに最適化するためのプロジェクション設計」へ プロジェクションはDELETEに最適化されていますか？ • YESの場合：終了 • NOの場合：「Replay Deleteの仕組みと最適化設計」へ MergeoutやRecovery処理が処理速度に問題なく処理されて いますか？
- 7. VerticaでのDELETE処理とは？ VerticaでのDeleteは論理削除 Deleteされたデータは、直ちには削除されず、「Deleted」としてマークされ、デリートベク ターに情報が保持される - デリートベクターは、どこでいつ行がDeleteされたのかを記録しているシステムテーブル（位置とエ ポック情報を保持） - REDOログやUNDOログのようなものは存在しない Deleteされたデータは最初はクエリの結果セットに含まれ、ユーザーに実行結果が返される 前に削除される 大量の個別のDELETE文でレコードを削除するよりも、バッチ処理で、サブクエリやINリスト を含む一つのステートメントでの削除を推奨 7
- 8. 8 DELETE FROM テー ブル WHERE A=1; A B C B CA CA B A C A 1 pen B 2 apple A C 1 pen 2 apple X X データファイル 位置情報 エポック 1 1234 デリートベクター 位置情報 エポック 1 1234 デリートベクターデータファイル テーブル プロジェクション DELETE処理の流れ
- 9. 9 SELECT * FROM テーブル; A B C B CA CA B A C A 1 pen B 2 apple A C 1 pen 2 apple X X データファイル 位置情報 エポック 1 1234 デリートベクター 位置情報 エポック 1 1234 デリートベクターデータファイル テーブル プロジェクション B A C B 2 apple DELETEされたデータを持つテーブルに対するSELECT処理の流れ
- 11. データ削除方式 単一行（少量） 削除 バルク削除 パーティション 削除 全データ削除 SQL文 DELETE FROM テー ブル名 DELETE /*+DIRECT*/ FROM テーブル名 SELECT DROP_PARTITION(‘ テーブル名’,値) TRUNCATE TABLE テーブル名 ロールバックの可 否 可能 可能 不可能 不可能 ロックの種類 Exclusive（X）ロッ ク Exclusive（X）ロッ ク Owner（O）ロック Owner（O）ロック 処理性能 プロジェクション 設計に依存 プロジェクション 設計に依存 高速(*) 高速(*) 使用用途 頻繁な間隔で起こ る小さな削除 ひとつのSQL文で一 括で削除 月単位、日単位な どで過去のデータ を削除 データ入れ替えのた めなどのために全 データ削除 ※テーブル定義情報は保 持される (*) カタログ情報の削除の後、バックグランドで ストレージ情報は削除されるため
- 12. col1 col2 col3 1 A pen 2 B apple col1 col3 1 pen 2 apple Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 位置情報 エポック 1 1234 位置情報 エポック 1 1234 デリートベクターA1 デリートベクターA2 DELETE FROM テー ブルA WHERE COL1=1; col1 col2 col3 1 A pen 2 B apple col1 col3 1 pen 2 apple Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 ①ユーザーがDELETE文を テーブルAに対して実行 する。 ②内部的に、データファイ ルが編集されるのではなく、 デリートベクター情報が WOS（メモリ）上に作成さ れる。 単一行（少量）削除時の流れ
- 13. col1 col2 col3 1 A pen 1 AA pen col1 col3 1 pen 1 pen Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 位置情報 エポック 1 1234 2 1234 位置情報 エポック 1 1234 2 1234 デリートベクターA1 デリートベクターA2 DELETE /*+DIRECT*/ FROM テーブルA WHERE COL1=1; col1 col2 col3 1 A pen 1 AA pen col1 col3 1 pen 1 pen Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 ①ユーザーがDELETE文を DIRECTオプション付で テーブルAに対して実行 する。 ②内部的に、データファイ ルが編集されるのではなく、 デリートベクター情報が ROS（ディスク）上に作成 される。 バルク削除時の流れ
- 14. 201701 1 1234 201701 2 2345 201701 1 201701 2 YYYYMM char(6), Col1 int, Col2 int テーブルA プロジェクション A1 プロジェクションA2 SELECT DROP_PARTITION( テーブル A,’201701’); YYYYMM char(6), Col1 int, Col2 int テーブルA プロジェクションA1 プロジェクションA2 ①ユーザーが DROP_PARTITION関数を テーブルAに対して実行 する。 ②DROP_PARTITION関数内で 指定したキーに該当する ファイルが物理削除される。 201702 9 9876 201702 9 YYYYMM Col1 Col2 YYYYMM Col1 201702 9 9876 201702 9 YYYYMM Col1 Col2 YYYYMM Col1 削除対象 削除対象パーティション削除時の流れ
- 15. col1 col2 col3 1 A pen 1 AA pen col1 col3 1 pen 1 pen Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 TRUNCATE TABLE テーブルA; col1 col2 col3 col1 col3 Col1 int, Col2 char(1), Col3 char(5) テーブルA プロジェクションA1 プロジェクションA2 ①ユーザーがTRUNCATE をテーブルAに対して実 行する。 ②関連するすべてのデータ が物理削除される。（ただ し、プロジェクション定義 等の定義情報は残る。） 全データ削除時の流れ
- 16. 手順概要 1. DELETEのWhere句で指定する値を一時テーブル にロードする。 2. DELETEのWhere句で指定する値のデータを持つ 一時テーブルと、削除するデータを持つテーブ ルと結合して、1つのDELETE文で行を削除する。 実行例：複数の従業員のレコード（従業員ID）を削 除する場合 1. 従業員IDを格納する一時テーブルを作成する。 2. 削除対象の従業員ID一覧データを挿入する。 3. DELETEのWhere句で指定する従業員IDの値のデータを 持つ一時テーブルと、削除するデータを持つテーブル を結合してひとつのDELETE文で行を削除する。 4. 作成した一時テーブルを削除する。 => CREATE LOCAL TEMP TABLE data_to_delete (emp_id INT); => COPY data_to_delete FROM '/tmp/employee_to_delete.txt' ; => DELETE /*+ direct */ FROM store.store_orders_fact WHERE employee_key IN (SELECT * FROM data_to_delete ); => DROP TABLE data_to_delete ; バルク削除実行例
- 17. 事前準備 1. 該当のテーブルに対して、パーティションキー を設定したテーブルを作成しておく。 手順概要 1. DROP_PARTITION関数を使って、該当のパーティ ションキーのデータを削除する。 事前準備例： 1. 年月をパーティションキーに設定したテーブル を作成する。 実行例：2016年10月分のデータを削除す る場合 1. DROP_PARTITION関数を使って、2016年10月分 （2016*12 + 10=24202）のデータを削除する。 => CREATE TABLE dates (year INTEGER NOT NULL, month VARCHAR(8) NOT NULL) PARTITION BY year * 12 + month; => SELECT DROP_PARTITION('dates', '24202'); DROP_PARTITION ------------------- Partition dropped (1 row) パーティション削除実行例
- 20. 更新処理の処理実装案 ポイント：デリートベクターを増大させないため、 UpdateやDelete文の実行回数をなるべく減らす 20 発生データ 一時テーブル 本番テーブル ①発生データを一時 テーブルへロードする。 ②本番テーブルから更 新対象のレコードを DELETEする。 ③一時テーブルから本 番テーブルへデータを INSERT-SELECTでロード する。 [コマンド例] delete /*+ DIRECT */ from 本番 where exists(select 'X' from TEMP B where 本番.COL1 = B.col1 and 本番.col2 = B.col2); [コマンド例] insert /*+ DIRECT */ into本番 select * from TEMP; [コマンド例] copy TEMP from [ソースファイルのパ ス] DIRECT;
- 22. デリートベクターが物理削除されるタイミング 1. Mergeoutの自動実行・手動実行時 1. Tuple Moverのmergeoutは、デフォルトで10分（MergeOutInterval）に一度、閾値（ROSPerStratum）を超え るプロジェクションに対して実行される。 2. 下記コマンドで、mergeoutを手動実行する。 22 パラメーター デフォルト値 MergeOutInterval 600秒 Tuple Moverがmergeoutを実行するために新しいROSファイルをチェックする間隔を 秒で指定 ROSPerStratum 32 階層内のROSコンテナの数。階層がデフォルト値の32に達すると、プロジェクショ ンはmergeout実行対象となる PurgeMergeoutPercent 20％ Tuple Moverがmergeout中にROSをPurgeする前に、Deleteされうる行数の最大パーセ ント MaxDVROSPerContainer 10 単一のROSコンテナに関連するデリートベクターの数がこの値に達すると、Tuple Mover mergeout処理は、デリートベクターをマージする => select do_tm_task(‘mergeout’,’テーブル名 or プロジェクション名’);
- 23. デリートベクターが物理削除されるタイミング 2. Purgeコマンドの手動実行時 1. AHMを進める。（PurgeはAHM以前のデータが対象となる。） 2. Purgeコマンドをテーブル、プロジェクション、あるいはパーティション単位で実行する。 1. データベース全体 2. テーブル単位 3. プロジェクション単位 4. パーティション単位 23 => select make_ahm_now(); => select PURGE(); => select PURGE_PROJECTION(‘プロジェクション名’); => select PURGE_PARTITION(‘テーブル名’,パーティションキー); => select PURGE_TABLE(‘テーブル名’);
- 24. デリートベクターのモニタリング DELETE_VECTORSシステムテーブル - クエリ例：プロジェクションごとのデリートベクターの行数一覧 STORAGE_CONTAINERSシステムテーブル - クエリ例：プロジェクションの全行数に対してデリートベクターの行数が5％を超えるプロジェク ション名一覧 24 SELECT distinct schema_name, projection_name, deleted_row_count, total_row_count FROM storage_containers WHERE deleted_row_count > total_row_count * .05::FLOAT ORDER BY deleted_row_count DESC; SELECT schema_name, projection_name, sum(deleted_row_count) FROM delete_vectors GROUP BY 1, 2 ORDER BY 3 DESC;
- 25. デリートベクターとエポックの関係 エポック名 説明（要チェック） Current Epoch(CE） Current epoch（現在のエポック）は、COMMIT操作後の最後のエポック（LE）になるオープン状態のエ ポックです。 COMMIT時のcurrent_epochは、そのDMLのエポックです。 Latest Epoch（LE） Latest epoch（最新のエポック）は、一番最後に閉じたエポックです。 COMMIT操作後のcurrent epoch（ 現在のエポック）は、latest epoch（最新のエポック）になります。 Last Good Epoch（LGE) すべてのノードで最小のチェックポイントエポックは、last good epoch（最後の正常なエポック）とし て知られています。 Last good epochとは、手動リカバリで回復できる最新のエポックを指します。 Ancient History Mark（AHM) Ancient history markは、それより前の履歴データを物理ストレージからpurgeすることができるエポック です。 AHMの前に履歴クエリを実行することはできません。 25
- 26. Deleteされたデータの物理ファイルが削除されるまでの動き AHMが1000、LGEが1005で、5件Delete済みの状態であるとする Closed Epochs Current Epoch 10071006100510041003100210011000… 1008 AHM データファイル STORAGE_OID エンコード済デー タ 81340698561 kldfjajdoiuaeojk 81340698562 ajhfaowetadka;92 81340698574 345ohiklnfma;lkf[ 81340698580 09d8k4ljm.3-08jo 81340698580 ujv4l3nk46jkluz78 81340698590 akljda[078 df-98q3 81340698592 nmt;obijaf[0-895j 81340698593 'puiw[0-8563p4jo 81340698597 f[p034975023iu5 81340698598 badjhadfkhal9233 デリートベクター STORAGE_OID DV_OID Epoch 81340698562 209456198 1001 81340698580 209456200 1002 81340698590 209456203 1004 81340698593 209456204 1006 81340698598 209456204 1006 LGE x x x x
- 27. Deleteされたデータの物理ファイルが削除されるまでの動き AHMが1005に進み、AHMより前に存在するDeleteされたデータは物理削除対象となる Closed Epochs Current Epoch 10071006100510041003100210011000… 1008 データファイル STORAGE_OID エンコード済デー タ 81340698561 kldfjajdoiuaeojk 81340698562 ajhfaowetadka;92 81340698574 345ohiklnfma;lkf[ 81340698580 09d8k4ljm.3-08jo 81340698580 ujv4l3nk46jkluz78 81340698590 akljda[078 df-98q3 81340698592 nmt;obijaf[0-895j 81340698593 'puiw[0-8563p4jo 81340698597 f[p034975023iu5 81340698598 badjhadfkhal9233 デリートベクター STORAGE_OID DV_OID Epoch 81340698562 209456198 1001 81340698580 209456200 1002 81340698590 209456203 1004 81340698593 209456204 1006 81340698598 209456204 1006 AHM x x x x
- 28. Deleteされたデータの物理ファイルが削除されるまでの動き AHMより前に存在するDeleteされたデータが物理削除され、新しいファイルが作成される Closed Epochs Current Epoch 10071006100510041003100210011000… 1008 新しいデータファイル STORAGE_OID エンコード済デー タ 81340698561 kldfjajdoiuaeojk 81340698574 345ohiklnfma;lkf[ 81340698580 ujv4l3nk46jkluz78 81340698592 nmt;obijaf[0-895j 81340698593 'puiw[0-8563p4jo 81340698597 f[p034975023iu5 81340698598 badjhadfkhal9233 新しいデリートベクター STORAGE_OID DV_OID Epoch 81340698593 209456204 1006 81340698598 209456204 1006 AHM x x x x
- 30. DELETEに最適化するためのテーブル・プロジェクション設計 テーブル設計 - DROP_PARTITION関数でデータを削除できるように、テーブルをパーティション化を使用してデータを グループ毎に分ける。 プロジェクション設計 - DELETEを発行する対象のテーブルにひもづく全てのプロジェクションにDELETE文のWhere句で指定す る列を含める。 - たとえば、time_keyのようなよくDELETE文のWHERE句に指定されるカラムがある場合、すべての関連 プロジェクションのORDER BY句にtime_keyを入れるようにする。 - ソート順の終わりにカーディナリティの高い列を使用する。 （注）システム構築前に実行されうるDELETE文のパターンが予測できない場合、システム構築後で あっても、EVALUATE_DELETE_PERFORMANCE関数を実行することにより、DELETEに最適化すべきプロ ジェクションを確認し、必要に応じて、プロジェクションを再構築することが可能 30
- 31. Clickstreamテーブルの年月カラムに対し て、DROP_PARTITIONを実行する際の実行 クエリ例 Clickstreamテーブルのテーブル設計例 => select DROP_PARTITION(‘Clickstream’,’201 6’); CREATE TABLE clickstream ( tdate DATE NOT NULL, user VARCHAR(20), URL VARCHAR(100), … ) PARTITION BY EXTRACT (year FROM tdate); 2016年のデータを全て削除。Rollback不可 だが、デリートベクターは生成されず、 ファイルがただちに物理削除されるため、 システムパフォーマンスに悪影響を与え ることはない。 パーティションキーの指定に関数も使 用可能。ただし、パーティションキー ごとにROSコンテナが生成されるため、 ROSコンテナのノード・プロジェク ション毎の上限値1024を超えないよう に指定するカラムを決める必要あり。 DELETEに最適化するためのテーブル設計例
- 32. tテーブルに対するDELETEの実行クエリ例 tテーブルのプロジェクション設計例 32 => DELETE from t WHERE a = 1; => DELETE from t WHERE b = 1; CREATE TABLE t (a INTEGER, b INTEGER, c INTEGER); CREATE PROJECTION p1 (a, b, c) AS SELECT * FROM t ORDER BY a; CREATE PROJECTION p2 (a, b) AS SELECT a, b FROM t ORDER BY b, a; たとえば、WHERE句にカラムaとカラムb を指定するケースがあるとする。 すべての関連プロジェクションに、カラ ムaとカラムbを含むように設計すること により最適化される。 DELETEに最適化するためのプロジェクション設計例
- 33. DELETEに最適化するためのプロジェクション設計例 DELETEに最適なプロジェクションのソート順 1. 下記のように、たとえば、time_keyのようなよくDELETE文のWHERE句に指定されるカラムがある場 合、すべての関連プロジェクションのORDER BY句にtime_keyを入れるようにする。 2. 各プロジェクションのORDER BY句に指定したカラムの組み合わせに対する行が一意、あるいは、小 さい行セットとなるように指定する。 システム構築時に実行されうるDELETE文が予測できない、あるいは、システム構築後に DELETE文の発行のされかたが変わってしまったような場合、EVALUATE_DELETE_PERFORMANCE 関数を実行することにより、DELETEに最適化すべきプロジェクションを確認可能 33 => DELETE from t where time_key < '1-1-2007'; => select evaluate_delete_performance(); evaluate_delete_performance --------------------------------------------------------------------------- The following projection exhibits delete performance concerns: "public"."one_sort" See v_catalog.projection_delete_concerns for more details. (1 row)
- 35. Replay Deleteとは Replay deleteとは、デリートベクターを再構築して、ストレージコンテナ全体のレコードの移 動に適応させるプロセス Replay delete処理は、Tuple Moverのmergeout処理中に行われる - Mergeout処理でレコードを削除したROSコンテナがマージされると、AHMエポック以前に削除された レコードはすべて削除され、 Purgeできないレコードは、新しく作成されたROSコンテナに新しい位置 を持つが、新しいROSコンテナでpurgeされなかった削除されたレコードの位置を指すデリートベク ターを再構築する必要あり。この処理をReplay deleteとよぶ Replay deleteは、ノードのリカバリ、再編成、クラスタからのノードの追加または削除時のリ バランス、およびプロジェクションのリフレッシュ中に実行される 35
- 36. Replay Deleteの仕組み ROSコンテナの統合時に、Purgeされていないデリートベクターについては位置情報を再構築 する 36 位置情報 エポック 3 102 col1 エポック 100 101 200 101 300 101 col1 エポック 40 100 50 100 60 100 位置情報 エポック 3 102 col1 エポック 40 100 50 100 60 100 100 101 200 101 300 101 位置情報 エポック 3 102 6 102 Tuple Mover mergeout ROSコンテナ ROSコンテナ ROSコンテナDVROS DVROS DVROS
- 37. Replay Delete遅延の対応策 Replay Deleteが遅延しているプロジェクションを特定し、該当するプロジェクションのソー ト順（ORDER BY句）の最後にカーディナリティの高い列を追加する 下記コマンドで、replay deleteのパフォーマンスも評価可能 37 => select evaluate_delete_performance(); evaluate_delete_performance --------------------------------------------------------------------------- The following projection exhibits delete performance concerns: "public"."one_sort" See v_catalog.projection_delete_concerns for more details. (1 row)
- 38. 関連ページ Best Practices for Deleting Data （英語） - 上記記事の日本語版はこちら Deletes in Vertica: The FAQs （英語） - 上記記事の日本語版はこちら Understanding Vertica Epochs （英語） - 上記記事の日本語版はこちら Tuple Mover Best Practices （英語） - 上記記事の日本語版はこちら Best Practices for DELETE and UPDATE （英語） 38