- リリース ノート
- はじめる前に
- 基本情報
- Integrations
- プロセス アプリを使用する
- アプリを作成する
- データを読み込む
- プロセス アプリをカスタマイズする
- アプリ テンプレート
- その他のリソース
- すぐに使えるタグと期限日
- ローカル環境でデータ変換を編集する
- ローカルのテスト環境を設定する
- イベント ログをデザインする
- SAP Ariba の抽出ツールを拡張する
- パフォーマンス特性
- 基本的なトラブルシューティング ガイド
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
パフォーマンス特性
Process Mining アプリの応答時間は、さまざまな要因によって決まりますが、一般的には次の原則が成り立ちます。
-
データが少ないほど実行速度が速い
Process Mining には、異なるパフォーマンス特性を持つ 2 つの領域があります。データを読み込むためのデータ実行と、データを表示するためのダッシュボードです。
Process Mining では、各プロセス アプリに開発ステージとパブリッシュ済みステージがあります。 目的のアプリで大きなデータセットが必要な場合は、データ変換とダッシュボードの開発に、より小さなデータセット (<10M レコード) を使用することをお勧めします。
開発データセットは、データ変換のテストに使用されます。パブリッシュ済みのプロセス アプリのダッシュボードに表示されるデータには影響しません。 ビジネス ユーザーがアプリを使用する準備が整ったら、アプリをパブリッシュして、パブリッシュ済みのプロセス アプリで使用する新しいデータを取り込むことができます。
一般的なシナリオは、開発に短い時間枠のデータセットを使用することです (たとえば、2 週間の時間枠で 100,000 個のイベントのみ)。 パブリッシュ時には、より大きなデータセット (12 か月など) を使用できます。
Process Mining のデータ実行は、以下のユース ケースでトリガーされます。
-
アプリの作成
-
データをアップロードする
-
データ変換エディターで [ダッシュボードに適用]、[すべてのテストを実行]、または [ファイルを実行] をトリガーする
-
データ変換に変更があるアプリをパブリッシュする
データ実行は通常、以下の手順から成り、各手順にはそれぞれ異なるパフォーマンス特性があります。
データをアップロードする場合、ディスクにアップロードされたデータの全体的なサイズが速度にとって最も重要な要因です。詳しくは、「データを読み込む」をご覧ください。パフォーマンスに影響する要因は次のとおりです。
-
テーブルの数
-
テーブル内のレコードの数
-
テーブル内の列数
-
テーブル内のデータ。たとえば、複数行の説明が格納されている列は、単純な Boolean 列よりも低速です。
データ変換により、入力データを、ダッシュボードに必要なデータ モデルに変更します。詳しくは、「データ変換」をご覧ください。
.sql
ファイルは、追加の SQL クエリを実行します。データ変換の速度に影響する要因は次のとおりです。
-
.sql
ファイルの数 -
各テーブルのレコードの数
-
各テーブルの列数
-
SQL クエリの複雑さ: 結合条件、共通テーブル式 (Common Table Expressions、CTE) の数、SQL クエリの式
データ モデルによって、ダッシュボードに公開されるテーブルのセットが決まります。データ実行中にテストが実行され、データ モデル内のこれらのテーブルの構造が検証されます。ただし、最も時間のかかる部分は、後でダッシュボードの表示を高速化するために行われる事前計算です。
この手順の全体的な速度は、次の要素によって決まります。
-
データ モデル内のテーブルの数
-
出力テーブル間の関係
-
出力テーブルの列数
-
出力テーブルのレコード数
データの量を減らす
データのアップロード速度を向上させるには、データのサイズを必要最小限に抑えます。このアドバイスは、データのすべてのステージに適用されます。
-
必要な入力データのみを抽出する
-
必要なデータのみを変換する
-
データ モデルにテーブルを追加するのは、データ分析に必要な場合だけにする
このための最も簡単な方法は、通常、データ抽出に使用する期間を短くすることです。これにより、入力から変換、出力までの過程で、ほとんどのデータ テーブルのレコード数が減ります。
早い段階でデータのサイズを縮小できるほど、効率が向上します。
-
sql
ファイルをフィルター処理する。データ変換のできるだけ早い段階か、可能であればデータ抽出時に行います。 -
開発には通常、よりサイズの小さいデータセットを使用する。クエリのテストを高速化するには、「開発データと運用データ」をご覧ください。
データ テーブルと列の数を減らす
さらに、実際に使用する列のみを読み込むように注意します。プロセスの早い段階で列を除外するほど、効率が向上します。
-
抽出する一連のデータ列を減らし、必要なものだけにする
-
出力データ モデルに必要のない
.sql
ファイルを削除する -
クエリ内の不要なデータ列を削除する
-
一連のイベントから不要なアクティビティを削除する
複雑さを軽減する
データ変換の計算とデータ モデルが複雑になるほど、データ実行は遅くなります。複雑さを軽減することは困難な場合がありますが、データ実行の時間に大きな影響を及ぼすことができます。
-
可能であれば SQL ステートメントの複雑さを軽減する。「SQL を記述するためのヒント」を参照してください。
-
データ モデル内のデータを減らし、データ分析に必要なデータだけにする。データ分析に必要のないテーブルや列はすべて削除することをお勧めします。
-
[BPMN モデルをインポート] を使用してプロセスを表示する場合は、アクティビティとエッジの数を少なくする。これにより、パフォーマンスが向上します。
一般に、ダッシュボードの読み込み時間は、グラフで使用されるデータの量と、計算されるメトリックの影響を受けます。
ダッシュボードが Process Mining に読み込まれるたびに、各グラフが並列に計算されます。グラフの読み込み速度に影響する要因は次のとおりです。
-
グラフに表示するメトリックの数。
-
各メトリックでは、メトリックを計算するために必要な結合サイズが重要です。結合サイズを判断するには、グラフをグループ化するために使用するテーブルに、メトリックのテーブルを組み合わせます。
-
2 つのテーブル間のリレーションの複雑さ
-
データ モデル内での 2 つのテーブル間の距離
-
-
使用するフィールドのデータ型。数値フィールドはテキスト フィールドよりも高速です。
-
メトリック自体の複雑さ。メトリックが複数のフィールドに基づいている可能性があります。