ユーザーがデータを探索できるようにする最適な方法の 1 つは、効果的な Looker ダッシュボードを作成して、キュレートされたビューを提供することです。ユーザーに優れたパフォーマンスを提供したい場合は、ダッシュボードを設計する際にこのページのヒントを検討してください。
Looker ダッシュボードがブラウザに読み込まれます。最適なパフォーマンスを得るには、次の点に注意してください。
ダッシュボードのパフォーマンスで最も重要な要素は、基盤となる SQL クエリのパフォーマンスです。各ダッシュボードの要素は、キャッシュから返されない場合、基盤となるデータベースでの実行に時間がかかる SQL クエリを実行します。パフォーマンスの高いクエリの作成について詳しくは、Looker のパフォーマンスの最適化のベスト プラクティスのページのクエリ パフォーマンスの最適化セクションをご覧ください。
一部のコンポーネントは、SQL 関連よりもメモリ消費量が多いため、ダッシュボードでのパフォーマンスが低下する可能性があります。
-
データ量がパフォーマンスに最大の影響を与える。 個別の要素で返されるデータが増えれば増えるほど、消費されるメモリリソースが多くなります。何千ものデータポイントで返される Look とダッシュボードの要素によって、より多くのメモリが使用されます。
-
ダッシュボードの要素の数を制限する。 1 つの要素の設計がいくつかの要因（このページの後半で説明します）によってメモリ消費量に影響するため、数について厳密なルールはありません。それでも、クエリの数が 25 を超えるダッシュボードを作成することは避けてください。 ダッシュボードのパフォーマンスを適切に維持するには、ダッシュボード間でナビゲーション リンクを作成するか、カスタム URL へのリンクを作成することによって、ダダッシュボードからダッシュボードへのナビゲーションをキュレートします。類似するメジャーを同じ単独の値のビジュアリゼーションにまとめるようにすることで、単独のタイル ビジュアリゼーションの数が増えることを防ぐこともできます。
-
ダッシュボード設定を戦略的に使用する。 ダッシュボードでautorefreshを使用する場合は、リフレッシュが ETL プロセスよりも速く行われないようにします。通常、自動更新は 15 分以上に設定してください。ダッシュボードにフィルタを適用することが想定されている場合は読み込み時実行を使用しないでください。必須フィルタを使用して、ユーザーが必要なフィルタなしでダッシュボードを実行しないようにします。
-
キャッシュ保存を活用する。 データグループを使用してすべての Looker コンテンツ（ダッシュボード、Look、スケジュール）を ETL プロセスと同期することがベスト プラクティスです。これにより、データが最新でないときに必要でないクエリが行われないようにします。
-
結果の結合、カスタム フィールド、表計算などのクエリの後処理機能はメモリを消費する。使用するクエリの後処理機能が多ければ多いほど、メモリの消費が増えます。複数の Look やダッシュボードを横断して同じ表計算、結果の結合、カスタム フィールドを使用する場合は、可能な限り LookML モデルにそれらをハードコードすることを検討します。一般的に、1 つのダッシュボードに追加する結果の結合タイルは 4 つまでにします。
-
ピボット ディメンションはメモリを消費する。 Look またはダッシュボード タイルでピボットされるディメンションが多ければ多いほど、ダッシュボードの読み込み時のメモリ消費量が増えます。箇条書きの 1 つ目で説明したように、これは、より多くのデータが返されるとより多くのデータが使用されるためです。ピボットするディメンションのカーディナリティが高い（一意の値が多い）場合は、それぞれの値に 1 つずつ列があります。一度にすべてを表示するのではなく、ダッシュボードか Look のレベルでフィルタして、ユーザーが比較対象として最も興味のあるディメンション値を選択できるようにします。
-
列と行の数が多いとメモリの消費が増える。 ブラウザのパフォーマンスを考えて、列数は50以下にすることをお勧めします。やはり箇条書きの 1 つ目で説明したとおり、Look によって大量の行や列が返されるとパフォーマンスが低下する可能性があります。ダッシュボード レベルまたは Look レベルでフィルタして、要素内の結果の数を減らしてください。
-
ドリルメニューのダッシュボードという Labs 機能は、メモリ消費への影響は少ないものの、クエリ時間が長くなってダッシュボードのパフォーマンスが低下する原因となることがあります。
-
単一のクエリで共有フィルタを活用し、複数のタイルにわたって単一のクエリの結果をレンダリングします。これにより、1 回のクエリが複数のダッシュボード要素に適用されるため、ダッシュボードから実行されるクエリの総数が減少します。
-
一部のクエリのサイズが非常に大きくなり、処理する際に Looker サーバーに負荷がかかる可能性があるため、[すべての結果] オプションを使用して、慎重にクエリを配信します。
要素を追加した後に、ダッシュボードのパフォーマンスをテストしてください。構築中に、ダッシュボードに移動してページを更新し、Look を追加したときにパフォーマンスがどのように影響を受けるかを確認します。
新しい Looker ダッシュボードを作成したら、フォルダ権限を利用して、ダッシュボードが誤って変更されないようにしてください。ユーザー グループを使用して、コンテンツへのアクセスと権限を個々のユーザー単位ではなく一括で管理します。
パフォーマンスの問題がある場合は、Looker サポートに直接お問い合わせください。Google のチームがいつでも調査し、サポートします。