動的テーブルは、設定された開始時刻とリフレッシュ間隔に基づいて、バックグラウンドでリフレッシュタスクを実行します。ベーステーブルが変更されると、動的テーブルはリフレッシュされ、最新のデータが反映されます。本トピックでは、これらのリフレッシュタスクを監視、表示、管理する方法について説明します。
監視メトリクス
Hologres V4.0.8 以降では、動的テーブルのリフレッシュタスクで以下の 4 つのメトリクスが利用可能です。要件に応じて、Cloud Monitor でアラートのしきい値を設定します。詳細については、「Cloud Monitor」をご参照ください。
インスタンスレベルのリフレッシュ失敗 QPS
メトリック名: Dynamic Table Refresh Failed QPS 単位: count/s (1 秒あたりのクエリ数)
このメトリックは、インスタンス内のすべての動的テーブルにおけるリフレッシュタスクの失敗率を示します。正常な状態では、値は 0 に近いままです。
この値が常にゼロ以外であるか、上昇し続けている場合は、HoloWeb に移動してトラブルシューティングを行ってください。
データレイテンシー
メトリック名: Dynamic Table Lag 単位: s (秒)
このメトリックは、各動的テーブルがそのベーステーブルや指定された時点からどれだけ遅れているかを示します。これはデータの鮮度を反映します。
レイテンシーが増加し続ける場合:
|
考えられる原因 |
次のステップ |
|
リフレッシュタスクが繰り返し失敗しているか、自動リフレッシュが一時停止しています |
HoloWeb コンソールに移動し、タスクのステータスを確認してください |
|
大量のアップストリームデータが変更され、インスタンスリソースが追いつくのに不十分です |
リフレッシュ期間などの Hologres 監視メトリクスを確認し、リソースボトルネックを調査してください |
リフレッシュ期間
メトリック名: Dynamic Table Refresh Duration 単位: ms (ミリ秒)
このメトリックは、各動的テーブルの現在のリフレッシュタスクがどのくらいの時間実行されているかを示します。これを使用して、リフレッシュの実行時間が長くなっていないかを検出します。
値が急に増加した場合、または過去の平均を大幅に上回った状態が続く場合:
|
考えられる原因 |
次のステップ |
|
リソースボトルネック |
インスタンスの CPU、メモリ、ストレージのメトリクスを確認してください |
|
アップストリームデータ量の増加 |
|
テーブルごとのリフレッシュ失敗 QPM
メトリック名: Dynamic Table Refresh Failed QPM 単位: count/m (1 分あたりのカウント数)
このメトリックは、各動的テーブルにおける1分あたりのリフレッシュタスクの失敗数を示します。正常な状態では、値は 0 です。
このメトリックの解釈:
|
観測されたパターン |
意味 |
アクション |
|
散発的なスパイクがあり、その後のリフレッシュは成功します |
一時的なシステム負荷またはインスタンスのアップグレード |
アクションは不要です |
|
特定のテーブルの値が、常に 0 より大きいままです |
永続的なリフレッシュの失敗 |
|
リフレッシュタスクの表示
実行中のリフレッシュタスクの表示
hologres.hg_dynamic_table_refresh_activity の使用
システムテーブル hologres.hg_dynamic_table_refresh_activity は、フルリフレッシュとインクリメンタルリフレッシュを含む実行中のリフレッシュタスクとそのリソース消費量を表示します。フィールドの説明については、「hologres.hg_dynamic_table_refresh_activity」をご参照ください。
このシステムテーブルは、Hologres V3.0 および V4.0.8 以降でのみサポートされています。
-- 現在実行中のリフレッシュタスクを表示
SELECT
pid,
query_id,
refresh_mode,
'RUNNING' AS status,
refresh_start,
extract(epoch FROM duration) AS duration, -- 秒
serverless_queue_time_ms::bigint / 1000 AS serverless_queue_time_sec,
serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_sec,
serverless_allocated_cores
FROM hologres.hg_dynamic_table_refresh_activity
WHERE datname = '${database}'
AND table_write = quote_ident('${schema}') || '.' || quote_ident('${tableName}')
ORDER BY refresh_start DESC
LIMIT 2000;
hg_stat_activity の使用
システムビュー hg_stat_activity も実行中のリフレッシュタスクを表示します。表示はリフレッシュモードによって異なります。
-
フルリフレッシュ:
INSERTステートメントが表示されます。 -
インクリメンタルリフレッシュ:
Refreshタスクが表示されます。
hologres.hg_dynamic_table_refresh_log の使用
3.1 構文で作成された動的テーブルの場合、hologres.hg_dynamic_table_refresh_log はリフレッシュタスクログのテーブルごとのビューを提供します。次の例では、特定のテーブルで現在実行中のすべてのリフレッシュタスクをクエリします。
-- 特定のテーブルで実行中のリフレッシュタスクを表示 (3.1 構文)
SELECT query_job_id, status
FROM hologres.hg_dynamic_table_refresh_log('<dynamic_table_name>')
WHERE status = 'RUNNING';
hologres.hg_dynamic_table_refresh_log は、3.1 構文で作成された動的テーブルでのみサポートされています。3.0 構文で作成された動的テーブルの場合は、hologres.hg_dynamic_table_refresh_activity または hg_stat_activity を使用してください。
このビューによって返される query_job_id は、実行中のリフレッシュタスクをキャンセルする際にも使用されます。詳細については、「新しい 3.1 構文で作成された動的テーブル」をご参照ください。
監視メトリクスの使用
QPS、RPS (1 秒あたりのレコード数)、レイテンシーなどのメトリクスを確認して、実行ステータスを検証してください。Command Type が refresh の場合、動的テーブルのリフレッシュタスクを示します。詳細については、「監視メトリクス」をご参照ください。
リフレッシュタスクがサーバーレスコンピューティングリソースで実行される場合は、サーバーレスコンピューティングのメトリクスでそのステータスを確認することもできます。
過去のリフレッシュタスクの表示
hologres.hg_dynamic_table_refresh_history の使用
システムテーブル hologres.hg_dynamic_table_refresh_history は、過去 1 か月間のすべてのリフレッシュタスク (フルリフレッシュ、インクリメンタルリフレッシュ、手動リフレッシュ) の履歴を記録します。フィールドの説明については、「hologres.hg_dynamic_table_refresh_history」をご参照ください。
レコードは 1 か月間保持されます。1 か月より古いデータはクエリできません。
テーブルの所有者は自分のリフレッシュ履歴のみ表示できます。スーパーユーザーロールを持つユーザーは、すべてのリフレッシュレコードを表示できます。
例 1:過去 1 日間のインクリメンタルリフレッシュタスクの表示
SELECT
query_id,
refresh_mode,
status,
refresh_start,
duration,
refresh_latency / 1000 AS refresh_latency_second,
serverless_allocated_cores,
queue_time_ms::bigint / 1000 AS queue_time_second,
serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
FROM hologres.hg_dynamic_table_refresh_history
WHERE refresh_start >= CURRENT_DATE - INTERVAL '1 day'
AND dynamic_table_name = '<dynamic_table>'
AND refresh_mode = 'incremental'
ORDER BY refresh_start DESC
LIMIT 100;
例 2:過去 1 日間のインスタンス内のすべてのリフレッシュタスクの表示
SELECT
query_id,
refresh_mode,
status,
refresh_start,
duration,
refresh_latency / 1000 AS refresh_latency_second,
serverless_allocated_cores,
queue_time_ms::bigint / 1000 AS queue_time_second,
serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
FROM hologres.hg_dynamic_table_refresh_history
WHERE refresh_start >= CURRENT_DATE - INTERVAL '1 day';
例 3:過去 1 日間の特定のテーブルのリフレッシュタスクの表示
SELECT
query_id,
refresh_mode,
status,
refresh_start,
duration,
refresh_latency / 1000 AS refresh_latency_second,
serverless_allocated_cores,
queue_time_ms::bigint / 1000 AS queue_time_second,
serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second
FROM hologres.hg_dynamic_table_refresh_history
WHERE schema_name = '<schema_name>'
AND dynamic_table_name = '<dynamic_table>'
AND refresh_start >= CURRENT_DATE - INTERVAL '1 day';
レガシーの 3.0 構文で作成されたフルリフレッシュの動的テーブルの場合、hologres.hg_dynamic_table_refresh_historyは成功または失敗のステータスを正確に反映しないことがあります。失敗したリフレッシュがSuccessとして表示される場合があります。これらのテーブルの実際のリフレッシュ履歴を取得するには、次の手順を実行してください:1.hologres.hg_dynamic_table_propertiesからcron_job_nameを取得します。2. その名前を使用して cron ジョブの実行レコードをクエリしてください。
-- ステップ 1:cron_job_name を取得
SELECT property_value AS cron_job_name
FROM hologres.hg_dynamic_table_properties
WHERE dynamic_table_name = '<dt_name>'
AND property_key = 'cron_job_name';
-- ステップ 2:cron ジョブの実行レコードをクエリ
SELECT *
FROM hologres.hg_user_cron_tasks
WHERE jobname = '<cron_job_name>'
ORDER BY start_time DESC;
スロークエリログの使用
リフレッシュタスクは、Command Type が refresh に設定されたスロークエリログにも表示されます。詳細については、「スロークエリログの取得と分析」をご参照ください。
リフレッシュタスクの実行計画の表示
リフレッシュステートメントで EXPLAIN および EXPLAIN ANALYZE を使用して、通常のクエリと同様に、その実行計画を表示し、パフォーマンスのボトルネックを特定できます。
EXPLAIN REFRESH DYNAMIC TABLE hmtest.dt_order_lineitem;
出力例:
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Gather (cost=0.00..10.13 rows=1 width=16)
-> Insert (cost=0.00..10.13 rows=1 width=16)
-> Redistribution (cost=0.00..10.11 rows=1 width=16)
-> Final HashAggregate (cost=0.00..10.11 rows=1 width=16)
Group Key: orders.o_orderpriority
-> Redistribution (cost=0.00..10.11 rows=10 width=16)
Hash Key: orders.o_orderpriority
-> Partial HashAggregate (cost=0.00..10.11 rows=10 width=16)
Group Key: orders.o_orderpriority
-> Hash Left Semi Join (cost=0.00..10.11 rows=1000 width=8)
Hash Cond: (orders.o_orderkey = lineitem.l_orderkey)
-> Redistribution (cost=0.00..5.03 rows=1000 width=16)
Hash Key: orders.o_orderkey
-> Local Gather (cost=0.00..5.01 rows=1000 width=16)
-> Seq Scan on orders (cost=0.00..5.01 rows=1000 width=16)
Filter: ((o_orderdate >= '1996-07-01 00:00:00+08'::timestamp with time zone) AND (o_orderdate < '1996-10-01 00:00:00+08'::timestamp with time zone))
-> Hash (cost=5.03..5.03 rows=1000 width=8)
-> Redistribution (cost=0.00..5.03 rows=1000 width=8)
Hash Key: lineitem.l_orderkey
-> Local Gather (cost=0.00..5.03 rows=1000 width=8)
-> Seq Scan on lineitem (cost=0.00..5.03 rows=1000 width=8)
Filter: (l_commitdate < l_receiptdate)
Optimizer: HQO version 2.1.0
(23 rows)
リフレッシュタイムアウト期間の設定
長時間実行されるリフレッシュタスクがリソースをブロックするのを防ぐために、タイムアウトを設定してください。Hologres は 3 つのレベルのタイムアウト設定をサポートしています。
テーブルレベルのタイムアウト
動的テーブルを作成する際に、テーブルレベルのタイムアウトを設定します。これは、そのテーブルのすべてのリフレッシュタスクに適用されます。次の例では、パブリックデータセット tpch_10g を使用します。コードを実行する前に、データセットをインポートしてください。詳細については、「パブリックデータセットのインポートタスクの作成」をご参照ください。
-- このテーブルのすべてのリフレッシュタスクに 30 分のタイムアウトを設定
CREATE DYNAMIC TABLE tpch_q1_batch
WITH (
refresh_mode = 'full',
auto_refresh_enable = 'true',
full_auto_refresh_interval = '1 hours',
refresh_guc_statement_timeout = '30 min'
)
AS
SELECT
l_returnflag,
l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price,
SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
AVG(l_quantity) AS avg_qty,
AVG(l_extendedprice) AS avg_price,
AVG(l_discount) AS avg_disc,
COUNT(*) AS count_order
FROM hologres_dataset_tpch_10.lineitem
WHERE l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY l_returnflag, l_linestatus;
セッションレベルのタイムアウト
手動リフレッシュの場合、セッションレベルの GUC (Grand Unified Configuration) パラメーターを使用してタイムアウトを設定します。
SET statement_timeout = <time>;
REFRESH DYNAMIC TABLE <dynamic_schema_name.dynamic_table_name>;
タイムアウト設定の詳細については、「アクティブなクエリのタイムアウトの変更」をご参照ください。
リフレッシュごとのタイムアウト
単一の手動リフレッシュのタイムアウトを上書きするには、refresh ... WITH (refresh_guc_statement_timeout = '...') を使用します。
REFRESH DYNAMIC TABLE <schema_name.table_name> WITH (
refresh_guc_statement_timeout = '30 min'
);
手動リフレッシュのトリガー
次のステートメントを実行して、即時リフレッシュをトリガーします。
REFRESH DYNAMIC TABLE <schema_name.table_name>;
自動リフレッシュが有効になっている場合、手動リフレッシュはスケジュールされた自動リフレッシュタスクと並行して実行されます。両方とも正常に完了します。システムは最新のデータのコピーを 1 つだけ保持します。
リフレッシュタスクのキャンセル
新しい 3.1 構文で作成された動的テーブル
実行中のリフレッシュタスクのキャンセル
hologres.hg_dynamic_table_refresh_log から実行中のタスクの query_job_id をクエリし、hologres.hg_internal_cancel_query_job を使用してキャンセルします。
-- ステップ 1:query_job_id を取得
SELECT query_job_id
FROM hologres.hg_dynamic_table_refresh_log('<dt_name>')
WHERE status = 'RUNNING';
-- ステップ 2:タスクをキャンセル
SELECT hologres.hg_internal_cancel_query_job('<query_job_id>');
スーパーユーザーのみが hologres.hg_internal_cancel_query_job を使用してリフレッシュタスクをキャンセルできます。
テーブルの自動リフレッシュの一時停止
テーブルレベルで後続のすべてのリフレッシュタスクを停止するには、自動リフレッシュを無効にします。
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name> SET (auto_refresh_enable = false);
この操作により、テーブルの今後のすべてのリフレッシュタスクが停止します。動的テーブルのデータは、自動リフレッシュが再度有効になるまで更新されません。再度有効にする方法については、「ALTER DYNAMIC TABLE」をご参照ください。
3.0 構文で作成された動的テーブル
実行中のリフレッシュタスクのキャンセル
リフレッシュタスクの実行時間が長すぎる、またはスタックしているように見える場合は、pg_cancel_backend を使用してキャンセルします。
-- プロセス ID (pid) でリフレッシュタスクをキャンセル
SELECT pg_cancel_backend(<pid>);
pid は hologres.hg_dynamic_table_refresh_activity または hg_stat_activity から取得します。詳細については、「リフレッシュタスクの表示」をご参照ください。
リフレッシュタスクをバッチでキャンセルするには、通常のクエリと同じ方法を使用します。詳細については、「クエリの終了」をご参照ください。
テーブルの自動リフレッシュの一時停止
テーブルレベルで後続のすべてのリフレッシュタスクを停止するには、次のようにします。
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name> SET (auto_refresh_enable = false);
この操作により、テーブルの今後のすべてのリフレッシュタスクが停止します。動的テーブルのデータは、自動リフレッシュが再度有効になるまで更新されません。再度有効にする方法については、「ALTER DYNAMIC TABLE」をご参照ください。