vertica, dwh, データウェアハウス

1. アプリケーション設計ガイド
DBメンテナンス設計
バージョン9.1, Enterprise mode
作成日：2018年7月3日
更新日：2018年XX月XX日
1

2. 更新履歴
版 日付 変更者 変更内容 備考
1.0 2018年7月3日 大林 加奈子 初版発行
※注意点
社外に提示する際は、本スライド(更新履歴)を削除し、PDF化
してお渡しください

3. Agenda
 DBメンテナンス処理に関するチェックポイント
 VerticaでのDBメンテナンス処理の概要説明
 DBメンテナンス処理の種類と最適なDBメンテナンス設計
 DBメンテナンス処理のモニタリング
 関連ページ

4. DBメンテナンス処理に関するチェックポイント
•YESの場合：次のチェックポイントへ
•NOの場合：「VerticaでのDBメンテナンス処理の概要説明」へ
Verticaのデータベースで必要なメン
テナンス処理について把握されてい
ますか？
•YESの場合：次のチェックポイントへ
•NOの場合：「DBメンテナンス処理の種類と最適なDBメンテナンス設計」へ
DBメンテナンス処理について最適
に設計されていますか？
•YESの場合：終了
•NOの場合：「DBメンテナンス処理のモニタリング」へ
DBメンテナンス処理関連のモニタ
リング方法について把握されていま
すか？

5. VerticaでのDBメンテナンス
処理の概要説明
5

6. VerticaでのDBメンテナンス処理の概要説明
 Verticaでは、DBメンテナンスという観点で、下記2点の処理実装の検討が必要
- 統計情報の更新
- Tuple Mover（Moveout/Mergeout）
Vertica#1 Vertica#2 Vertica#3 Vertica#4 Vertica#5
Data#1 Data#2 Data#3 Data#4 Data#5
Read Optimized Store（ROS）
Data#1
Data#2
Data#3
Data#4
Data#5
ソースデータ
Write Optimized Store（WOS）
Data#1 Data#2 Data#3 Data#4 Data#5
• ディスク上
• ソート済／圧縮済
• 分散化
• 大量データを直接ロード
• メモリ上
• 未ソート／非圧縮
• 分散化
• 低レイテンシ／少量で短時
間のInsert
どちらにも
ロード可能TUPLE MOVER(Moveout)
非同期データ転送

7. 統計情報更新とは
 オプティマイザが、最も効率的な実行計画を決定するために、定期的な実行が必要
 正確な統計情報が保持されることにより、オプティマイザの次のような決定に寄与
- クエリに応答する最適なプロジェクションの選択
- 結合を実行する最適な順序の選択
- 最適な結合、最適なGROUP BYの選択
- ブロードキャストや再分配などのデータ再分散アルゴリズムの最適な選択
 正確な統計情報が保持されない場合、オプティマイザは、クエリに対して最適ではないプロジェクショ
ンや結合順序を選択してしまう可能性あり
 統計情報更新により下記の情報を取得
- 各カラムの行数
- 各カラムの異なる値の数（カーディナリティ）
- 各カラムの最大値・最小値
- 各カラムのヒストグラム
7

8. Tuple Mover - moveout
MoveoutはWOSからROSへデータを非同期に移動させる内部処理
メモリー（WOS:Write Optimized Store)
メモリー上では、データは行単位で置かれる（未圧縮）
日付 顧客ID 店舗 エリア 売上高
0706 10001 横浜 神奈川 9,999
0706 10002 新宿 東京 3,000
日付 顧客ID 店舗 エリア 売上高
0706 10001 横浜 神奈川 9,999
0706 10002 新宿 東京 3,000
日付 顧客ID 店舗 エリア 売上高
0707 10001 横浜 神奈川 7,777
0707 10002 新宿 東京 9,000
日付 顧客ID 店舗 エリア 売上高
0707 10001 横浜 神奈川 7,777
0707 10002 新宿 東京 9,000
日付 売上高
0706 9,999
3,000
0707 7,777
9,000
エリア 店舗 日付 売上高 顧客ID
神奈川 横浜 0706 9,999 10001
0707 7,777 10001
東京 新宿 0706 3,000 10002
0707 9,000 10002
ディスク（ROS:Read Optimized Store) ディスクへ定期的にマージされながら、移動される（Moveout)
日付 売上高
0706 12,999
0707 16,777
Moveout

