一時テーブル
複雑なデータ処理タスクを実行する際、大規模な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はサポートされていません。
- 一時テーブルが削除される際、リサイクルビンには移動せず、即座に完全削除されます。
