【2024/2/13アップデート】INTERVALデータ型・Continue Handlerについての検証

# はじめに
今回は2024/2/13アップデートの【INTERVAL データ型のサポート開始】と【Continue Handler ステートメントのサポート開始】についての検証結果をご紹介いたします。

https://aws.amazon.com/jp/about-aws/whats-new/2024/02/amazon-redshift-interval-data-type-continue-handler-statements/


# 目次
【INTERVAL データ型のサポート開始】について
　・INTERVAL型とは
　・実際に使用してみよう
　・INTERVAL型を使用することの利点
【Continue Handler ステートメントのサポート開始】について
　・Redshiftにおけるストアドプロシージャとは
　・Continue Handlerとは
　・実施に使用してみよう
　・Continue Handlerを使用することの利点
　・所感
 

# 【INTERVAL データ型のサポート開始】について
**Amazon Redshiftにて期間または時間範囲を指定できるINTERVALデータ型のサポートを開始した**、というのがアップデートの内容です。


## INTERVAL型とは
>間隔のデータ型を使用して、**seconds、minutes、hours、days、months、years などの単位で期間を保存できます。** 間隔のデータ型とリテラルは、日付とタイムスタンプへの間隔の追加、間隔の合計、日付またはタイムスタンプからの間隔の減算など、**日時の計算に使用できます。** 間隔リテラルは、テーブル内の間隔データ型列への入力値として使用できます。
：AWS公式から引用

:::note info
・INTERVAL型は、時間間隔を表す
・使用することで日時の計算を簡素化することができる
:::


## 実際に使用してみよう
### 利用サービスと準備するもの
・Redshift
　クラスター×1
　テーブル×1
・IAM
　IAMロール×1
　＜ポリシー＞
　AmazonRedshiftAllCommandsFullAccess

### テーブル作成
今回は、勤怠時間の管理をイメージして、社員番号（employee_id）と労働時間（work_time）のカラムを作成します。
```SQL
CREATE TABLE test_schema.sample_interval_time_t(
    employee_id varchar(4)
    ,work_time interval day to second
) DISTSTYLE AUTO;
```

いくつかデータもインサートしてみます。
```SQL
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）が時間数で保持されていることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074902/1e60ae25-6056-48ad-abd4-ec6e5b855e10.png)

## INTERVAL型を使用することの利点
**明示的に日数・時間数・秒数等の経過時間を直接保存できる**というのが、INTERVALデータ型を使用することの大きな利点です。

今回の例のように、勤怠時間の管理を行う場合、2つの日付を別々に保存したり、クエリの実行時に差分を計算したりする必要がありましたが、INTERVAL型使用によりその手間がなくなります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074902/67e9360f-345d-c74b-e4d4-fa619f13e2a2.png)

詳細については下記AWS公式サイトをご確認ください。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_interval_data_types.html


# 【Continue Handler ステートメントのサポート開始】について
Redshift で、**ストアドプロシージャ内の実行フローをより適切に制御できる Continue Handler のサポートを開始した**、というのがアップデートの内容です。


## Redshiftにおけるストアドプロシージャとは
>ストアドプロシージャは、通常、**データ変換やデータ検証のロジック、ビジネス固有のロジックをカプセル化するために使用します。** 複数の SQL ステップをストアドプロシージャにまとめることで、アプリケーションとデータベースを往復する回数を減らすことができます。
：AWS公式から引用

:::note info
・ストアドプロシージャとは、**一連の処理を1つのプログラムとしてまとめてデータベースに保存したもの**
・ネットワーク・サーバーの負荷を減らすことができる
:::

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/stored-procedure-create.html


## Continue Handlerとは
>ハンドラーは、NONATOMIC ストアード・プロシージャー内の実行フローを制御する例外ハンドラーの一種です。これを使用することで、次のことができます。既存のステートメントブロックを終了せずに例外をキャッチして処理します。通常、格納されている プロシージャーの場合、フローは中断され、エラーは呼び出し元に返されます。しかし 一部のユースケースでは、フローを中断するほどエラー状態が深刻ではありません。あなたは、別のトランザクションで選択したエラー処理ロジックを使用して正常にエラーを実行し、エラーに続くステートメントの実行を続行します。
：AWS公式から引用


:::note info
・Continue Handlerを使用することで、深刻でないエラーをスルーするようにできる
:::

https://docs.aws.amazon.com/redshift/latest/dg/stored-procedure-trapping-errors.html

## 実際に使用してみよう
※INTERVAL型の検証で作成したもの以外を記載します
・Redshift
　テーブル×2
　ストアドプロシージャ×2

 ### テーブル作成
ストアドプロシージャでデータを格納するtbl_1テーブル、エラーログを格納するtbl_error_loggingテーブルを作成します。
```SQL
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を利用したストアドプロシージャ
```SQL
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を利用したストアドプロシージャ
```SQL
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のレコードを想定どおり格納していることが分かります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2777457/2438a0d8-f848-22e7-6421-481bdff46f4f.png)


## Continue Handlerを使用することの利点
エラー発生時に処理を継続できることがContinue Handlerの利点です。そのため想定するエラーがあり回避したい場合、エラーログを記録したい場合、テスト実行をしたい場合などで活用が期待できます。

## 所感
今回のアップデートで不要なカラムの削減と、Redshiftのみで処理を完結することができるようになりました。(以前まではエラー発生時にフローが中断してしまうためGlueやLambdaなど他AWSサービスを組合せる必要があった)
今後も利用者の要望に沿ったアップデートが実現され、各サービスが利用しやすくなることに期待します。

---------------------------------------------------

 株式会社ジールでは、「ITリテラシーがない」「初期費用がかけられない」「親切・丁寧な支援がほしい」「ノーコード・ローコードがよい」「運用・保守の手間をかけられない」などのお客様の声を受けて、オールインワン型データ活用プラットフォーム「ZEUSCloud」を月額利用料にてご提供しております。
ご興味がある方は是非下記のリンクをご覧ください：

https://www.zdh.co.jp/products-services/cloud-data/zeuscloud/?utm_source=qiita&utm_medium=referral&utm_campaign=qiita_zeuscloud_content-area