Looker のドキュメントを表示していることに注意してください。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

クエリのキャッシング

Looker では、以前の SQL クエリの結果が使用可能になり、キャッシュ保存ポリシーがこの関数を許可されている場合に、データベースの負荷を軽減し、パフォーマンスを向上させます。このページでは、Looker のデフォルトのキャッシュポリシーについて説明します。また、Looker インスタンスでキャッシュに保存された結果の期間を変更するオプションについても説明します。

Lookerにおけるキャッシュされたクエリの用途

Looker における SQL クエリのキャッシングの仕組みは次のとおりです。

Explore、Look、またはダッシュボードから SQL クエリを実行すると、Looker はそのキャッシュ結果をチェックして、そのクエリに対するキャッシュ結果がすでに存在するかどうかを確認します。キャッシュされた結果は、フィールド、フィルタ、パラメータ、行の制限など、クエリのすべての要素が同じ場合にのみ使用されます。
キャッシュに保存された結果が見つかると、Looker は LookML モデルで定義されているキャッシングポリシーをチェックして、キャッシュに保存された結果が期限切れかどうかを判断します。キャッシュに保存されている結果が期限切れでない場合、Looker はキャッシュに保存されている結果をクエリに使用します。
キャッシュに保存された結果がクエリに見つからない場合、またはキャッシュに保存された結果が期限切れの場合、Looker はデータベースに対してクエリを実行します。その後、新しいクエリ結果がキャッシュに保存されます。

デフォルトのキャッシュ保持ポリシーは 1 時間です。次のキャッシュ保持ポリシーの変更では、この時間を短縮または延長する方法と、キャッシュ保持ポリシーをデータベースの ETL（抽出、変換、読み込み）に同期するためのオプションについて説明します。

キャッシュ保持ポリシーの変更

キャッシュ保持ポリシーは、LookML Explore レベルと LookML モデルレベルで指定できます。

推奨されるキャッシュメカニズムは、モデルレベルで datagroup パラメータを使用することです。データグループでは、sql_trigger パラメータを使用し、max_cache_age パラメータでキャッシュの有効期限を設定して、モデルのキャッシュ保持ポリシーをデータベースの ETL スケジュールと同期できます。詳細については、データグループによるクエリのキャッシングとPDTの再構築をご覧ください。

代わりに、persist_for パラメータをモデルレベルまたは Explore レベルで使用すると、よりシンプルになります。persist_for パラメータをこのように使用して、デフォルトの 1 時間間隔をオーバーライドするキャッシュ有効期限間隔を設定できます。ただし、persist_for を使用する理由は、いくつかの理由からデータグループを使用する場合よりも堅牢性に劣ります。詳細については、persistent_for でのクエリのキャッシュセクションをご覧ください。

Explore またはモデルにデータグループまたは persist_for が定義されている場合、キャッシングポリシーは次のように変更されます。

persist_for 間隔またはデータグループの max_cache_age 間隔が期限切れになる前: クエリが再実行されると、Looker はキャッシュからデータを pull します。
persist_for 間隔またはデータグループの max_cache_age 間隔が期限切れになる時点: Looker はキャッシュからデータを削除します。
persist_for 間隔またはデータグループの max_cache_age 間隔の後: クエリが再実行された場合、Looker はデータベースからデータを直接 pull し、persist_for 間隔または max_cache_age 間隔をリセットします。

重要な点は、persist_for または max_cache_age の間隔が期限切れになると、データがキャッシュから削除されることです。

キャッシュが保存容量の上限に達すると、LRU（Least Recently Used）アルゴリズムに基づいてデータが押し出されます。これは、persist_for 間隔または max_cache_age 間隔が経過したデータが一すべて一括で削除されることを保証するものではありません。

データがキャッシュに保存される期間を最小限に抑える

Looker では、常にクエリ結果がキャッシュに書き込まれます。persist_for と max_cache_age の間隔がゼロに設定されていても、キャッシュされたデータは最大 10 分間保存されます。ディスクキャッシュに保存されているすべての顧客データは、高度暗号化標準（AES）で暗号化されます。

データがキャッシュに保存される時間を最小限に抑えるには:

persist_for パラメータ（モデルまたは Explore の場合）または max_cache_age パラメータ（データグループの場合）は、値を 0 minutes に設定します。persist_for 間隔の期限が切れるか、データがデータグループで指定された max_cache_age 間隔に達すると、Looker によりキャッシュが削除されます。（キャッシュに保存されるデータの量を最小限に抑えるために、PDT の persist_for パラメータを 0 minutes に設定する必要はありません。PDT は、キャッシュではなくデータベース自体に書き込まれます）。
suggest_persist_for パラメータに小さい間隔を設定します。suggest_persist_for の値は、フィルタの候補をキャッシュに保存する期間を指定するものです。フィルタの候補は、フィルタするフィールドの値のクエリに基づいています。ユーザーがフィルタテキストフィールドに入力する際にすばやくフィルタの候補を表示できるように、こうしたクエリ結果がキャッシュに保存されます。デフォルトでは、フィルタの候補は6時間キャッシュに保存されます。データがキャッシュ内に存在する期間を最小限に抑えるには、suggest_persist_for の値を 5 minutes など、より短い時間に設定します。

