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

1. リソース管理の仕組みと
ベストプラクティス
1

2. 本章の概要
 リソースマネージャー
 定義済のリソースプール
 リソースプールのパラメーター
 ユーザー定義のリソースプール
 リソースプールのモニタリング
 リソースプールの実装例
2

3. リソースマネージャー

4. なぜ、リソースマネージャーを持つのか？
4
Verticaクラスター
リカバリ
リフレッシュ
システムテーブ
ルクエリ
Web アプリ
レポーティング
ツール
アドホッ
ククエリ
ロード
Tuple Mover
(moveout/mergeout)
DBD

5. クエリ実行のライフサイクル
5
クエリの
リジェクト
クエリをキュー
クエリの実行
クエリの
リジェクト
集計した結果を
イニシエーター
ノードに返す
イニシエーターノード
でクエリプランを作成
要求されたリソー
スが利用可能領域
を超えるか？
クエリプランを実行ノード
（Executor Node）に配布
実行ノード上で、ローカ
ルのクエリプランを作成
要求されたリソー
スが利用可能領域
を超えるか？
クエリが長い間
キューに入ったま
まか？
はい
いいえ
はい
はい
いいえ
いいえ

6. リジェクト 対 キュー
 ノードあたりにあまりにも多くのメモリが要求された場合、もしくは、クエリがタイムアウ
トパラメーターより長く待ち状態になった場合、クエリをリジェクト（Reject）
- タイムアウトのデフォルトは5分、変更可能
- システムテーブルの「resource_rejections」で、「ABORT」と表示される
 必要なメモリ量が、現在および計画中のメモリの割り当てを満たすことができない場合、ク
エリをキュー（Queue）
- システムテーブルの「resource_queues」で、「WAIT」と表示される

7. リソースプール

8. リソースプール
 メモリ割り当て、同時実行、キュータイムアウト、優先順位を制御
 ユーザークエリと内部処理を制御
 異なる同時実行の要求を満たすように調整可能
 システムリソースの予約と優先順位付けために、ユーザ定義のプールを追加で作成可能
 ユーザーはいずれかのプールに割り当てられる
- デフォルトは、 General プールに割り当てられる。変更可能

9. 定義済のリソースプール

10. 定義済のプール（1/2）
 GENERAL
- ユーザークエリ実行時のデフォルトのプール
- 他のプールでリソースが足りない場合、ここから借用
- システムメモリのパーセンテージで指定される
 BLOBDATA
- 機械学習関連の関数を実行時に使用されるプール
 DBD
- DBDの内部処理用のリソースの割り当てを管理するために使用されるプール
 JVM
- Java UDx専用
- 利用可能メモリの2Gもしくは10％のいずれか小さい値
 METADATA
- Verticaのカタログ情報を保持するために使用されるプール

11. 定義済のプール（2/2）
 RECOVERY
- ノードのリカバリを処理するために使用されるプール
 REFRESH
- プロジェクションのリフレッシュにリソースを割り当てるために使用されるプール
 SYSDATA
- メモリ領域にシステムテーブルの結果が格納されるプール
 SYSQUERY
- システムテーブルのクエリの実行中に使用されるプール
 TM
- Tuple Mover（Moveout と Mergeout）実行時に使用されるプール
 WOSDATA
- メモリ上へのデータロード時に使用されるプール
- 利用可能メモリの2Gもしくは25％のいずれか小さい値

12. リソースプールの
パラメーター

13. リソースプールのパラメーター（1/6）
メモリ割り当てのコントロール
 MEMORYSIZE: 予約済メモリ（未予約の場合、0と設定）
 MAXMEMORYSIZE: GENERAL プールから借りる場合も含む、使用可能なメモリ量
1つのプールで、 MEMORYSIZE = 3G と MAXMEMORYSIZE = 3G と設定した場合の意味は何で
しょう？?
MEMORYSIZE = 1G で MAXMEMORYSIZE = 5G のプールと、実行完了するのに 5G のメモリが必
要なクエリがあります。General プールからどれくらいのメモリを借りますか？このプール
でクエリが 6G のメモリを必要とする場合、どうなるでしょう？
?

14. リソースプールのパラメーター（2/6）
クエリ並列実行度のコントロール
 MAXCONCURRENCY: 同時実行クエリの最大数
- 同時実行数が、 MAXCONCURRENCY の値に達すると、次のクエリはキュー
 PLANNEDCONCURRENCY: プールに対して想定されるクエリ実行数