9. Tuple Mover - moveout
日付 売上高
0701 100
1,000
0702 1,0000
0703 2,400
1,600
6,400
0705 1,000
0706 1,100
1,300
プロジェクション-1 プロジェクション-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
日付 売上高
0706 9,999
3,000
0707 7,777
9,000
エリア 店舗 日付 売上高 顧客ID
神奈川 横浜 0706 9,999 10001
0707 7,777 10001
東京 新宿 0706 3,000 10002
0707 9,000 10002
ディスクへ移動されたタイミングでは、2つの固まりとして保存される。
このタイミングでのクエリは2つの固まりを読み結果を返す。
日付 売上（SUM)
0706 12,999
0707 16,777
日付 売上（SUM)
0701 1,100
0702 1,0000
0703 10,400
0705 1,000
0706 2,400
プロジェクション-3
データは、ソート／圧縮／エンコードされ、
列形式のファイルに格納される

10. Tuple Mover - mergeout
日付 売上高
0701 100
1,000
0702 1,0000
0703 2,400
1,600
6,400
0705 1,000
0706 1,100
1,300
9,999
3,000
0707 7,777
9,000
プロジェクション-1 プロジェクション-2
エリア 店舗 日付 売上高 顧客ID
大阪 梅田 0703 2,400 10004
0706 1,100 10008
神奈川 横浜 0706 9,999 10001
0707 7,777 10001
東京 池袋 0703 1,600 10005
品川 0705 1,000 10007
新宿 0701 100 10001
1,000 10002
0703 6,400 10006
0706 3,000 10002
0707 9,000 10002
名古屋 名古屋 0702 1,0000 10003
0706 1,300 10009
定期的に、2つのファイルが1つにマージされて、最適化された形になる。
Postgresで必要なバキュームなどの必要は無く、Verticaが定期的に、未使用
領域の開放などをこのマージ中に実施する。
日付 売上（SUM)
0701 1,100
0702 1,0000
0703 10,400
0705 1,000
0706 14,999
0707 16,777
プロジェクション-3
Mergeout
Mergeoutは、ROSコンテナを統合し、
断片化することを軽減

11. DBメンテナンス処理の種類と
最適なDBメンテナンス設計
11

12. 統計情報更新の種類と実行方式
12
ANALYZE_ROW_COUNT ANALYZE_STATISTICS ANALYZE_HISTOGRAM
概要
• 全テーブル・プロジェクショ
ンの行数のみをカウント
• 統計情報全要素を更新
• ANALYZE_HISTOGRAMコマンド
のエイリアス
• ANALYZE_STATISTICSはサンプル
パーセンテージが10％
（Default）
• 統計情報全要素を更新
• サンプルのパーセンテージ（1
～100％）を指定可能
発行方法 自動発行
※60秒毎（Default）
手動発行 手動発行
実行コマンド 実行間隔を下記コマンドで変更可
能
=> SELECT
SET_CONFIG_PARAMETER(‘AnalyzeRo
wCountInterval’, 秒数);
ロード直後等、データが大きく変
わった場合に、下記の通り発行
=> SELECT ANALYZE_STATISTICS
(‘(schema_name.)table-name’);
※全テーブルの統計情報を取得す
る場合は、(‘’)とします。
※「 ‘(schema_name.)table-
name.column_name’」を指定する
と、カラム単位でも取得可能です。
ロード直後等、データが大きく変
わった場合に、下記の通り発行
=> SELECT ANALYZE_HISTOGRAM
(‘(schema_name.)table-name’,
percent);
※全テーブルの統計情報を取得す
る場合は、(‘’)とします。
※「 ‘(schema_name.)table-
name.column_name’」を指定する
と、カラム単位でも取得可能です。

