# アプリのパフォーマンスの最適化 アプリのパフォーマンスは、アプリのサイズを縮小し、データ モデルを簡略化し、set 分析を戦略的に使用することで改善できます。このセクションは、パフォーマンスに影響を与える可能性のある領域と、アプリのパフォーマンスを評価および監視する方法を指摘することにより、パフォーマンスの問題を回避するのに役立ちます。 ## アプリの複雑さ これらは、問題の診断に役立つ緩いカテゴリです。アプリが複雑になるほど、パフォーマンスは低くなります。 シンプルなアプリ: * 複雑な set 分析や If() ステートメントが含まれていない。 * 大きなテーブルが含まれていない。 * 簡単なデータ モデルで構成されている。 * 簡単な計算が含まれている。 * データ量が多い場合がある。 適度なアプリ: * 多くのテーブルを持つデータ モデルで構成されているが、ベスト プラクティスに従っている。 * set 分析といくつかの If() ステートメントを使用している。 * シートに大きいまたは広いテーブル (15列以上) を保有している。 複雑なアプリ: * 非常に複雑なデータ モデルを保有している。 * 大量のデータに接続している。 * 複雑な計算、チャート、テーブルが含まれている。 ## アプリの詳細 Qlik Sense デプロイメントのパフォーマンスに影響を与えるため、アプリのサイズに関連してハードウェア環境を考慮する必要があります。例えば、アプリを最適化しない場合、より多くのハードウェア リソースが必要になることがあります。 アプリのサイズを監視すると、次のことが可能になります。 * 現在のパフォーマンスを理解する。 * 新しいアプリの展開によるパフォーマンスへの影響を理解する。 * 既存のアプリの変更によるパフォーマンスへの影響を理解する。 * パフォーマンスの問題を解決する。 * 将来の成長に向けて計画する。 Qlik は、アプリの評価に役立つツールを提供します。詳細については、「[Qlik Sense Enterprise のパフォーマンスとスケーラビリティ](https://help.qlik.com/ja-JP/sense-admin/November2025/Subsystems/DeployAdministerQSE/Content/Sense_DeployAdminister/Common/qse-performance-stability.htm)」を参照してください。 これらは、パフォーマンスに影響を与える可能性がある基本的なアプリ要素です。 パフォーマンスに影響を与える可能性のあるアプリの詳細 | 機能 | 説明 | | --- | --- | | アプリのディスク サイズ (MB) | アプリのサイズは QMC で確認できます。[アプリ] に移動し、右側の [アクション] の横にある [列セレクター] を開きます。[ファイルサイズ (MB)] の横のラジオ ボタンをクリックします。Qlik Sense Desktop を使用している場合は、Windows Explorer でアプリのサイズを確認できます。既定のフォルダーは %USERPROFILE%\Documents\Qlik\Sense\Apps です。[アプリ] フォルダーには、すべてのアプリ名とファイル サイズがリストされます。 | | RAM 内のアプリ サイズ (GB) | アプリのベース RAM フットプリントは次の方法で決定できます。

  1. Qlik Sense サーバーを再起動する。
  2. 現在の RAM の使用状況を確認する。
  3. Qlik Sense アプリを開く。
  4. RAM の違いを記録する。