クエリの結果がキャッシュから返されたものかどうかを確認する

クエリ実行後に [Explore] ウィンドウの右上隅を確認すると、クエリの結果がキャッシュから返されたかどうかを判断できます。

キャッシュからクエリが返されると、「キャッシュから」と表示されます。それ以外の場合、クエリを返すためにかかった合計時間が表示されます。

データベースから強制的に新しい結果が生成されるようにする

[Explore] ウィンドウで、データベースから強制的に新たな結果を取得することもできます。クエリ（マージされた結果クエリを含む）を実行した後に、画面の右上にある [アクションを探す] 歯車メニューから [キャッシュをクリアして更新] オプションを選択します。

データグループによるクエリのキャッシングとPDTの再構築

データグループを使用して、データベースの ETL（抽出、変換、読み込み）スケジュールを Looker のキャッシュポリシーと PDT の再構築スケジュールと連携させます。

データグループを使用すると、データベースに新しいデータが追加されるタイミングに基づいて、PDT の再構築トリガーを指定できます。同じデータグループを Explore やモデルに適用すると、PDT が再構築されたときにキャッシュに保存された結果も期限切れになります。

また、データグループを使用して、キャッシュに保持される最大期間からPDT再構築トリガーを切り離すことができます。これは、かなり頻繁に更新されるデータに基づく Explore があり、より低い頻度で再構築される PDT に結合されている場合に便利です。このようなケースでは、PDTが再構築される頻度よりも頻繁にクエリキャッシュをリセットしたいと思うでしょう。

データグループの定義

モデルファイルまたは独自の LookML ファイルで、datagroup パラメータを使用してデータグループを定義します。プロジェクトの異なるExploreやPDTに対して、それぞれ異なるキャッシングポリシーやPDT再構築ポリシーを設定したい場合は、複数のデータグループを定義できます。

datagroup パラメータには次のサブパラメータを使用できます。

label — データグループのラベルを指定します（オプション）。
description - データグループの目的と仕組みを説明するために使用できる、データグループの説明を指定します（省略可）。
max_cache_age - 期間を定義する文字列を指定します。Looker ではクエリがキャッシュされてからこの期間を過ぎると、キャッシュは無効となります。次回このクエリが発行されると、クエリはデータベースに送られ、最新の結果が取得されます。
sql_trigger - 1 つの行と 1 つの列を返す SQL クエリを指定します。クエリから返される値がクエリの以前の結果と異なる場合、データグループはトリガー状態になります。
interval_trigger - データグループをトリガーするタイムスケジュール（"24 hours" など）を指定します。

これらのパラメータの詳細については、datagroup のドキュメントページをご覧ください。

データグループには、少なくとも max_cache_age パラメータ、sql_trigger パラメータ、または interval_trigger パラメータが必要です。

注: データグループには sql_trigger パラメータと interval_trigger パラメータの両方を含めることはできません。両方のパラメータを指定してデータグループを定義した場合、そのデータグループは interval_trigger 値を使用し、sql_trigger の値は無視します。sql_trigger パラメータの場合、Looker がデータベースをクエリするときにデータベースリソースを使用する必要があるためです。

ここでは、sql_trigger が毎日 PDT を再ビルドするように設定されたデータグループの例を示します。また、いずれかの Explore で、1 日 1 回より高い頻度で更新される他のデータと PDT が結合されている場合に備えて、クエリキャッシュを 2 時間おきにクリアするように max_cache_age を設定します。

datagroup: customers_datagroup {
  sql_trigger: SELECT DATE(NOW());;
  max_cache_age: "2 hours"
}

データグループを定義したら、それをExploreとPDTに割り当てることができます。

データグループを PDT に割り当てるには、derived_table パラメータの下にある datagroup_trigger パラメータを使用します。例については、このページのデータグループを使用して PDT の再構築トリガーを指定するをご覧ください。
データグループを Explore に割り当てるには、モデルレベルまたは Explore レベルで persist_with パラメータを使用します。例については、このページのデータグループを使用して Explore のクエリキャッシュリセットを指定するをご覧ください。

データグループを使用してPDTの再構築トリガーを指定する

データグループを使用して PDT 再ビルドトリガーを定義するには、sql_trigger サブパラメータまたは interval_trigger サブパラメータを指定して datagroup パラメータを作成します。次に、PDT の derived_table 定義内の datagroup_trigger サブパラメータを使用して、データグループを個々の PDT に割り当てます。PDT に datagroup_trigger を使用する場合は、派生テーブルに対してその他の永続化戦略を指定する必要はありません。PDT に複数の永続化戦略を指定すると、Looker IDE で警告が表示され、datagroup_trigger のみが使用されます。