13. 統計情報更新の実行タイミング
https://my.vertica.com/docs/latest/HTML/index.htm#Authoring/AdministratorsGuide/Statistics/BestPracticesForStatisticsCollection.htm%3FTocPath
%3DAdministrator's%2520Guide%7CCollecting%2520Database%2520Statistics%7C_____6
 統計情報更新時には、システムに一定以上の負荷がかかるため、下記のようなタイミングで
実行することを推奨
- 初期データロード後
※データベースデザイナーを実行する場合、その際に実行可能
- プロジェクションが新たに作成されリフレッシュされた場合
- データが大幅に変更された場合
- テーブルのカラムの最大値・最小値が大幅に変更された場合
- 参照整合性制約を持つ新しい主キーを追加した場合
※主キーと外部キーを保持する両テーブルに適用必要
- 任意のテーブルのサイズが他のテーブルに対して大きく変化した場合
- データ分布の著しい偏差がヒストグラムを再計算する必要がある場合
※イベントによって特定の株式の取引が異常に高水準になる場合など
- データベースが一定期間アクティブではなかった場合
13
左記のようなタイミングの
判断が難しい場合、下記の
ようなタイミングで実行す
ることが考えられます。
1. 初期データロード後
2. 日次処理（あるいは、
週次・月次処理）実行
後
3. 手動での大量データ変
更後
4. プロジェクション追加
作成後
5. カラム追加後

14. Tuple Moverの種類と最適な実装方法
14
Moveout Mergeout
概要
WOSコンテナから新しいROSコンテナにデータ
を定期的に移動し、WOSがいっぱいになって
ROSにスピルする（流出する）ことを防ぐ
ROSコンテナを統合し、Deleteによって論理削除
されたレコードを物理的に削除する
発行方法 自動発行 ※5分毎（Default） 自動発行 ※10分毎（Default）
最適な実装方法 • 基本的にはデフォルト間隔での自動発行が
推奨
• Trickleロードが頻繁に発生し、WOSが溢れる
可能性がある場合は、実行間隔を短くする
など検討
• 基本的にはデフォルト間隔での自動発行が
推奨
• Moveoutの実行間隔を短くした場合、
Mergeoutの実行間隔も必要に応じて短くす
ることを検討
• 日中にロードが発生したものに対して
Mergeoutの実行を避けたい場合は、夜間に
手動実行を仕込むなどを検討
実行間隔の変更方法 実行間隔を下記コマンドで変更可能
=> SELECT
SET_CONFIG_PARAMETER(‘MoveOutInterval’,秒数);
実行間隔を下記コマンドで変更可能
=> SELECT
SET_CONFIG_PARAMETER(‘MergeOutInterval’,秒数);
手動実行方法 下記コマンドで手動実行可能
=> select do_tm_task(‘moveout’,’table_name’);
下記コマンドで手動実行可能
=> select do_tm_task(‘mergeout’,’table_name’);

15. Tuple Mover - Moveoutに関するパラメーター
15
パラメーター名 デフォルト値 変更を検討すべきか否か パラメーターの説明
MoveOutInterval 300秒（5分） Trickleロードが頻繁に発生
し、WOSが溢れる可能性が
ある場合は、実行間隔を短
くするなど検討
WOSからROSへ転送すべき新データが無い
かどうかをTuple Moverが確認する周期
（秒）
MoveOutMaxAgeTime 1800秒（30分） 変更する必要なし WOS上にあるデータが強制的にディスク
に書き込まれる周期（秒）
MoveOutSizePct 0%（閾値なし）
（※）
変更する必要なし Moveout処理が実行されるための、WOSの
データ量の閾値（％）
（※）この場合、WOSの最大値までWOSでデータが格納され、最大値に達すると、Moveout処理が実行されます。