- 各クエリに割り当てられたターゲットメモリを決定するために使用される
- デフォルトは、ノードあたりのコア数
クエリあたりの割り当
てメモリサイズ =
[MAXの75%]MEMORYSIZE
PLANNEDCONCURRENCY

15. リソースプールのパラメーター（3/6）
15
PLANNEDCONCURRENCY シナリオ：6ユーザーが
「ABC」という名前のプールに割り当てられ、全ユー
ザーが1Gのクエリを実行する
ABC プールのパラメーター：
MEMORYSIZE 4G
PLANNEDCONCURRENCY 4
MAXCONCURRENCY 5
クエリ当たりの割り当てメモリ
サイズ
=
[MAX]MEMORYSIZE
PLANNEDCONCURRENCY
この場合、 4G
4
= 1G （1クエリあたり）
Query 1 1G
Query 2 1G
Query 3 1G
Query 4 1G
Query 5 1G
Query 6 1G
ABC
General
Queue
どのプールでメモリが
割り当てられるか？

16. リソースプールのパラメーター（4/6）
キューに入ったクエリのコントロール
 PRIORITY: リソースマネージャーがメモリを予約する順番を指定
- 待ち状態の要求にのみ適用
- 同じ優先度の要求は、到着順で実行開始される
- 高優先度で指定しても、クエリがより高速に実行されるわけではない
 QUEUETIMEOUT: 発行クエリの最大待ち時間

17. リソースプールのパラメーター（5/6）：CPU関連のコントロール
 CPUAFFINITYMODE: 該当のリソースプールの CPU アフィニティの処理モード
- any（デフォルト）/exclusive/shared
 CPUAFFINITYSET: 該当のプールに関連付けられたクエリが実行される CPU のセット
 EXECUTIONPARALLELISM:
任意の単一クエリを処理
するために使われるスレッド数を制限
- このパラメーターを減らすことにより、
プールで発行されたショートクエリのスループットが増加
クエリ   結果
スレッド

18. リソースプールのパラメーター（6/6）
クエリ実行時間のコントロール
 RUNTIMEPRIORITY: リソースプール内のクエリ実行専用のリソースの量（CPU、 IO 帯域幅）を
指定
- HIGH/MEDIUM/LOW を指定可能
- RUNTIMEPRIORITY が HIGH で指定されたクエリは、 MEDIUM や LOW で指定されたクエリよりも、より
多くの CPU と I/O 帯域幅が割り当てられる
 RUNTIMEPRIORITYTHRESHOLD: リソースマネージャーが RUNTIMEPRIORITY を割り当てる前の実
行時間（秒）を指定
 RUNTIMECAP: 任意のプール内で、クエリが実行可能な最大実行時間
- 設定したリソースプール上の全てのユーザーに対して制限をかけることなく、個々のユーザーに対し
てパラメーターを設定し、特定のユーザーに対してのみクエリの実行時間を制限することも可能
 CASCADE TO: 割り当てられたプールの RUNTIMECAP に達したクエリに対して使用されるセカ
ンダリリソースプールを指定
RUNTIMEPRIORITYTHRESHOLD を 0 とし、 RUNTIMEPRIORITY を HIGH とする設定の意味は何で
しょう？?

19. リソースプールの比較
※「select * from resource_pools;」で確認可能

20. リソースプールのデフォルト値

21. ユーザー定義の
リソースプール

22. ユーザー定義のプール
 専用のプールを定義
 全てのパラメーターはカスタマイズ可能
 クエリに追加のリソースが必要な場合、 General プールより借用
=> CREATE RESOURCE POOL load_pool MEMORYSIZE '10G'
PRIORITY 100;
ユーザー定義のプール名
相対的な優先度は100で、
General プール
（MAXMEMORY が指定さ
れていないため）からメモ
リを借用する可能性あり
10 GB の予約済メモ
リ

23. ユーザールール
 ユーザー定義のプールが
指定されていない限り、
General プールか
SYSQUERY プールで
ユーザークエリは実行
 ユーザーが1つのプール
にのみ割り当てられる
 グループはプール
に割り当て不可
GENERAL/
SYSQUERY
ユーザー
定義
GENERAL/
SYSQUERY
管理者
グルー
プ


GENERAL/
SYSQUERY


ユーザー
定義/
SYSQUERY

