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] ページから、データグループに関連付けられているすべてのキャッシュを削除できます。