次のベストプラクティスは、ダッシュボード設計とInsightsモデル設計を強化するためのヒントを提供します。
このトピックの内容:
ダッシュボードのパフォーマンスを向上させるためのガイドラインは次のとおりです:
ダッシュボードで推奨されるウィジェット数は7〜10です。すべてのウィジェットは1つ以上の独立したクエリを生成します。
フィルターなど、ダッシュボード内の要素の数を制限します。これにより、追加のクエリが実行されます。
多数の行を持つピボットまたはテーブルウィジェットを使用して大量のデータを表示すると、ダッシュボードのロード時間が増加します。
幅が広いまたは長いピボットテーブルは避けてください。列の数を減らし、値をフィルタリングして行の数を減らします。
折れ線/列グラフでの幅が広いX軸や、「break by」句に複数の項目を持つフィールドは避けてください。
含める/除外する値やダッシュボードの日付関数が多すぎることは避けてください。代わりに、Insightsモデルでロジックを作成することをお勧めします。
レンダリングのために返されるデータの量を制限することで、ダッシュボードのパフォーマンスを向上させることができます。できるだけデータを集計します。
Insightsモデルのパフォーマンスを向上させるためのガイドラインは次のとおりです:
Insightsモデルのテーブル間のリレーションシップは、1対多または1対1として構築することをお勧めします。多対多のリレーションシップは避けてください。
- 結合キーの1つは、そのテーブルの_一意キー_である必要があります。
- **どちらの結合キーも一意でない場合、**これは多対多のリレーションシップになり、避けるべきです。
ダッシュボードを使用すると多対多のクエリが生成され、大幅なメモリスパイクが発生するため、避けるべきです。
複数の列で2つのテーブルを結合するモデルリレーションシップの作成は避けてください。
- 複数列のリレーションシップはクエリパフォーマンスに影響を与え、より多くのメモリを消費する遅いダッシュボードになります
- 複数列の一意キーを単一列の複合/代理キーに置き換えます
- 行の一意性を定義するために必要な列の一意の組み合わせごとにダミー整数キーを作成することをお勧めします。
- 一意性を定義する列が2つの短い文字列である場合:
それらを単一の文字列に連結するカスタム列を追加します
- そのカスタム列でリレーションシップを作成します