customers_datagroup データグループを使用する PDT 定義の例を次に示します。この定義では、customer_id と first_order_date の両方にインデックスがいくつか追加されます。PDT の定義について詳しくは、Looker の派生テーブルに関するドキュメントページをご覧ください。

view: customer_order_facts {
  derived_table: {
    sql: ... ;;
    datagroup_trigger: customers_datagroup
    indexes: ["customer_id", "first_order_date"]
  }
}

他の PDT との依存関係があるカスケード PDT の場合は、矛盾するデータグループキャッシングポリシーを指定しないよう注意してください。

接続パラメータを指定するユーザー属性がある接続で、次のいずれかを行う場合は、PDT オーバーライドフィールドを使用して個別の接続を作成する必要があります。

モデルで PDT を使用する

データグループを使用して PDT 再ビルドトリガーを定義する

PDT のオーバーライドがなくても、max_cache_age でデータグループを使用して Explore のキャッシュポリシーを定義できます。

データグループと PDT の連携に関する詳細は、Looker の派生テーブルのドキュメントをご覧ください。

データグループを使用してExploreのクエリキャッシュリセットを指定する

データグループがトリガーされると、Looker リジェネレータによって、そのデータグループを永続性戦略として使用する PDT が再構築されます。データグループの　PDT　が再構築されたら、Looker　は、データグループの再構築　PDT　を使用する　Explore　のキャッシュをクリアします。データグループのクエリキャッシュのリセットスケジュールをカスタマイズする場合は、データグループ定義に max_cache_age パラメータを追加できます。max_cache_age パラメータによって、データグループの　PDT　が再構築される際に　Looker　が実行する自動クエリ　キャッシュ　リセットに加えて、指定したスケジュールでクエリ　キャッシュをクリアできます。

データグループでクエリキャッシングポリシーを定義するには、max_cache_age サブパラメータを使用して datagroup パラメータを作成します。

Explore のクエリキャッシュのリセットに使用するデータグループを指定するには、persist_with パラメータを使用します。

データグループをモデル内のすべての Explore のデフォルトとして割り当てるには、persist_with パラメータをモデルレベル（モデルファイル内）で使用します。
データグループを個々の Explore に割り当てるには、explore パラメータの下の persist_with パラメータを使用します。

次の例は、モデルファイルで定義されている orders_datagroup という名前のデータグループを示しています。データグループには sql_trigger パラメータがあり、ETL の発生を検出するためにクエリ select max(id) from my_tablename が使用されます。たとえしばらくの間　ETL　が行われなかったとしても、データグループの max_cache_age によって、キャッシュ　データは最大　24　時間までしか使用しないと定められています。

モデルの persist_with パラメータは orders_datagroup キャッシュポリシーを指します。つまり、これがモデル内のすべての Explore のデフォルトのキャッシングポリシーになります。ただし、customer_facts と customer_background の Explore ではモデルのデフォルトキャッシュポリシーを使用しないため、persist_with パラメータを追加して別のキャッシュポリシーを指定できます。orders と orders_facts の Explore には persist_with パラメータがないため、モデルのデフォルトのキャッシングポリシー orders_datagroup が使用されます。

datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
}

datagroup: customers_datagroup {
  sql_trigger: SELECT max(id) FROM my_other_tablename ;;
}

persist_with: orders_datagroup

explore: orders { ... }

explore: order_facts { ... }

explore: customer_facts {
  persist_with: customers_datagroup
  ...
}

explore: customer_background {
  persist_with: customers_datagroup
  ...
}

persist_with と persist_for の両方が指定された場合は、検証警告が表示され、persist_with が使用されます。

データグループを使ってスケジュールされた配信をトリガーする

データグループは、ダッシュボードや Look の配信をトリガーするためにも使用できます。このオプションを使うと、データグループが完了するとLookerはデータを送信し、スケジュール設定されたコンテンツが最新の状態となります。

データグループの [Admin] パネルを使用する

Looker の管理者ロールを持っている場合は、管理パネルのデータグループページを使用して既存のデータグループを表示できます。各データグループの接続、モデル、現在のステータスを確認できます。また、LookML で指定されている場合は、各データグループのラベルと説明を確認できます。また、データグループのキャッシュのリセット、データグループのトリガー、データグループの　LookML　への移動が可能です。

`persist_for` を使用したクエリのキャッシュ

モデルレベルまたは Explore レベルで persist_for パラメータを使用して、Looker のデフォルトのキャッシュ保持期間を 1 時間に変更します。間隔は 0 minutes（最小）または 8760 hours（1 年）以上に設定できます。

persist_for パラメータの定義は、データグループの定義よりも高速かつ簡単ですが、堅牢性が劣ります。次の理由から、persist_for よりもデータグループをおすすめします。

データグループは、データベースの ETL プロセスと同期できます。
データグループは複数のモデルや Explore で再利用できます。つまり、データグループの max_cache_age を更新すると、そのデータグループが使用されるすべての場所のキャッシュポリシーが更新されます。
[Datagroups] ページから、データグループに関連付けられているすべてのキャッシュを削除できます。