パフォーマンス改善の際に気を付けるべき点

より複雑な集計などを実現しようとして入れ子が増えすぎてしまうケース。FIXED計算や集計関数とIF文などを組み合わさっていることがよくある

クエリパイプラインを意識してなるべく全体の計算量が少なくなるように分解するとよい

🚫 悪い例：
{FIXED [Category]:SUM({FIXED [Product]: SUM([Sales])})}

✅ 改善例：
{FIXED [Category],[Product]: SUM([Sales])}

Point!

不要な文字の削除やデータの表記形式をそろえるために様々な文字列操作を実施しているパターン

そもそも文字列関数全般はパフォーマンスが悪いため、基本的にはデータソース側で対応するのがよい

🚫 悪い例：
LEFT(RIGHT(REPLACE([Full Name], " ", "|"),FIND([Full Name], " ")),LEN([Full Name]))

✅ 良い例：
REGEXP_EXTRACT([Full Name], '[^ ]+ ([^ ]+)', 1)

Point!

LOD式（Level of Detail式）は便利だが、使い方次第でパフォーマンスに大きく影響するので表計算機能とうまく使い分ける

チューニング時にはいくつかの実装方法に対してパフォーマンスモニタリングを実施したうえで、どちらの実装が速いかを検討する必要がある

使い分けのポイント：

表計算を使うべき場合：

LOD式を使うべき場合：

データソース側でのフィルタリングやクレンジングを実施することが効果的なケースも多いですが、上記のような部分についても意識してダッシュボード作成をすることでより高いパフォーマンスを発揮できるので覚えておこうと思います。