24. ユーザーをプールに関連付け
 リソースプールの作成
 ユーザーをそれぞれ特定のプールに関連付け：
- ユーザーを作成し、関連付け
- もしくは、現在のユーザーを変更
=> CREATE RESOURCE POOL load_pool MEMORYSIZE '10G'
PRIORITY 100;
=> CREATE USER test RESOURCE POOL load_pool;
=> ALTER USER…

25. ユースケース – オンライン小売店の CEO のクエリ
CEO は毎週月曜の朝9時にレポートを実行します。
どうすれば、レポートがいつも時間通りに確実に実行されるようにできるでしょうか。

26. ユースケース – オンライン小売店の CEO のクエリの答え
 推定メモリ使用量を決めるためにクエリのプロファイル情報を取得
 リソースプールを作成
- 十分な MEMORYSIZE で
- ALTER USER コマンドを使用し、 CEO レポートの実行ユーザーを作成したリソースプールに関連付け
- このアプローチの欠点は何でしょうか？
=> PROFILE SELECT region, sum(revenue) FROM sales group by region;
NOTICE: Statement is being profiled.
HINT: select *
from v_monitor.execution_engine_profiles
where transaction_id=45035996273751349
and statement_id=6;
NOTICE: Initiator memory estimate for query:
[on pool general: 1723648 KB, minimum: 355920 KB]
=> CREATE RESOURCE POOL ceo_pool MEMORYSIZE '1800M' PLANNEDCONCURRENCY 1 PRIORITY 50;
=> ALTER USER ceo_user RESOURCE POOL ceo_pool;

27. ユースケース – 携帯電話会社向け Web アプリ
インタラクティブなポータルを使用した Web アプリケーションを使っています。IT 部門がバッ
チ処理のレポートを実行する際、 Web ページの更新に時々多大な時間がかかってしまい、エン
ドユーザーが不満を言っています。
どうすれば、バッチ処理のレポートを止めることなく、 Web サイトの閲覧ユーザーによりより
ユーザーエクスぺリエンスを提供することができるでしょうか？

28. ユースケース – 携帯電話会社向け Web アプリの答え
 Web ページのクエリのリフレッシュ専用のプールを作成
- PLANNEDCONCURRENCY と MEMORYSIZE を設定
- Web サイトのクエリを実行するデータベースユーザーとプールを関連付け
 メモリが他の目的でいつでも利用可能であるように、バッチ処理のレポートで使用するメモ
リサイズを固定し制限するプールを作成
=> CREATE RESOURCE POOL web_pool MEMORYSIZE '250M' PRIORITY 50
MAXCONCURRENCY 5 PLANNEDCONCURRENCY 1
=> CREATE RESOURCE POOL batch_pool MEMORYSIZE '4G‘ MAXMEMORYSIZE '4G'
MAXCONCURRENCY 10:

29. リソースプールの
モニタリング

30. リソースのモニター
システムテーブル 内容
RESOURCE_POOL_DEFAULTS 定義済みリソースプールとユーザー定義のリソースプールのデフォ
ルトパラメーターの設定情報を含む。各プールで値が明示的に設定
されていない場合、これらの値を採用
RESOURCE_POOL_STATUS メモリの使用量、同時実行中のクエリ数を含む、リソースプールの
現在の状態
RESOURCE_ACQUISITIONS 実行クエリに割り当てられたリソースと以前に実行されたクエリの
状態
RESOURCE_QUEUES プールと優先度の情報に加えて、待ち状態のクエリの現在のリスト
RESOURCE_REJECTIONS リジェクトされたクエリの統計情報とリジェクトの理由
RESOURCE_REJECTION_ DETAILS Verticaがリジェクトした各リソース要求の詳細情報
30

31. Verticaリソースプールの実
装例

32.  Verticaのリソースプール機能により、各業務の使用リソースに制限をかけることが可能
Vertica
Verticaリソースプールの実装例
オンラインのバッチ処理と検索処理が相互干渉しないようにリソース制御が可能
IFテーブル Workテーブル DMテーブル
Insert-Select SelectCOPY Insert-Select
CSV/TSV
25% 75%
CPU Resource CPU Resource
※処理内容は一例
CSV/TSV
CSV/TSV

33. Verticaリソースプールの実装例 CPUリソース制御イメージ
リソース状況に応じて、各処理のCPUの使い方を制御
 処理別にResource Poolを定義し、CPU使用率上限、使用方法（占有/非占有）を設定
 Resource Poolのパラメータは動的に変更可能（DB再起動など不要）
