表示されているのは 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 パラメータを使用してモデルのキャッシュ保持ポリシーをデータベースの ETL スケジュールと同期し、max_cache_age パラメータでキャッシュの有効期限間隔を設定できます。詳細については、データグループによるクエリのキャッシングと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" など）を指定します。

1 つのデータグループに、少なくとも 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 パラメータがあります。これは、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] ページから、データグループに関連付けられているすべてのキャッシュを削除できます。