2018 年 6 月以降に Qlik Sense を使用している場合は、App Metadata Analyzer を使用してこのメトリックを見つけることができます。詳細については、「[App Metadata Analyzer](https://help.qlik.com/ja-JP/sense-admin/November2025/Subsystems/DeployAdministerQSE/Content/Sense_DeployAdminister/QSEoW/Administer_QSEoW/Monitoring_QSEoW/app-metadata-analyzer-app.htm)」を参照してください。 | | アプリの行数の合計 (M) | システム項目を使用して、行数の合計を計算できます。メジャー Sum($Rows) で KPI を作成します。詳しくは「[システム項目](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/system-fields.htm)」を参照してください。 | | アプリの項目数の合計 | システム項目を使用して、項目数の合計を計算できます。メジャー Sum($Fields) で KPI を作成します。詳しくは「[システム項目](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/system-fields.htm)」を参照してください。 | | アプリのテーブル数の合計 | システム項目を使用して、テーブル数の合計を計算できます。メジャー Count(DISTINCT $Table) で KPI を作成します。詳しくは「[システム項目](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/system-fields.htm)」を参照してください。 | ## アプリのモニター Qlik 管理コンソール (QMC) は、システムのパフォーマンスと Qlik Sense Enterprise on Windows での使用をモニターするためのアプリを提供します。 * Operations Monitor アプリでは、サーバー メモリと CPU の使用率、アクティブ ユーザー数、リロード タスク アクティビティなど、ハードウェアの使用状況に関する情報が提供されます。さらに、Qlik Sense サーバー環境でのエラー、警告、ログ アクティビティに関する要約と詳細情報も提供します。 * License Monitor アプリは、ライセンスの使用状況を追跡し、ライセンス割り当ての変更を監視するためにも活用できます。 * Log Monitor アプリは、使用可能なログ データをほぼすべて提示し、トレンド分析およびトラブルシューティングを有効にします。 * Sessions Monitor アプリは、アプリの使用方法に関するログ データを示します。 * Reloads Monitor アプリは、QMC およびハブで開いているアプリの両方から、リロードされたデータの詳細情報を提示します。 * Sense System Performance Analyzer アプリには、すべてのノードにおける Qlik Sense パフォーマンスが表示されます。 * Sense Connector Logs Analyzer アプリでは、特定の Qlik コネクターの使用状況とエラーに対する洞察を得ることができます。 * App Metadata Analyzer アプリでは、すべての Qlik Sense アプリを全体的に表示することができます (アプリのデータ モデルの詳細およびそのリソース使用率を含む)。 詳細については、「[Qlik Sense Enterprise on Windows サイトの監視](https://help.qlik.com/ja-JP/sense-admin/November2025/Subsystems/DeployAdministerQSE/Content/Sense_DeployAdminister/QSEoW/Administer_QSEoW/Monitoring_QSEoW/Monitor-Qlik-Sense-site.htm)」を参照してください。 ## 大量のデータ 大量のデータに接続する場合は、これらのアーキテクチャ戦略を採用できます。 ### セグメント化 時間枠、地域、集計レベルなどの軸で QVDs をセグメント化できます。例えば、次のようにできます。 * 最近 2 年間のデータを含む QVD。 * 2 年以上前の履歴データを含む QVD。 * より高いレベルで集約されたすべてのデータを含む QVD。例えば、日付ではなく月ごと、または個々の顧客ではなく国ごとです。 * すべてのデータを含む 1 つの大きな QVD。これは、ユーザーの小さなサブセットのみが使用します。 アプリは類似の方法でセグメント化することができます。小さなアプリは、ほとんどのユーザーの分析ニーズに対応します。これはメモリを節約します。 さまざまな地域に焦点を当てた複数のアプリを保有することもできます。こうすることで、ユーザーは、興味のないデータやアクセス権のないデータのアプリを開くことがなくなります。セクション アクセスでアクセスできないデータは、メモリに影響を与えます。 ### オンデマンド アプリの生成 (ODAG) Qlik Sense のオンデマンド アプリは、ビッグ データ ストアの集計ビューをユーザーに提供します。詳細な分析のために、データの関連サブセットを識別してロードできます。 ユーザーの観点からは、2 つのアプリがあります: 1. 集約されたデータを含むショッピング カート。 2. 詳細を表示するために使用される空のテンプレート アプリ。 ユーザーがショッピング カート アプリで選択を行います。 しきい値に達すると、カスタム LOAD スクリプトが作成され、テンプレート アプリに要求された詳細が入力されます。詳しくは「[On-demand アプリによるビッグ データの管理](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/DataSource/Manage-big-data.htm)」を参照してください。 ### アプリケーションのチェーン アプリケーション チェーン (QlikView ではドキュメント チェーンと呼ばれる) は、ユーザーが定期的に使用する集計アプリがあることを意味します。ユーザーがより詳細な情報を必要とする場合は、集約されたアプリから詳細アプリに選択を渡すことができるため、より詳細なレベルで表示できます。ユーザーが不要な詳細をロードしないため、メモリを節約できます。アプリケーション チェーンは、シートにボタン オブジェクトを追加することで実行できます。詳細については、「[ボタン](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Visualizations/Button/button.htm#Applicat)」を参照してください。 アプリケーション チェーンは、APIs でもサポートされています。たとえば、 App Integration API を使用してカスタム アプリケーション チェーンを作成できます。詳細については、「[App Integration API](https://help.qlik.com/en-US/sense-developer/November2025/Subsystems/APIs/Content/Sense_ClientAPIs/app-integration-api.htm) (英語のみ)」を参照してください。 ## データ モデルのパフォーマンス これらは、データ モデルのパフォーマンスに影響を与える可能性のあるインジケーターです。それぞれがアプリの使いやすさを向上させるベスト プラクティスです。 データ モデル パフォーマンスのベスト プラクティス | アクション | 説明 | | --- | --- | | 合成キーを削除する | Qlik Sense は、2 つ以上のデータ テーブルに 2 つ以上の共通の項目がある場合に合成キーを作成します。これは、スクリプトまたはデータ モデル にエラーがあることを意味する場合があります。合成キーを診断するには、「[合成キー](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/synthetic-keys.htm)」を参照してください。 | | データ モデルから循環参照を削除する | 2 つの項目に複数の関連付けがある場合、循環参照が発生します。Qlik Sense は、いずれかのテーブルへの接続を変更することにより、これらを解決しようとします。ただし、循環参照の警告はすべて解決する必要があります。「[循環参照を理解し解決](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/LoadData/understand-circular-references.htm)」を参照してください。 | | データの粒度を適切にする | 必要なデータのみをロードする必要があります。例えば、ユーザーのグループに必要なのは、週、月、年で分割されたデータだけです。集約データをロードするか、ロード スクリプト内でデータを集約してメモリを節約できます。ユーザーがより細かいレベルでデータを視覚化する必要がある場合は、ODAG またはドキュメント チェーンを使用できます。 | | 可能な場合は QVDs を使用する | QVD は、Qlik Sense からエクスポートされたデータのテーブルを含むファイルです。このファイル形式は、スクリプトからデータを読み取る際の速度について最適化されていますが、それでも非常にコンパクトです。QVD ファイルからのデータの読み取りは、他のデータ ソースから読み取る場合よりも、一般に 10～100 倍速くなっています。詳しくは「[QVD ファイルでの作業](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/work-with-QVD-files.htm)」を参照してください。 | | QVD ファイルをロード時に最適化する | QVD ファイルは、標準 (高速) と最適化 (超高速) の 2 つのモードで読み取ることができます。使用されるモードは、スクリプト エンジンによって自動的に決定されます。

最適化されたロードに関して、いくつかの制限があります。項目の名前は変更できますが、これらの操作はいずれも標準のロードとなります。

| | 増分ロードを活用する | 継続的に更新される、データベースからの大量のデータにアプリが接続する場合、データ セット全体をリロードするには時間がかかります。代わりに、増分ロードを使用して、データベースから新しいレコードまたは変更されたレコードを取得する必要があります。詳しくは「[増分ロードにより新規および更新された記録をロード](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/LoadData/use-QVD-files-incremental-load.htm)」を参照してください。 | | Snowflake モデルを統合する | スノーフレーク データ モデルを使用している場合は、Join プレフィックスまたは他のマッピングを使用してそれらの一部を結合することにより、データ テーブルの数を減らすことができる場合があります。これは、大きなファクト テーブルにとって特に重要です。経験則として、大きなテーブルは 1 つだけにすることです。詳細については、[[参加するまたは参加しない](https://community.qlik.com/t5/Qlik-Design-Blog/To-Join-or-not-to-Join/ba-p/1463102)] を参照してください。 | | 項目の数が少ないテーブルを非正規化する | 項目が少ない 2 つのテーブルがある場合、それらを結合するとパフォーマンスが向上する可能性があります。 詳細については、「[スクリプト作成の次のステップ](https://help.qlik.com/ja-JP/sense/November2025/Content/Sense_Helpsites/Tutorials/Tutorials-scripting-next-steps.htm)」を参照してください。 | | マッピング ロードがあるルックアップ (リーフ) テーブルを非正規化する | 1 つの項目をテーブルから別の項目に追加するだけでよい場合は、Join プレフィックスを使用しないでください。ApplyMap ルックアップ関数を使用する必要があります。[[参加しない - ApplyMap を使用する](https://community.qlik.com/t5/Qlik-Design-Blog/Don-t-join-use-Applymap-instead/ba-p/1467592)] を参照してください。 | | 日付項目からタイム スタンプを削除または分離する | 文字列表現が大きく、個別の値の数が多いため、タイムスタンプが存在する場合、日付項目がスペースを埋めることがあります。分析に精度が必要ない場合は、例えば Timestamp(Floor(YourTimestamp,1/24)) を使用してタイムスタンプを最も近い時間に丸めるか、Date(Floor(YourTimestamp)) を使用して時間コンポーネントを完全に削除できます。

タイムスタンプが必要な場合は、日付自体から切り離すことができます。同じ Floor() 関数を使用し、Time(Frac(YourTimestamp)) などを使用して、抽出された時間で新しい項目を作成できます。 | | データ モデルから不要な項目を削除する | データ モデルに必要な項目のみをロードする必要があります。Load \* と SELECT の使用は避けてください。以下を保持してください。

| | 大量のデータを処理するときにリンク テーブルを回避する | 可能な場合はリンク テーブルを使用してください。ただし、大量のデータを処理している場合、連結されたテーブルはリンク テーブルよりもパフォーマンスが高くなる可能性があります。 | | 連結された軸を新しい項目に分割する | 連結された軸を別々の項目に分割する必要があります。これにより、項目内の値の一意の出現回数が減少します。これは、タイムスタンプを最適化する方法に似ています。 | | 可能な場合は AutoNumber を使用する | 最適化されたロードを作成するには、QVD ファイルのデータをロードしてから、AutoNumber ステートメントを使用して値をシンボル キーに変換します。詳細については、「[AutoNumber](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/ScriptRegularStatements/Autonumber.htm)」を参照してください。 | | データ アイランドを回避する | データ アイランドは便利ですが、通常はパフォーマンスに影響します。選択値のアイランドを作成する場合は、変数を使用します。 | | QVD は増分時間枠に基づいて保存する | QVD は毎月などのセグメントに格納する必要があります。これらの小さな月次 QVD は、すべてのデータを必要としない可能性がある多くの異なるアプリをサポートできます。 | ## シート パフォーマンス シートとビジュアライゼーションのパフォーマンスを向上させるためのベスト プラクティスを以下に示します。 シート パフォーマンス ベスト プラクティス | アクション | 説明 | | --- | --- | | 可能な場合は If() 関数の使用を回避する | If() 関数を集計関数内で使用すると、レコード レベルで動作し、何度も評価されます。

例えば、集約に 1000 レコードがある場合、If() 条件は 1000 回評価されます。ステートメントをネストすると、これは急速にカスケードする可能性があります。代わりに set 分析を使用することを推奨します。集合の前に set 分析フィルターが適用されるため、応答が速くなります。これらの応答は、set 分析を介してキャッシュすることもできますが、If() はキャッシュできません。また、他の関数やデータ モデルへの変更を検討することもできます。 | | [](https://help.qlik.com/en-US/sense/Subsystems/Hub/Content/Sense_Hub/Apps/app-performance.htm)集計テーブル内の異なるテーブルの項目は、可能な限り回避されます。 | 集計が評価されると、計算は 2 つのステップで実行されます。

  1. 最初のステップは、計算を行うための関連する組み合わせを見つけることです。このステップはシングルスレッドです。

  2. 2 番目のステップは計算を実行することです。このステップはマルチスレッドです。



シングルスレッド部分は、パフォーマンスに大きな影響を与える可能性があります。1 つの例は、集約内に複数の項目がある場合です (例: Sum(Quantity\*ListPrice))。Quantity がファクト テーブルにあり、ListPrice がマスター製品テーブルにある場合、エンジンは製品の合計を開始する前に、まず 2 つのテーブルを結合して組み合わせを見つける必要があります。結合はシングルスレッド部分であり、合計はマルチスレッドです。両方の項目が同じテーブルで見つかった場合、結合は不要であり、集計はかなり高速に評価されます。 | | Aggr() およびネストされた Aggr() 関数の使用を最小限にする | Aggr() 関数はパフォーマンスに大きく影響します。誤って使用すると、不正確な結果が生じる可能性があります。例えば、Aggr() 関数内の軸とは異なる軸を持つテーブルで生じる可能性があります。詳細については、[[AGGR を使用すべきでない場合](https://community.qlik.com/t5/Qlik-Design-Blog/When-should-the-Aggr-function-NOT-be-used/ba-p/1467855)] を参照してください。 | | 可能な場合は set 分析を使用する | set 分析を使用して、現在の選択で定義された通常のセットとは異なるデータ値のセットを定義できます。詳しくは「[set 分析](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/ChartFunctions/SetAnalysis/set-analysis-expressions.htm)」を参照してください。 | | 可能な場合は文字列比較の使用を避ける | 文字列比較は、set 分析ほど効率的ではありません。例えば、Match()、MixMatch()、WildMatch()、Pick() は避けてください。スクリプトでフラグを作成するか、代わりに set 分析を使用してください。詳細については、[[条件分岐関数](https://help.qlik.com/ja-JP/sense/November2025/Subsystems/Hub/Content/Sense_Hub/Scripting/ConditionalFunctions/conditional-functions.htm)] と [[条件付き集計のパフォーマンス](https://community.qlik.com/t5/Qlik-Design-Blog/Performance-of-Conditional-Aggregations/ba-p/1463021)] を参照してください。 | | 演算実行条件は、集中的な計算を含むオブジェクトで使用する | 何も選択されていない場合、多くのレコードを含む視覚化がある場合があります。ベスト プラクティスとして、特定の選択が行われた後にのみレンダリングされるように、演算実行条件をオブジェクトに追加します。これにより、非常に大きなハイパーキューブの作成が停止します。例: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1。このシナリオでは、ユーザーが単一の国を選択するか、単一の国のみが可能な他の選択を行わない限り、ビジュアライゼーションはレンダリングされません。 | | 可能な場合、メジャーは事前にスクリプトで計算する | データ モデルの最小レベルの粒度であるメジャーは、スクリプトで計算する必要があります。例えば、テーブルの同じレコードに Sales と Cost がある場合、Sales - Cost AS Margin を計算してマージンを導き出すことができます。選択に基づいて変化しないか、または異なるレベルの粒度にバインドされていることがわかっている場合は、事前に他の値を集計することもできます。 | | テーブルは 15 列未満とし、演算実行条件を付ける | 15 列のテーブルは幅が広いと見なすことができます。テーブルが多くのレコードで構成されている場合は、テーブル オブジェクトに対して計算された条件を使用して、特定の選択または基準が満たされた後にのみレンダリングされるようにする必要があります。テーブルが非常に広い場合は、次の点を考慮してください。

| | シートに過剰な数のオブジェクトを追加しない | オブジェクトは、ユーザーがシートに移動したときに計算されます。ユーザーがそのシートで選択を行うたびに、現在の状態がキャッシュに存在しない場合、各オブジェクトが再計算されます。多くのチャートを含むシートがある場合、ユーザーは、ほぼすべての選択ですべてのオブジェクトが計算されるのを待つ必要があります。これにより、エンジンに大きな負荷がかかります。ベスト プラクティスとして、Dashboard/Analysis/Reporting (DAR) の概念に従って、クリーンで最小限のアプリを開発します。詳細については、[DAR 手法](https://community.qlik.com/t5/Qlik-Design-Blog/DAR-methodology/ba-p/1466733)を参照してください。 | | set 分析で使用するためにスクリプトで数値フラグを利用する | フラグを使用した set 分析は、文字列比較や乗算を使用するよりも効率的です。 | | [](https://help.qlik.com/en-US/sense/Subsystems/Hub/Content/Sense_Hub/Apps/app-performance.htm)数式でマスター アイテムまたは変数を使用する | マスター アイテムにより、管理されたメトリックのドラッグ アンド ドロップが可能になり、数式がキャッシュされることが保証されます。例えば、Sum(Sales) は SUM(Sales) とは異なります。数式はスペルと大文字小文字がキャッシュされ、再利用するには逐語的に一致する必要があります。 |