これらのベスト プラクティスは、経験豊富な Looker の部門横断的なチームが共有する推奨事項を反映しています。これらのインサイトは、実装から長期的な成功に至るまで、Looker のお客様との連携に携わった長年の経験に基づいています。ベスト プラクティスはほとんどのユーザーと状況に対応するよう作成されていますが、実装の際は慎重に判断してください。
クエリのパフォーマンスの最適化
以下のフロントエンドとバックエンドのヒントを使用して、データベースに対して最適な方法でクエリを作成し実行することができます。
-
可能な限り、
many_to_one結合を使用して Explore を作成します。ビューを最も粒度の細かいレベルから最も詳細なレベル（many_to_one）まで結合すると、通常、クエリ パフォーマンスが最も高くなります。 -
可能な限りキャッシュを最大化して ETL ポリシーと同期し、データベースのクエリ トラフィックを削減します。デフォルトでは、Looker はクエリを 1 時間キャッシュに保存します。
persist_withパラメータを使用して Explore 内でデータグループを適用することで、キャッシュ ポリシーを制御し、Looker のデータ更新を ETL プロセスと同期できます。Looker とバックエンド データ パイプラインの統合を強化できるので、古いデータを分析するリスクを伴わずにキャッシュ使用量を最大化できます。名前の付けられたキャッシュ ポリシーをモデル全体や個々の Explore、永続的な派生テーブル（PDT）に適用することができます。 - Looker の集約テーブルの自動認識機能を使用して、Looker がロール アップまたはサマリー テーブルを作成できます。Looker は可能な限り、特に大規模なデータベースの一般的なクエリの場合にこのテーブルを使用できます。また、集約テーブルの自動認識を利用して、大幅にダッシュボード全体のパフォーマンスを改善することもできます。詳細については、集約テーブルの自動認識のチュートリアルをご覧ください。
- PDT を使用してクエリを高速化します。多くの複雑な結合やパフォーマンスの低い結合を持つ Explore や、サブクエリやサブセレクトを持つディメンションを PDT に変換すると、ビューが事前結合され、ランタイム前に使用可能な状態になります。
- データベース言語が増分 PDT をサポートしている場合は、増分 PDT を構成して、Looker が PDT テーブルの再構築にかかる時間を短縮します。
- Looker で定義された連結済みの主キーでビューを Explore に結合しないようにします。ビューに含まれる、連結済みの主キーを構成する基本フィールドで結合します。または、ビューの LookML ではなく、テーブルの SQL 定義で事前定義された連結済みの主キーを使用して、ビューを PDT として再作成します。
- ベンチマークには、SQL Runner ツールの Explain を利用します。
EXPLAINは、特定の SQL クエリに対するデータベースのクエリ実行プランの概要を生成します。これにより、最適化できるクエリ コンポーネントを検出できます。詳細については、コミュニティ投稿のEXPLAINを使用して SQL を最適化する方法をご覧ください。 -
インデックスを宣言します。各テーブルのインデックスは、Looker で SQL Runner から直接確認できます。テーブルの歯車アイコンをクリックし、[Show Indexes] を選択します。
よく使われる列のうち、インデックスのメリットを得られる列は、重要な日付と外部キーです。これらの列にインデックスを追加すると、ほぼすべてのクエリのパフォーマンスが向上します。これは PDT にも当てはまります。
indexes、sort keys、distributionなどの LookML パラメータが適切に適用できます。 - 不十分なハードウェア、または大規模なデータセットを処理するために必要なプロビジョニングされたリソース（AWS など）を備えたデータベースのメモリ、コア、I/O（入力/出力）を増やして、クエリのパフォーマンスを向上させます。
Looker サーバーのパフォーマンスの最適化
Looker のサーバーとアプリケーションが最適に機能するように、対策を講じることもできます。
- 個々のダッシュボード内の要素の数を制限します。各要素の設計がさまざまな要因に基づいてメモリ使用量に影響するため、数を定義するための明確なルールはありません。ただし、25 個以上のタイルを含むダッシュボードは、パフォーマンスに関して問題が生じる傾向があります。
- ダッシュボードの自動更新機能を戦略的に使用します。ダッシュボードで自動更新が使用されている場合、その更新はバックグラウンドで実行される ETL プロセスより速くならないようにしてください。
- ピボットを戦略的に使用し、ダッシュボード タイルや Look 内でピボットを過剰に使用しないようにします。ピボット ディメンションを含むクエリは、より多くのメモリを消費します。ピボットされるディメンションが多ければ多いほど、コンテンツ（Explore、Look、ダッシュボード）の読み込み時のメモリ消費量が増えます。
- 結果の統合、カスタム フィールド、表計算などのクエリ後の処理機能の使用は控えめにします。これらの機能は、モデルの設計に役立つ概念実証として使用することを目的としています。使用頻度の高い計算や関数は LookML にハードコードすることをおすすめします。これにより、データベースで処理される SQL を生成します。過剰な計算は Looker インスタンスの Java メモリと競合する可能性があるため、Looker インスタンスのレスポンスが遅くなります。
-
ビューファイルの数が多い場合は、モデル内に含めるビューの数を制限します。1 つのモデルにすべてのビューを含めると、パフォーマンスが低下する可能性があります。プロジェクト内に多数のビューがある場合は、各モデルに必要なビューファイルのみを含めることを検討してください。モデルにビューグループを簡単に含められるように、ビューファイルの名前に戦略的な命名規則を採用することを検討してください。例については、
includesパラメータのドキュメントをご覧ください。 -
ダッシュボードのタイルと Look 内に、大量のデータポイントをデフォルトで返すのを避けます。何千ものデータポイントを返すクエリは、より多くのメモリを消費します。フロントエンドのフィルタをダッシュボード、Look、Explore に適用し、LookML レベルで
required filters、conditionally_filter、sql_always_whereパラメータを使用して、可能な限りデータを制限できるようにします。 - クエリのサイズが非常に大きくなり、処理する際に Looker サーバーに負荷がかかる可能性があるため、[すべての結果] オプションを使用してのクエリのダウンロードや配信は控えめにします。
パフォーマンス問題の原因を特定するには、パフォーマンスの概要のベスト プラクティスのページをご覧ください。