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] ウィンドウで、データベースから強制的に新たな結果を取得することもできます。クエリを実行した後（統合された結果クエリ）、キャッシュをクリアして更新オプションからアクションを探す歯車メニューして、ソース別にトラフィックデータを分類します。

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

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

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

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

データグループの定義

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

datagroup パラメータには次のサブパラメータを含めることができます。

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

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

ここでは、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 の連携に関する詳細は、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 パラメータがあります。このパラメータは、クエリ select max(id) from my_tablename を使用して ETL が発生したことを検出するように指定します。たとえしばらくの間　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] ページから、データグループに関連付けられているすべてのキャッシュを削除できます。