バッチ処理用Resource Pool
CPU使用に関する設定
• CPUAFFINITYSET=25%（使用率25%を上限）
• CPUAFFINITYMODE=SHARED（非占有使用）
⇒CPU使用率は25%以内に抑える
バッチ処理
検索処理
Vertica検索用Resource Pool
CPU使用に関する設定
• 使用率の上限は設けない
⇒バッチ処理で25%使っていれば75%が上限、使わ
れていなければ100%が上限

34. select name,memorysize,maxmemorysize,executionparallelism
exepara,queuetimeout,plannedconcurrency,maxconcurrency,runtimecap,cpuaffinityset,cpuaf
finitymode from resource_pools;
■25%のCPUを専有で使う
dbadmin=> create RESOURCE POOL CPU25e cpuaffinityset '25%' cpuaffinitymode EXCLUSIVE;
■50%のCPUを共有で使う
dbadmin=> create RESOURCE POOL CPU50s cpuaffinityset ‘50%’ cpuaffinitymode SHARED;
■リソースプールの指定（Userデフォルト設定 or セッション単位で指定）
dbadmin=> set session resource_pool=cpu50;
Verticaリソースプールの実装例 具体的なコマンドと使用リソース

35. s15 15%
s35 35%
制御無 100%
s55 55%
s35_1 35%
Userにデフォルトで使用する、リソースプールを設定してリソースを制御することが可能
またセッションごとに、set session を使って指定することも可能（その場合は、Userにそのリソースプー
ルの使用権限を与えておく必要がある）
SQL実行前に下記のコマンドを実行することで、そのセッションは指定したリソースプールを使用する
set session resource_pool=s35_1;
今回は、下記の、s55,s35,s15,s35_1というリソースプールを作成
特に制限をかけない
最大55%のCPUリソースを使用
最大35%のCPUリソースを使用
最大15%のCPUリソースを使用
最大35%のCPUリソースを使用
s35と、s35_1では、それぞれ別の35%のCPUリソースを使う

36. ロード
検索
15%
55%
ロード
検索
35%
35%
検索 15%
344937.583 ms
141017.407 ms
158581.541 ms
219019.931 ms
507822.211 ms
単体試験
ロード
検索
58447.572 ms
80378.134 ms
100%
100%
ロード 55% 101217.042 ms
リソース制御割合
CPUリソースが上限値までしか使われていないことを確認し、ロード、検索を実施
処理時間もCPUリソース応じて変化していることを確認
リソースを制御することによ
り、処理時間が長くなってい
ることが確認できる。
リソースを制御することによ
り、処理時間が長くなってい
ることが確認できる。

37. ロード
検索
15%
55%
ロード
検索
35%
35%
ロード
検索
55%
15%
360194.262 ms
147579.770 ms
275760.151 ms
351450.411 ms.
109074.243 ms.
514751.148 ms
2クエリー同時実行
ロード
検索
35%
35%
166044.571 ms
220309.198 ms
リソース制御割合
リソース制限をかけた状態で、ロードと検索を同時に実行、CPUリソースが上限値までしか使われていな
いことを確認。また、処理時間も単体テストに比べて劣化が無いことを確認し、ロードと検索を同じS35
のリソースプールを利用した際は、リソースの競合が起きていることを確認。
344937.583 ms
単体試験時
141017.407 ms
158581.541 ms
219019.931 ms
158581.541 ms
219019.931 ms
507822.211 ms
101217.042 ms

38. 0
10
20
30
40
50
60
70
80
90
100
13:42:05
13:42:45
13:43:25
13:44:05
13:44:45
13:45:25
13:46:05
13:46:45
13:47:25
13:48:05
13:48:45
13:49:25
13:50:05
13:50:45
13:51:25
13:52:05
13:52:45
13:53:25
13:54:05
13:54:45
13:55:25
13:56:05
13:56:45
13:57:25
13:58:05
13:58:45
13:59:25
14:00:05
14:00:45
14:01:25
14:02:05
14:02:45
14:03:25
14:04:05
14:04:45
14:05:25
14:06:05
14:06:45
14:07:25
14:08:05
14:08:45
14:09:25
SYS
USER
ロード
検索
15%
55%
ロード
検索
35%
35%
ロード
検索
55%
15%
ロード
検索
35%
35%
CPU利用率 %
時間
ロード 検索

39. Thank you