16. Tuple Mover - Mergeoutに関するパラメーター
16
パラメーター名 デフォルト値 変更を検討すべきか否か パラメーターの説明
ActivePartitionCount 1 テーブルにパーティション
キーを設定している場合、
データの挿入方法によって
は変更を検討
Tuple Moverはパーティションテーブルの
最新のパーティションにのみデータが挿
入されることを前提とする。もしそうで
ない場合、このパラメーターを設定する
ことで、同時にデータを受け取り可能な
パーティションの数を設定可能
MergeOutInterval 600秒（10分） Moveoutの実行間隔を短く
した場合、Mergeoutの実行
間隔も必要に応じて短くす
ることを検討
Mergeoutすべき新ファイルがROS上に無い
かどうかをTuple Moverが確認する周期
（秒）。ROSコンテナが頻繁に追加されて
いる場合、この値を小さく取る必要があ
り
MaxROSPerStratum 32 変更する必要なし Mergeoutが実行されるROSの閾値になりま
す。Defaultの場合、ROSの数が32個に達す
ると、Mergeoutが発行される。ただし、
この値を変更することは通常ない

17. ActivePartitionCount=1の場合の動作例
 前提：日付でパーティション
 ロード処理概要：当日、前日、前々日までのデータが混在
 動作例：
1. 当日のデータをロードする。（当日データの複数のROS
コンテナが生成される。）
2. 前日のデータをロードする。（当日のROSコンテナが1つ
に統合されつつ、前日データには複数のROSコンテナが
生成される。）
ベストプラクティス
 左記のようなロード処理の場合、ActivePartitionCount=3とする
 動作例：
1. 当日のデータをロードする。（当日データの複数のROS
コンテナが生成される。）
2. 前日のデータをロードする。（当日のROSコンテナはそ
のままで、前日データには複数のROSコンテナが生成さ
れる。）
17
当日 前日 前々日
当日 前日 前々日
当日 前日 前々日
当日 前日 前々日
ActivePartitionCountの最適な設定について
任意のテーブルにパーティションキーを設定している場合要検討
ActivePartitionCount=1の場合、別日のデータが挿入されるたびに、該当以外のパーティションに含まれ
るROSのマージ処理が走るためシステム負荷が高まり、ユーザークエリに性能影響がでる可能性あり！

18. DBメンテナンス処理のモニ
タリング
18

19. 統計情報の確認方法
どの種類の統計情報がいつ取得されているのかの確認方法
 確認実行SQL
 実行結果例
- 統計情報を手動取得している場合
- 統計情報を手動取得していない場合
19
=> select SELECT PROJECTION_NAME,PROJECTION_COLUMN_NAME,STATISTICS_TYPE,STATISTICS_UPDATED_TIMESTAMP
FROM PROJECTION_COLUMNS
WHERE TABLE_NAME = 'テーブル名' AND TABLE_SCHEMA = 'スキーマ名'
ORDER BY 1,2;
PROJECTION_NAME | PROJECTION_COLUMN_NAME | STATISTICS_TYPE | STATISTICS_UPDATED_TIMESTAMP
-----------------+------------------------+-----------------+-------------------------------
trades_p_b0 | ask | FULL | 2017-06-01 02:09:04.408772+00
trades_p_b0 | bid | FULL | 2017-06-01 02:09:04.408772+00
trades_p_b0 | stock | FULL | 2017-06-01 02:09:04.408772+00
PROJECTION_NAME | PROJECTION_COLUMN_NAME | STATISTICS_TYPE | STATISTICS_UPDATED_TIMESTAMP
-----------------+------------------------+-----------------+-------------------------------
trades_p_b0 | ask | ROWCOUNT | 2017-06-01 02:07:03.045345+00
trades_p_b0 | bid | ROWCOUNT | 2017-06-01 02:07:03.045345+00
trades_p_b0 | stock | ROWCOUNT | 2017-06-01 02:07:03.045345+00

20. 統計情報の確認方法
その他の確認方法
 統計情報が取得されているかどうかを確認
 統計情報更新が手動実行されたかどうかを確認
