動的テーブルのデータソースとなるベーステーブルが変更されると、動的テーブルは自動的にデータを更新します。動的テーブルは、設定された開始時刻および更新間隔に基づき、バックグラウンドで自動的に更新タスクを実行します。本トピックでは、動的テーブル更新タスクの確認方法と保守方法について説明します。
モニタリングとアラート
モニタリングメトリック
Hologres V4.0.8 以降では、動的テーブルの更新タスクを管理するため、以下のモニタリングメトリックが提供されています。
インスタンスレベルの動的テーブル更新失敗 QPS(回/秒)
このメトリックは、インスタンス内のすべての動的テーブルにおける更新タスクの失敗件数をクエリ/秒(QPS)で示します。更新プロセス全体の健全性を反映します。通常、この値はゼロに近いはずです。この値が継続的にゼロ以外になったり、急激に増加したりする場合は、更新タスクが繰り返し失敗している可能性があります。 HoloWeb コンソール にアクセスし、失敗したタスクを確認して、速やかに問題を解決してください。
動的テーブルのデータ遅延(秒)
このメトリックは、インスタンス内の各動的テーブルのデータが、上流のベーステーブルの最新データまたは指定された時点に対してどの程度遅れているかを示します。単位は秒です。データの鮮度を反映します。要件に応じて、遅延に対する適切なアラートしきい値を設定してください。遅延が継続的に増加している場合、考えられる原因は以下のとおりです。
更新タスクが継続的に失敗している、または自動更新が一時停止されている。 HoloWeb コンソール の動的テーブル管理ページにアクセスして調査してください。
上流のデータソースで大量のデータが変更され、インスタンスのリソースが不足しているため更新処理が遅延している。更新所要時間などの Hologres モニタリングメトリックを確認して調査してください。
実行中の動的テーブル更新タスクの所要時間(ミリ秒)
このメトリックは、インスタンス内の各動的テーブルの現在実行中の更新タスクがどれだけの時間実行されているかを示します。単位はミリ秒です。このメトリックを使用して、更新エポックが長引いていないかを検出できます。ビジネスシナリオに応じて、個々のテーブルに対して更新所要時間のアラートを設定してください。このメトリックが突然増加したり、過去の平均値よりも著しく高くなったりする場合は、インスタンスのリソースボトルネックや上流データ量の変化などの原因を調査してください。
動的テーブル更新失敗 QPM(回/分)
このメトリックは、インスタンス内の各動的テーブルの更新タスクの失敗件数を 1 分あたりの回数(QPM)で示します。単一テーブルの更新安定性を評価するのに役立ちます。通常、この値はゼロである必要があります。システム負荷やインスタンスのスペックアップなどによる一時的な失敗は、その後の更新が成功すれば無視しても問題ありません。ただし、このメトリックが特定のテーブルで継続的にゼロより大きい場合は、そのテーブルの更新タスクに持続的な問題が発生していることを示します。動的テーブルの失敗ログに記録されたエラーメッセージをもとに、問題を調査・解決してください。
アラート
Cloud Monitor で動的テーブル更新タスクのアラートルールを設定し、異常を迅速に検出できます。詳細については、「Cloud Monitor」をご参照ください。
更新タスクの確認
実行中の更新タスクの確認
hologres.hg_dynamic_table_refresh_activity を使用した確認
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, -- milliseconds
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 システムビューを使用して、実行中の更新タスクを確認できます。hg_stat_activity に表示される内容は、更新モードによって異なります。
フル更新:`INSERT` 文が表示されます。
増分更新:`Refresh` タスクが表示されます。
モニタリングメトリックを使用した更新タスクの確認
QPS、1 秒あたりのレコード数(RPS)、遅延などのメトリックを確認して、動的テーブル更新タスクの実行状況を把握できます。`Command Type` が `refresh` の場合、動的テーブル更新タスクを示します。モニタリングメトリックの詳細については、「Hologres コンソールのモニタリングメトリック」をご参照ください。
動的テーブル更新タスクがサーバーレスコンピューティングリソース上で実行されている場合、関連するサーバーレスコンピューティングメトリックからもそのステータスを確認できます。
Cloud Monitor で動的テーブル更新タスクのアラートルールを作成できます。詳細については、「Cloud Monitor」をご参照ください。
過去の更新タスクの確認
hologres.hg_dynamic_table_refresh_history を使用した確認
hologres.hg_dynamic_table_refresh_history システムテーブルには、過去 1 か月間のすべての動的テーブル更新タスク(フル更新、増分更新、手動更新を含む)の履歴が記録されます。hologres.hg_dynamic_table_refresh_history システムテーブルのフィールドの詳細については、「hologres.hg_dynamic_table_refresh_history システムテーブル」をご参照ください。
デフォルトでは、過去 1 か月分のレコードが保持されます。1 か月以上前のデータはクエリできません。
テーブルオーナーは自身の更新履歴のみを確認できますが、Superuser はすべての更新レコードを確認できます。
例 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 日間の現在のインスタンス内のすべての更新タスクを表示します。
-- 過去 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 日間の特定のテーブルの更新レコードを表示します。
-- 過去 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='<scehma_name>' and dynamic_table_name='<dynamic_table>' and refresh_start >= CURRENT_DATE - INTERVAL '1 day'
従来の 3.0 構文で作成されたフル更新の動的テーブルの場合、hologres.hg_dynamic_table_refresh_history に記録される更新の成功/失敗ステータスが実際の状態と一致しないことがあります。失敗した更新が `Success` として表示される可能性があります。3.0 構文で作成されたフル更新動的テーブルの正確な過去の更新ステータスを取得するには、以下の手順を実行します。
cron_job_nameをhologres.hg_dynamic_table_propertiesから取得します。取得した
cron_job_nameを使用して、hologres.hg_user_cron_tasks内の Cron タスク実行レコードをクエリします。
-- 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';
-- cron_job_name で 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 < '199
6-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)更新タイムアウト期間の設定
通常のクエリと同様に、動的テーブル更新タスクのタイムアウト期間を設定できます。
テーブルレベルの設定
動的テーブルを作成する際に、そのテーブルのすべての更新タスクに適用される更新タスクのタイムアウト期間を設定できます。以下の SQL コードは、tpch_10g 公開データセットを例として使用しています。コードを実行する前に、tpch_10g 公開データセットを正常にインポート済みであることを確認してください。詳細については、「公開データセットのインポートタスクの作成」をご参照ください。
-- テーブル作成時に更新タスクのタイムアウト期間を設定
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 mins'-- 更新タイムアウト期間は 30 分
)
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;セッションレベルの設定
手動更新を実行する際に、セッションレベルの Grand Unified Configuration(GUC)パラメーターを使用してタイムアウト期間を設定できます。以下の SQL 文がその例です。
SET statement_timeout = <time>;
refresh DYNAMIC TABLE <dynamic_schema_name.dynamic_table_name>;設定の詳細については、「アクティブクエリのタイムアウト期間の変更」をご参照ください。
refresh with option を使用した設定
手動更新を実行する際に、refresh ... with (refresh_guc_statement_timeout = '...') を使用して、現在の更新のタイムアウト期間を指定することもできます。以下に例を示します。
REFRESH DYNAMIC TABLE <schema_name.table_name> WITH (
refresh_guc_statement_timeout = '30 mins'
);手動更新
動的テーブルを手動で更新できます。構文は以下のとおりです。
REFRESH DYNAMIC TABLE <schema_name.table_name>;テーブルプロパティで自動更新が有効になっている場合、手動更新は自動更新タスクと並行して実行されます。両方のタスクは正常に実行され、システムは最新データのコピーを 1 つだけ保持することを保証します。
更新タスクのキャンセル
新しい 3.1 構文で作成された動的テーブル
実行中の更新タスクのキャンセル
新しい 3.1 構文で作成された動的テーブルの場合、まず query_job_id を hologres.hg_dynamic_table_refresh_log から取得し、次に hologres.hg_internal_cancel_query_job を使用してタスクをキャンセルします。
-- query_job_id を取得
SELECT query_job_id
FROM hologres.hg_dynamic_table_refresh_log('<dt_name>')
WHERE status = 'Running';
-- query_job_id に基づいて更新タスクをキャンセル
SELECT hologres.hg_internal_cancel_query_job('<query_job_id>');hologres.hg_internal_cancel_query_job を使用して更新タスクをキャンセルできるのは、Superuser のみです。
テーブルのすべての更新タスクのキャンセル
動的テーブルに更新タスクが設定されている場合、ALTER TABLE 文を実行して、テーブルレベルですべての後続の更新タスクをキャンセルできます。更新を再度有効にする方法については、「ALTER DYNAMIC TABLE」をご参照ください。
ALTER DYNAMIC TABLE [ IF EXISTS ] [<schema>.]<table_name> SET (auto_refresh_enable=false);この操作は慎重に行ってください。そうしないと、後続のデータが更新されない可能性があります。
3.0 構文で作成された動的テーブル
実行中の更新タスクのキャンセル
更新タスクが長時間完了せずに実行されている場合や、カクつきなどの問題が発生している場合は、pg_cancel_backend を使用して実行中の更新タスクをキャンセルできます。
以下のコマンドを実行して、単一の実行中の更新タスクをキャンセルします。
-- pid は更新タスク ID です。更新タスクを確認することで query_id を取得できます。
SELECT pg_cancel_backend(<pid>);`pid` パラメーターは更新タスク ID です。更新タスク ID(`query_id`)は、更新タスクを確認することで取得できます。詳細については、「更新タスクの確認」をご参照ください。
実行中の更新タスクを一括でキャンセルする方法は、通常のクエリの場合と同じです。詳細については、「クエリの停止」をご参照ください。
テーブルのすべての更新タスクのキャンセル
動的テーブルに更新タスクが設定されている場合、ALTER DYNAMIC TABLE コマンドを使用して、テーブルレベルですべての後続の更新タスクをキャンセルできます。
ALTER DYNAMIC TABLE [IF EXISTS ] [<schema>.]<table_name> set (auto_refresh_enable=false);この操作は慎重に行ってください。そうしないと、後続のデータが更新されない可能性があります。