このページでは、derived_table の一部である
persist_forパラメータについて説明します。
persist_forは、persist_for（Explore 用）パラメータのドキュメント ページで説明されているように、Explore の一部としても使用できます。
persist_forは、persist_for（モデル用）パラメータのドキュメント ページで説明されているように、モデルの一部としても使用できます。
用途
view: my_view {
derived_table: {
persist_for: "24 hours"
...
}
}
|
階層
persist_for |
デフォルト値
なし
許可
整数と期間（秒、分、時間）を含む文字列
|
定義
代わりに、クエリのキャッシュ保存に関するドキュメントで説明されている
datagroupパラメータとdatagroup_triggerパラメータの使用を検討してください。
persist_for を使用すると、永続的な派生テーブルが再生成される前に使用できる最大時間を設定できます。ユーザーが persist_for 派生テーブルに依存するクエリを実行すると、Looker はテーブルの経過時間を persist_for と比較します。経過時間が persist_for 設定よりも大きい場合、クエリの実行前に派生テーブルが再生成されます。経過時間が persist_for 設定より短い場合は、既存の派生テーブルが使用されます。
PDT の persist_for は、モデルと Explore の persist_for パラメータとは独立して実行されます。
管理者が develop 権限を付与している場合は、派生テーブルの persist_for の有効期限が切れる前に、派生テーブルを強制的に再生成できます。[Explore アクション] の歯車アイコンのプルダウン メニューから [派生テーブルの再ビルドと実行] オプションを選択します。
[派生テーブルを再構築して実行する] オプションの詳細については、Looker の派生テーブルのドキュメント ページをご覧ください。
例
派生テーブルが 1 時間以上経過している場合は再生成する
persist_for: "1 hour"
派生テーブルが 1.5 時間以上経過している場合は再生成する
persist_for: "90 minutes"
派生テーブルが 1 日以上経過している場合は再生成する
persist_for: "24 hours"
注意点
persist_for を使用するには、永続的な派生テーブルを有効にする必要があります
Looker インスタンスで派生テーブルの永続性を有効にしていない限り、persist_for は効果がありません。ほとんどのお客様は、Looker を最初に構成するときに永続的な派生テーブルを設定します。このルールの最も一般的な例外は、Looker を PostgreSQL の読み取り専用のホットスワップ レプリカ データベースに接続するお客様です。
persist_for の動作が Development Mode と本番環境モードで異なる
persist_for は、本番環境モードで想定どおりに動作します。開発モードでは、persist_for をより長い値に設定した場合でも、すべての派生テーブルは最大 24 時間永続化されます。
詳しくは、Looker の派生テーブル ドキュメントの Development Mode の永続テーブルをご覧ください。
persist_for の代替手段
persist_for の期間が終了すると、Looker は新しい派生テーブルを自動的に再生成しません。テーブルは削除され、ユーザーが次回クエリを実行したときに新しい派生テーブルが生成されます。ユーザー クエリが派生テーブルの生成をトリガーするのを待つのではなく、sql_trigger_value を使用して派生テーブルの自動再生成をスケジュールできます。
datagroup と max_cache_age の違い
datagroup_trigger パラメータで datagroup パラメータを使用すると、PDT の再ビルドをトリガーする際の柔軟性が高まります。ただし、max_cache_age パラメータはキャッシュを無効にするだけで、PDT の有効期限が切れることはありません。スクラッチ スキーマから PDT を削除するまでの最大期間を設定する場合は、派生テーブルで persist_for を使用します。