20
=> SELECT GET_PROJECTION_STATUS('public.trades_p_b0');
GET_PROJECTION_STATUS
---------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Current system K is 1.
# of Nodes: 3.
public.trades_p_b0 [Segmented: Yes] [Seg Cols: "public.trades.stock", "public.trades.bid", "public.trades.ask"] [K:
1] [public.trades_p_b1] [Safe: Yes] [UptoDate: Yes] [Stats: Yes]
(1 row)
=> SELECT PROJECTION_NAME,HAS_STATISTICS
FROM PROJECTIONS
WHERE ANCHOR_TABLE_NAME = 'trades' AND PROJECTION_SCHEMA = 'public';
PROJECTION_NAME | HAS_STATISTICS
-----------------+----------------
trades_p_b0 | t
trades_p_b1 | t
(2 rows) 手動取得されている場合：’t’
手動取得されていない場合：’f’
No：RowCountsも取得されていない状態
RowCounts：RowCountsのみ取得されている状態
Yes：手動取得されている場合

21. 統計情報の出力・取込方法
 SQLコマンドでXML形式で統計情報をファイルでExportすることが可能
※統計情報取得後に取得することをご推奨
- 実行コマンド
 Export済XML形式ファイルを取込前に検証することが可能
※警告が出た場合は、再度統計情報取得することをご推奨
- 実行コマンド
 Export済XML形式ファイルをImportすることが可能
- 実行コマンド
21
=> select EXPORT_STATISTICS(‘Vertica上の出力ファイル名’,’スキーマ名.テーブル名’,’カラム名’);
オプション
=> select VALIDATE_STATISTICS(‘Vertica上の出力ファイル名’);
=> select IMPORT_STATISTICS(‘Vertica上の出力ファイル名’);

22. Tuple Mover関連処理のモニタリング
システムテーブルtuple_mover_operationsで確認可能
 Moveoutの状況確認
 Mergeoutの状況確認
 Analyze Statisticsの状況確認
22
=> SELECT node_name, projection_name, plan_type, operation_start_timestamp, operation_status
FROM TUPLE_MOVER_OPERATIONS WHERE plan_type = ‘Moveout’ and table_name=‘trades’ ORDER BY 1,2,3,4;
node_name | projection_name | plan_type | operation_start_timestamp | operation_status
-----------------+-----------------+-----------+-------------------------------+------------------
v_demo_node0001 | trades_p_b1 | Moveout | 2017-06-01 02:11:03.018112+00 | Start
v_demo_node0001 | trades_p_b1 | Moveout | 2017-06-01 02:11:03.051374+00 | Complete
=> SELECT node_name, projection_name, plan_type, operation_start_timestamp, operation_status
FROM TUPLE_MOVER_OPERATIONS WHERE plan_type = ‘Mergeout’ and table_name=‘trades’ ORDER BY 1,2,3,4;
node_name | projection_name | plan_type | operation_start_timestamp | operation_status
-----------------+-----------------+------------+-------------------------------+------------------
v_demo_node0001 | trades_p_b1 | Mergeout | 2017-06-01 03:11:03.018112+00 | Start
v_demo_node0001 | trades_p_b1 | Mergeout | 2017-06-01 03:11:03.051374+00 | Complete
=> SELECT node_name, projection_name, plan_type, operation_start_timestamp, operation_status
FROM TUPLE_MOVER_OPERATIONS WHERE plan_type = ‘Analyze Statistics’ and table_name=‘trades’ ORDER BY 1,2,3,4;
node_name | projection_name | plan_type | operation_start_timestamp | operation_status
-----------------+-----------------+----------------------+-------------------------------+------------------
v_demo_node0001 | trades_p_b1 | Analyze Statistics | 2017-06-01 03:11:03.018112+00 | Start
v_demo_node0001 | trades_p_b1 | Analyze Statistics | 2017-06-01 03:11:03.051374+00 | Complete
WHERE句にoperation_status=‘Running’
を付与することで、実行中のものに
絞って参照可能

23. 関連ページ
 Best Practices for Statistics Collection（英語）
 Collecting Database Statistics （英語）
 Tuple Mover Best Practices（英語）
- 上記記事の日本語版はこちら
 Vertica Partitions: The FAQs （英語）
- 上記記事の日本語版はこちら
 Tuple Mover Operations （英語）
 Managing the Tuple Mover（英語）
23

24. Thank you
japan_vertica_info@microfocus.com