一時テーブル
複雑なデータ処理タスクを実行する際、大規模なSQLクエリを複数のステップに分割し、各ステップの結果を物理テーブルとして一時的に保存することは効果的な戦略です。この方法により、SQLクエリの複雑さを大幅に軽減し、データのデバッグ性を向上させることができます。ただし、これらの物理テーブルは目的を果たした後、手動でクリーンアップする必要があることに注意が必要です。非物理的な一時テーブルが望ましい場合、Dorisは現在WITH句を介した定義のみをサポートしています。
上記の問題に対処するため、Dorisは一時テーブル機能を導入しています。一時テーブルは一時的に存在するマテリアライズされた内部テーブルであり、以下の主な特徴があります：
-
セッションバインディング: 一時テーブルは作成されたセッション内でのみ存在します。そのライフサイクルは現在のセッションと密接に結びついており、セッションが終了すると、そのセッション内で作成された一時テーブルは自動的に削除されます。
-
セッション固有の可視性: 一時テーブルの可視性は、作成されたセッションに厳密に限定されます。同じユーザーが同時に開始した別のセッションであっても、これらの一時テーブルにはアクセスできません。
一時テーブル機能の導入により、Dorisは複雑なデータ処理における一時的なデータストレージと管理を簡素化するだけでなく、データ処理の柔軟性とセキュリティをさらに向上させます。
内部テーブルと同様に、一時テーブルはInternal カタログ内のDatabase下に作成する必要があります。ただし、一時テーブルはセッションベースであるため、その命名は一意性制約の対象ではありません。異なるセッションで同じ名前の一時テーブルを作成したり、他の内部テーブルと同じ名前の一時テーブルを作成したりすることができます。
同じDatabase内で同じ名前の一時テーブルと非一時テーブルが同時に存在する場合、一時テーブルが最高のアクセス優先度を持ちます。そのセッション内では、同じ名前のテーブルに対するすべてのクエリと操作は一時テーブルにのみ影響します（マテリアライズドビューの作成を除く）。
使用方法
一時テーブルの作成
Unique、Aggregate、Duplicateモデルのいずれであっても、様々なモデルのテーブルを一時テーブルとして定義できます。以下のSQL文でTEMPORARYキーワードを追加することで一時テーブルを作成できます：
一時テーブルのその他の使用方法は基本的に通常の内部テーブルと同じです。上記のCreate文を除き、他のDDLおよびDML文ではTEMPORARYキーワードを追加する必要はありません。
注意事項
- 一時テーブルはInternal カタログでのみ作成できます。
- テーブル作成時にENGINEをOLAPに設定する必要があります。
- 一時テーブルの変更にはAlter文はサポートされていません。
- 一時的な性質のため、一時テーブルに基づくビューやマテリアライズドビューの作成はサポートされていません。
- 一時テーブルはバックアップできず、CCR/Sync Jobを使用した同期もサポートされていません。
- Export、Stream Load、Broker Load、S3 Load、MySQL Load、Routine Load、Spark Loadはサポートされていません。
- 一時テーブルが削除される際、リサイクルビンには移動せず、即座に完全削除されます。
