アプリのパフォーマンスの最適化
アプリのパフォーマンスは、アプリのサイズを縮小し、データ モデルを簡略化し、set 分析を戦略的に使用することで改善できます。このセクションは、パフォーマンスに影響を与える可能性のある領域と、アプリのパフォーマンスを評価および監視する方法を指摘することにより、パフォーマンスの問題を回避するのに役立ちます。
パフォーマンス評価ツールを使用して、アプリのパフォーマンスを確認できます。詳細については、「アプリ パフォーマンス評価」を参照してください。
アプリの複雑さ
これらは、問題の診断に役立つ緩いカテゴリです。アプリが複雑になるほど、パフォーマンスは低くなります。
シンプルなアプリ:
- 複雑な set 分析や If() ステートメントが含まれていない。
- 大きなテーブルが含まれていない。
- 簡単なデータ モデルで構成されている。
- 簡単な計算が含まれている。
- データ量が多い場合がある。
適度なアプリ:
- 多くのテーブルを持つデータ モデルで構成されているが、ベスト プラクティスに従っている。
- set 分析といくつかの If() ステートメントを使用している。
- シートに大きいまたは広いテーブル (15列以上) を保有している。
複雑なアプリ:
-
非常に複雑なデータ モデルを保有している。
- 大量のデータに接続している。
- 複雑な計算、チャート、テーブルが含まれている。
大量のデータ
大量のデータに接続する場合は、これらのアーキテクチャ戦略を採用できます。
セグメント化
時間枠、地域、集計レベルなどの軸で QVDs をセグメント化できます。例えば、次のようにできます。
- 最近 2 年間のデータを含む QVD。
- 2 年以上前の履歴データを含む QVD。
より高いレベルで集約されたすべてのデータを含む QVD。例えば、日付ではなく月ごと、または個々の顧客ではなく国ごとです。
- すべてのデータを含む 1 つの大きな QVD。これは、ユーザーの小さなサブセットのみが使用します。
アプリは類似の方法でセグメント化することができます。小さなアプリは、ほとんどのユーザーの分析ニーズに対応します。これはメモリを節約します。
さまざまな地域に焦点を当てた複数のアプリを保有することもできます。こうすることで、ユーザーは、興味のないデータやアクセス権のないデータのアプリを開くことがなくなります。セクション アクセスでアクセスできないデータは、メモリに影響を与えます。
オンデマンド アプリの生成 (ODAG)
Qlik Sense のオンデマンド アプリは、ビッグ データ ストアの集計ビューをユーザーに提供します。詳細な分析のために、データの関連サブセットを識別してロードできます。
ユーザーの観点からは、2 つのアプリがあります:
- 集約されたデータを含むショッピング カート。
- 詳細を表示するために使用される空のテンプレート アプリ。
ユーザーがショッピング カート アプリで選択を行います。 しきい値に達すると、カスタム LOAD スクリプトが作成され、テンプレート アプリに要求された詳細が入力されます。詳しくは「On-demand アプリによるビッグ データの管理」を参照してください。
アプリケーションのチェーン
アプリケーション チェーン (QlikView ではドキュメント チェーンと呼ばれる) は、ユーザーが定期的に使用する集計アプリがあることを意味します。ユーザーがより詳細な情報を必要とする場合は、集約されたアプリから詳細アプリに選択を渡すことができるため、より詳細なレベルで表示できます。ユーザーが不要な詳細をロードしないため、メモリを節約できます。アプリケーション チェーンは、シートにボタン オブジェクトを追加することで実行できます。詳細については、「アプリケーションのチェーン」を参照してください。
アプリケーション チェーンは、APIs でもサポートされています。たとえば、 App Integration API を使用してカスタム アプリケーション チェーンを作成できます。詳細については、「App Integration API (英語のみ)」を参照してください。
ダイナミック ビュー
ダイナミック ビューにより、大量のデータまたはデータが急速に変化するシナリオにおける最新のビジュアライゼーションが可能になります。ダイナミック ビューを使用する際には、以下を考慮してください。
ダイナミック ビューを更新すると、データ ソースが直接読み込まれます。更新のパフォーマンスは、基になるデータ ソースのパフォーマンスに影響されます。
ダイナミック ビューのテンプレート app は、ダイナミック チャートの作成を支援します。
ダイナミック ビューの使用については、「ダイナミック ビューによるデータの管理」を参照してください。
Direct Query
インメモリ app が推奨ですが、Direct Query はデータを元のソースに保持することができるようにします。Direct Query の使用を最適化するために以下を考慮してください。
Direct Query のパフォーマンスは、基になるデータ ソースのパフォーマンスに大きく影響されます。
Direct Query のデータ モデルはできるだけシンプルにします。複雑なクエリはパフォーマンスに悪影響を及ぼす可能性があります。
Direct Query の詳細については、「Direct Query を使用してクラウド データベースに直接アクセス」を参照してください。
データ モデルのパフォーマンス
これらは、データ モデルのパフォーマンスに影響を与える可能性のあるインジケーターです。それぞれがアプリの使いやすさを向上させるベスト プラクティスです。
| アクション | 説明 |
|---|---|
合成キーを削除する | Qlik Sense は、2 つ以上のデータ テーブルに 2 つ以上の共通の項目がある場合に合成キーを作成します。これは、スクリプトまたはデータ モデル にエラーがあることを意味する場合があります。合成キーを診断するには、「合成キー」を参照してください。 |
データ モデルから循環参照を削除する | 2 つの項目に複数の関連付けがある場合、循環参照が発生します。Qlik Sense は、いずれかのテーブルへの接続を変更することにより、これらを解決しようとします。ただし、循環参照の警告はすべて解決する必要があります。「循環参照を理解し解決」を参照してください。 |
データの粒度を適切にする | 必要なデータのみをロードする必要があります。例えば、ユーザーのグループに必要なのは、週、月、年で分割されたデータだけです。集約データをロードするか、ロード スクリプト内でデータを集約してメモリを節約できます。ユーザーがより細かいレベルでデータを視覚化する必要がある場合は、ODAG またはドキュメント チェーンを使用できます。 |
可能な場合は QVDs を使用する | QVD は、Qlik Sense からエクスポートされたデータのテーブルを含むファイルです。このファイル形式は、スクリプトからデータを読み取る際の速度について最適化されていますが、それでも非常にコンパクトです。QVD ファイルからのデータの読み取りは、他のデータ ソースから読み取る場合よりも、一般に 10～100 倍速くなっています。詳しくは「QVD ファイルでの作業」を参照してください。 |
QVD ファイルをロード時に最適化する | QVD ファイルは、標準 (高速) と最適化 (超高速) の 2 つのモードで読み取ることができます。使用されるモードは、スクリプト エンジンによって自動的に決定されます。 最適化されたロードに関して、いくつかの制限があります。項目の名前は変更できますが、これらの操作はいずれも標準のロードとなります。
|
増分ロードを活用する | 継続的に更新される、データベースからの大量のデータにアプリが接続する場合、データ セット全体をリロードするには時間がかかります。代わりに、増分ロードを使用して、データベースから新しいレコードまたは変更されたレコードを取得する必要があります。詳しくは「増分ロードにより新規および更新された記録をロード」を参照してください。 |
Snowflake モデルを統合する | スノーフレーク データ モデルを使用している場合は、Join プレフィックスまたは他のマッピングを使用してそれらの一部を結合することにより、データ テーブルの数を減らすことができる場合があります。これは、大きなファクト テーブルにとって特に重要です。経験則として、大きなテーブルは 1 つだけにすることです。詳細については、[参加するまたは参加しない] を参照してください。 |
項目の数が少ないテーブルを非正規化する | 項目が少ない 2 つのテーブルがある場合、それらを結合するとパフォーマンスが向上する可能性があります。詳しくは「Join と Keep を使用したテーブルの結合」を参照してください。 |
マッピング ロードがあるルックアップ (リーフ) テーブルを非正規化する | 1 つの項目をテーブルから別の項目に追加するだけでよい場合は、Join プレフィックスを使用しないでください。ApplyMap ルックアップ関数を使用する必要があります。[参加しない - ApplyMap を使用する] を参照してください。 |
日付項目からタイム スタンプを削除または分離する | 文字列表現が大きく、個別の値の数が多いため、タイムスタンプが存在する場合、日付項目がスペースを埋めることがあります。分析に精度が必要ない場合は、例えば Timestamp(Floor(YourTimestamp,1/24)) を使用してタイムスタンプを最も近い時間に丸めるか、Date(Floor(YourTimestamp)) を使用して時間コンポーネントを完全に削除できます。 タイムスタンプが必要な場合は、日付自体から切り離すことができます。同じ Floor() 関数を使用し、Time(Frac(YourTimestamp)) などを使用して、抽出された時間で新しい項目を作成できます。 |
データ モデルから不要な項目を削除する | データ モデルに必要な項目のみをロードする必要があります。Load * と SELECT の使用は避けてください。以下を保持してください。
|
大量のデータを処理するときにリンク テーブルを回避する | 可能な場合はリンク テーブルを使用してください。ただし、大量のデータを処理している場合、連結されたテーブルはリンク テーブルよりもパフォーマンスが高くなる可能性があります。 |
連結された軸を新しい項目に分割する | 連結された軸を別々の項目に分割する必要があります。これにより、項目内の値の一意の出現回数が減少します。これは、タイムスタンプを最適化する方法に似ています。 |
可能な場合は AutoNumber を使用する | 最適化されたロードを作成するには、QVD ファイルのデータをロードしてから、AutoNumber ステートメントを使用して値をシンボル キーに変換します。詳細については、「AutoNumber」を参照してください。 |
データ アイランドを回避する | データ アイランドは便利ですが、通常はパフォーマンスに影響します。選択値のアイランドを作成する場合は、変数を使用します。 |
QVD は増分時間枠に基づいて保存する | QVD は毎月などのセグメントに格納する必要があります。これらの小さな月次 QVD は、すべてのデータを必要としない可能性がある多くの異なるアプリをサポートできます。 |
シート パフォーマンス
シートとビジュアライゼーションのパフォーマンスを向上させるためのベスト プラクティスを以下に示します。
| アクション | 説明 |
|---|---|
可能な場合は If() 関数の使用を回避する | If() 関数を集計関数内で使用すると、レコード レベルで動作し、何度も評価されます。 例えば、集約に 1000 レコードがある場合、If() 条件は 1000 回評価されます。ステートメントをネストすると、これは急速にカスケードする可能性があります。代わりに set 分析を使用することを推奨します。集合の前に set 分析フィルターが適用されるため、応答が速くなります。これらの応答は、set 分析を介してキャッシュすることもできますが、If() はキャッシュできません。また、他の関数やデータ モデルへの変更を検討することもできます。 |
| 集計テーブル内の異なるテーブルの項目は、可能な限り回避されます。 | 集計が評価されると、計算は 2 つのステップで実行されます。
シングルスレッド部分は、パフォーマンスに大きな影響を与える可能性があります。1 つの例は、集約内に複数の項目がある場合です (例: Sum(Quantity*ListPrice))。Quantity がファクト テーブルにあり、ListPrice がマスター製品テーブルにある場合、エンジンは製品の合計を開始する前に、まず 2 つのテーブルを結合して組み合わせを見つける必要があります。結合はシングルスレッド部分であり、合計はマルチスレッドです。両方の項目が同じテーブルで見つかった場合、結合は不要であり、集計はかなり高速に評価されます。 |
Aggr() およびネストされた Aggr() 関数の使用を最小限にする | Aggr() 関数はパフォーマンスに大きく影響します。誤って使用すると、不正確な結果が生じる可能性があります。例えば、Aggr() 関数内の軸とは異なる軸を持つテーブルで生じる可能性があります。詳細については、[AGGR を使用すべきでない場合] を参照してください。 |
可能な場合は set 分析を使用する | set 分析を使用して、現在の選択で定義された通常のセットとは異なるデータ値のセットを定義できます。詳しくは「set 分析」を参照してください。 |
可能な場合は文字列比較の使用を避ける | 文字列比較は、set 分析ほど効率的ではありません。例えば、Match()、MixMatch()、WildMatch()、Pick() は避けてください。スクリプトでフラグを作成するか、代わりに set 分析を使用してください。詳細については、[条件分岐関数] と [条件付き集計のパフォーマンス] を参照してください。 |
演算実行条件は、集中的な計算を含むオブジェクトで使用する | 何も選択されていない場合、多くのレコードを含む視覚化がある場合があります。ベスト プラクティスとして、特定の選択が行われた後にのみレンダリングされるように、演算実行条件をオブジェクトに追加します。これにより、非常に大きなハイパーキューブの作成が停止します。例: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1。このシナリオでは、ユーザーが単一の国を選択するか、単一の国のみが可能な他の選択を行わない限り、ビジュアライゼーションはレンダリングされません。 |
可能な場合、メジャーは事前にスクリプトで計算する | データ モデルの最小レベルの粒度であるメジャーは、スクリプトで計算する必要があります。例えば、テーブルの同じレコードに Sales と Cost がある場合、Sales - Cost AS Margin を計算してマージンを導き出すことができます。選択に基づいて変化しないか、または異なるレベルの粒度にバインドされていることがわかっている場合は、事前に他の値を集計することもできます。 |
テーブルは 15 列未満とし、演算実行条件を付ける | 15 列のテーブルは幅が広いと見なすことができます。テーブルが多くのレコードで構成されている場合は、テーブル オブジェクトに対して計算された条件を使用して、特定の選択または基準が満たされた後にのみレンダリングされるようにする必要があります。テーブルが非常に広い場合は、次の点を考慮してください。
|
シートに過剰な数のオブジェクトを追加しない | オブジェクトは、ユーザーがシートに移動したときに計算されます。ユーザーがそのシートで選択を行うたびに、現在の状態がキャッシュに存在しない場合、各オブジェクトが再計算されます。多くのチャートを含むシートがある場合、ユーザーは、ほぼすべての選択ですべてのオブジェクトが計算されるのを待つ必要があります。これにより、エンジンに大きな負荷がかかります。ベスト プラクティスとして、Dashboard/Analysis/Reporting (DAR) の概念に従って、クリーンで最小限のアプリを開発します。詳細については、DAR 手法を参照してください。 |
set 分析で使用するためにスクリプトで数値フラグを利用する | フラグを使用した set 分析は、文字列比較や乗算を使用するよりも効率的です。 |
| マスター アイテムにより、管理されたメトリックのドラッグ アンド ドロップが可能になり、数式がキャッシュされることが保証されます。例えば、Sum(Sales) は SUM(Sales) とは異なります。数式はスペルと大文字小文字がキャッシュされ、再利用するには逐語的に一致する必要があります。 |
データの読み込みパフォーマンス
Qlik Cloud で app を使用する際は、データの読み込みを最適化することが、シームレスで応答性が高いエクスペリエンスを得るために重要です。このセクションでは、パフォーマンスに影響を与える要素に焦点を当て、パフォーマンスへの悪影響を回避する方法についてのガイドを提供します。
Qlik Data Gateway - 直接アクセス
App にデータをリロードするために Qlik Data Gateway - 直接アクセス を使用する場合は、次の要素がパフォーマンスに影響を及ぼします。
データ ゲートウェイとデータベースをホストしているマシン間の接続速度と待機時間。
データ ゲートウェイと Qlik Cloud テナントをホストしているマシン間の接続速度と待機時間。理想的には、データ ゲートウェイと Qlik Cloud テナントを同一リージョンにホストするとパフォーマンスが改善されます。
データベースのストレージ
ストレージの接続速度が遅いと、リロード時間が増加します。オンプレミスまたはクラウドでホストされるデータベースについては、以下を考慮してください。
オンプレミス: データベースがオンプレミスにあり、サーバーを他のアプリケーションと共有している場合は、こうしたアプリケーションのアクティビティがパフォーマンスに影響を及ぼす可能性があります。
クラウド: 適切なサイズの場合、クラウド データベースは通常、オンプレミス データベースよりも優れたパフォーマンスを提供します。最適な結果を得るには、Qlik Cloud テナントに近いリージョンをクラウド ストレージのリージョンに選択します。