はじめに
今回は2024/2/13アップデートの【INTERVAL データ型のサポート開始】と【Continue Handler ステートメントのサポート開始】についての検証結果をご紹介いたします。
目次
【INTERVAL データ型のサポート開始】について
・INTERVAL型とは
・実際に使用してみよう
・INTERVAL型を使用することの利点
【Continue Handler ステートメントのサポート開始】について
・Redshiftにおけるストアドプロシージャとは
・Continue Handlerとは
・実施に使用してみよう
・Continue Handlerを使用することの利点
・所感
【INTERVAL データ型のサポート開始】について
Amazon Redshiftにて期間または時間範囲を指定できるINTERVALデータ型のサポートを開始した、というのがアップデートの内容です。
INTERVAL型とは
間隔のデータ型を使用して、seconds、minutes、hours、days、months、years などの単位で期間を保存できます。 間隔のデータ型とリテラルは、日付とタイムスタンプへの間隔の追加、間隔の合計、日付またはタイムスタンプからの間隔の減算など、日時の計算に使用できます。 間隔リテラルは、テーブル内の間隔データ型列への入力値として使用できます。
：AWS公式から引用
・INTERVAL型は、時間間隔を表す
・使用することで日時の計算を簡素化することができる
実際に使用してみよう
利用サービスと準備するもの
・Redshift
クラスター×1
テーブル×1
・IAM
IAMロール×1
＜ポリシー＞
AmazonRedshiftAllCommandsFullAccess
テーブル作成
今回は、勤怠時間の管理をイメージして、社員番号（employee_id）と労働時間（work_time）のカラムを作成します。
CREATE TABLE test_schema.sample_interval_time_t(
employee_id varchar(4)
,work_time interval day to second
) DISTSTYLE AUTO;
いくつかデータもインサートしてみます。
insert into test_schema.sample_interval_time_t values ('1',interval '9' hour);
insert into test_schema.sample_interval_time_t values ('2',interval '5' hour);
insert into test_schema.sample_interval_time_t values ('3',interval '9' hour);
データをセレクト
実際にデータをセレクトしてみましょう。
労働時間（work_time）が時間数で保持されていることがわかります。
INTERVAL型を使用することの利点
明示的に日数・時間数・秒数等の経過時間を直接保存できるというのが、INTERVALデータ型を使用することの大きな利点です。
今回の例のように、勤怠時間の管理を行う場合、2つの日付を別々に保存したり、クエリの実行時に差分を計算したりする必要がありましたが、INTERVAL型使用によりその手間がなくなります。
詳細については下記AWS公式サイトをご確認ください。
【Continue Handler ステートメントのサポート開始】について
Redshift で、ストアドプロシージャ内の実行フローをより適切に制御できる Continue Handler のサポートを開始した、というのがアップデートの内容です。
Redshiftにおけるストアドプロシージャとは
ストアドプロシージャは、通常、データ変換やデータ検証のロジック、ビジネス固有のロジックをカプセル化するために使用します。 複数の SQL ステップをストアドプロシージャにまとめることで、アプリケーションとデータベースを往復する回数を減らすことができます。
：AWS公式から引用
・ストアドプロシージャとは、一連の処理を1つのプログラムとしてまとめてデータベースに保存したもの
・ネットワーク・サーバーの負荷を減らすことができる
Continue Handlerとは
ハンドラーは、NONATOMIC ストアード・プロシージャー内の実行フローを制御する例外ハンドラーの一種です。これを使用することで、次のことができます。既存のステートメントブロックを終了せずに例外をキャッチして処理します。通常、格納されている プロシージャーの場合、フローは中断され、エラーは呼び出し元に返されます。しかし 一部のユースケースでは、フローを中断するほどエラー状態が深刻ではありません。あなたは、別のトランザクションで選択したエラー処理ロジックを使用して正常にエラーを実行し、エラーに続くステートメントの実行を続行します。
：AWS公式から引用
・Continue Handlerを使用することで、深刻でないエラーをスルーするようにできる
実際に使用してみよう
※INTERVAL型の検証で作成したもの以外を記載します
・Redshift
テーブル×2
ストアドプロシージャ×2
テーブル作成
ストアドプロシージャでデータを格納するtbl_1テーブル、エラーログを格納するtbl_error_loggingテーブルを作成します。
CREATE TABLE tbl_1 (a int);
CREATE TABLE tbl_error_logging(info varchar, err_state varchar, err_msg varchar);
ストアドプロシージャ作成
検証のためにExit Handler(エラー発生時フローを中断する処理)とContinue Handler(エラー発生時フローを継続する処理)のストアドプロシージャを作成します。
＜処理概要（フロー）＞
①int型の1をインサート
②文字型のvalをインサート ※互換性のないデータ型のためエラーとなる
③int型の2をインサート
a.Exit Handlerを利用したストアドプロシージャ
CREATE OR REPLACE PROCEDURE test_schema.sp_exc_handling_1()
NONATOMIC
LANGUAGE plpgsql
AS $$
BEGIN
INSERT INTO test_schema.tbl_1 VALUES (1);
INSERT INTO test_schema.tbl_1 VALUES ("val"); -- ※互換性のないデータ型のためエラーとなる
INSERT INTO test_schema.tbl_1 VALUES (2);
EXCEPTION EXIT_HANDLER WHEN OTHERS THEN
INSERT INTO test_schema.tbl_error_logging VALUES ('Encountered error', SQLSTATE, SQLERRM);
END;
$$
b.Continue Handlerを利用したストアドプロシージャ
CREATE OR REPLACE PROCEDURE test_schema.sp_exc_handling_2()
NONATOMIC
LANGUAGE plpgsql
AS $$
BEGIN
INSERT INTO test_schema.tbl_1 VALUES (1);
INSERT INTO test_schema.tbl_1 VALUES ("val"); -- ※互換性のないデータ型のためエラーとなる
INSERT INTO test_schema.tbl_1 VALUES (2);
EXCEPTION CONTINUE_HANDLER WHEN OTHERS THEN
INSERT INTO test_schema.tbl_error_logging VALUES ('Encountered error', SQLSTATE, SQLERRM);
END;
$$
処理結果の比較
a,bのストアドプロシージャの結果を比較すると、エラーログに関してはどちらも格納していますが、格納データに関してはb.Continue Handlerを利用した処理のみエラー後もフローを継続し1,2のレコードを想定どおり格納していることが分かります。
Continue Handlerを使用することの利点
エラー発生時に処理を継続できることがContinue Handlerの利点です。そのため想定するエラーがあり回避したい場合、エラーログを記録したい場合、テスト実行をしたい場合などで活用が期待できます。
所感
今回のアップデートで不要なカラムの削減と、Redshiftのみで処理を完結することができるようになりました。(以前まではエラー発生時にフローが中断してしまうためGlueやLambdaなど他AWSサービスを組合せる必要があった)
今後も利用者の要望に沿ったアップデートが実現され、各サービスが利用しやすくなることに期待します。
株式会社ジールでは、「ITリテラシーがない」「初期費用がかけられない」「親切・丁寧な支援がほしい」「ノーコード・ローコードがよい」「運用・保守の手間をかけられない」などのお客様の声を受けて、オールインワン型データ活用プラットフォーム「ZEUSCloud」を月額利用料にてご提供しております。
ご興味がある方は是非下記のリンクをご覧ください：