パフォーマンスのヒント
ここでは、InterSystems IRIS® データ・プラットフォーム Business Intelligence のパフォーマンスに関するヒントを紹介します。これは、実装プロセスの一環として確認してください。"Business Intelligence グローバルの別のデータベースへの配置" も参照してください。
パフォーマンスおよびトラブルシューティング・オプションの詳細は、InterSystems Developer CommunityOpens in a new tab を参照してください。
結果キャッシュおよびキューブの更新
(既定で) 64,000 レコードより多く使用するキューブの場合、システムは、結果キャッシュを保持して使用します。同期または再構築することでキューブを更新した場合、あるいは手動で更新した後に %SetCubeDSTime() を明示的に呼び出した場合、結果キャッシュの一部は無効と見なされ、クリアされます。詳細はキューブ定義のオプションに応じて異なります (このページで後述する "キャッシュのバケットとファクトの順序" を参照)。したがって、通常、頻繁にキューブを更新することは望ましくありません。
結果キャッシュは以下のように動作します。ユーザが (例えばアナライザを使用して) クエリを実行するたびに、システムはそのクエリの結果をキャッシュします。次回そのクエリを任意のユーザが実行すると、システムはそのキャッシュがまだ有効かどうかをチェックします。有効な場合は、キャッシュの値が使用されます。それ以外の場合、システムはクエリを再実行し、新しい値を使用して、それらをキャッシュします。その実質的な効果は、より多くのユーザがより多くのクエリを実行するほど、経時的にパフォーマンスが向上することです。
キャッシュのバケットとファクトの順序
前述のとおり、大量のデータ・セットの場合、システムは結果キャッシュを保持して使用します。この場合、ファクト・テーブルの行の順序を制御すると役立つことがあります。この順序によって、システムがキャッシュをどのように作成して使用するかが変化するからです。そのためには、キューブの [初期ビルド順序] オプションを指定します。"他のキューブ・オプション" を参照してください。
ユーザがピボット・テーブルを評価する場合、システムは可能な限り後で再使用する集約値を計算してキャッシュします。キャッシュが再使用できるかどうかを判断するために、システムは以下のロジックを使用します。
-
特定のシナリオで使用されるレコードの ID を調べます (例えば、特定のピボット・テーブルのセルについて)。
-
それらの ID が属するバケットを確認します。バケットとは、ファクト・テーブル内で連続する多数のレコードのことです (詳細は、後述します)。
-
(バケット内の少なくとも 1 つの ID に変更が加えられたために) バケットが更新されると、システムは、そのバケットに関連付けられた該当のキャッシュを破棄して、結果を再生成します。
-
バケットが更新されていない場合、システムは適切なキャッシュを再使用します (利用可能なキャッシュがある場合)。または、結果を再生成します (利用可能なキャッシュがない場合)。
-
シナリオによっては、ソース・レコードに加えた変更 (および、キューブに対するそれに対応する更新) は、最新のソース・レコードで最初に発生します。このようなシナリオでは、確実に古いレコードが最初になるように、レコードの古さ順でファクト・テーブルを構築することが有効です。この方法では、データへの変更によってより古い行のキャッシュが無効になることがなくなります (これに対して、古い行と新しい行がファクト・テーブル全体に混在していると、新しいレコードに変更が発生したときに、すべてのキャッシュが無効になる可能性があります)。
詳細は、"Analytics エンジンの仕組み" を参照してください。
非アクティブのキャッシュ・バケットの削除
キャッシュ・バケットが無効になった場合 (前のセクションを参照)、非アクティブとしてマークされますが、削除はされません。非アクティブのキャッシュ・バケットを削除するには、%DeepSee.UtilsOpens in a new tab の %PurgeObsoleteCache() メソッドを呼び出します。例 :
d ##class(%DeepSee.Utils).%PurgeObsoleteCache("patients")
キューブ・セルの事前計算
前述のように、ユーザがピボット・テーブルを評価する場合、システムは可能な限り後で再使用する集約値を計算してキャッシュします。つまり、このキャッシュ処理は、Business Intelligence で作業するユーザが増えるほどシステムの動作が速くなることを意味します (詳細は、"Analytics エンジンの仕組み" を参照してください)。
初期パフォーマンスも高速化するには、ピボット・テーブルで使用される特定の集約値を事前計算してキャッシュします。これは特に、パフォーマンスが重要となる場合に有効です。この機能は、以下のように実行されます。
-
キューブ・クラス内で、事前計算とキャッシュが必要なキューブ・セルを指定する追加の XData ブロック (CellCache) を指定します。詳細は、最初のサブセクションを参照してください。
-
それらのキューブ・セルをプログラムを使用して事前計算するには、ユーティリティ・メソッドを使用します。2 番目のサブセクションを参照してください。
これは、キューブの構築後に実行する必要があります。
より単純なオプションは、単にクエリを事前に (つまり、ユーザが作業する前に) 実行することです。
セル・キャッシュの定義
キューブ・クラスには、事前計算およびキャッシュが可能なキューブ・セルを指定する追加の XData ブロック (CellCache) を格納できます。これによって Business Intelligence の初期パフォーマンスが高速化されます。以下に例を示します。
/// This xml document defines aggregates to be precomputed.
XData CellCache [ XMLNamespace = " http://www.intersystems.com/deepsee/cellCache" ]
{
<cellCache xmlns= "http://www.intersystems.com/deepsee/cellCache" >
<group name= "BS">
<item>
<element >[Measures].[Big Sale Count]</element >
</item>
</group>
<group name= "G1">
<item>
<element >[UnitsPerTransaction].[H1].[UnitsSold]</ element>
<element >[Measures].[Amount Sold]</element >
</item>
<item>
<fact >DxUnitsSold</fact >
<element >[Measures].[Amount Sold]</element >
</item>
</group>
</cellCache >
}
<cellCache> 要素は以下のとおりです。
-
ネームスペース "http://www.intersystems.com/deepsee/cellCache" 内に存在している必要があります。
-
ゼロ個以上の <group> 要素が含まれます。
各 <group> 要素は以下のとおりです。
-
name 属性があります。この属性は、後で事前計算するセル・グループを指定するときに使用します。
-
1 つ以上の <item> 要素が含まれます。
各 <item> 要素は、キューブ・インデックスの組み合わせを表し、%SHOWPLAN によって返される情報に対応します。<item> 要素は、1 つ以上の <element> 要素で構成されます。
<element> には、以下の構造のいずれかが、任意の組み合わせで 1 つ以上含まれます。
<fact>fact_table_field_name</fact>
または、以下のようになります。
<element>mdx_member_expression</element >
以下は、この指定の説明です。
-
fact_table_field_name は、レベルまたはメジャーのファクト・テーブルのフィールド名で、そのレベルまたはメジャーの factName 属性によって指定されています。
-
mdx_member_expression は、メンバとして評価する MDX 式です。これは、レベルのメンバの場合も、メジャー名の場合もあります (各メジャーは特殊な MEASURES ディメンジョンのメンバです)。
この式は、計算メンバであってはいけません。
各グループは、一連の共通部分を定義します。グループ内の共通部分の数は、キューブ・セルを事前計算するときの処理速度に影響します。
キューブ・セルの事前計算
<group> で指定される集約値を事前計算するには、%DeepSee.UtilsOpens in a new tab の %ComputeAggregateGroup() メソッドを使用します。このメソッドは、以下のとおりです。
classmethod %ComputeAggregateGroup(pCubeName As %String,
pGroupName As %String,
pVerbose As %Boolean = 1) as %Status
pCubeName はキューブの名前、pGroupName は <group> の名前、pVerbose はメソッドの実行中に進捗情報を書き込むかどうかを指定します。pGroupName については、"*" を使用してそのキューブのすべてのグループを事前計算することもできます。
このメソッドを使用する場合、最初にキューブを構築する必要があります。
このメソッドは、各グループを処理するために、ファクト・テーブルをループし、グループ内の項目によって定義されている共通部分を計算します。処理はグループ内の共通部分の数が少ないほど速くなります。この処理はシングルスレッドです。これによりフォアグラウンドでのクエリが可能になります。
インデックス圧縮ユーティリティの使用法
キューブが同期によって頻繁に更新されると、インデックスのためのストレージ容量のニーズが大幅に増加します。インデックスのストレージ要件を最小限に抑えるために、インターシステムズは %DeepSee.Utils の一部として %CompressIndices メソッドを提供しています。このメソッドは、以下のとおりです。
classmethod %CompressIndices(pCubeName As %String,
pVerbose As %Boolean = 0) As %Status
pCubeName ではキューブ名、pVerbose ではメソッドの実行中に情報を書き込むかどうかを指定します。
バックグラウンド・タスクのワーカの割り当ての制限
ユーザは、%SetAgentCount メソッドを介して、バックグラウンド・タスクの特定のグループに割り当てられる %SYSTEM.WorkMgr エージェントの数を制限できます。このメソッドは、以下のとおりです。
classmethod %SetAgentCount(pNumAgents As %Integer = "", pType = "build", Output pStatus As %Status) As %Integer
pNumAgents は、特定のタイプのバックグラウンド・タスクに割り当てることのできるエージェントの数で、pType は制限を適用するバックグラウンド・タスクのカテゴリです。pType は、既定で build タスクに設定されていますが、runTime に設定することもできます。各タイプの制限は別個に格納され、以下のコマンドを実行することで取得できます。
write %DeepSee.Utils:%GetAgentCount(type)
type は、割り当て可能なエージェントの制限を確認するタスクのカテゴリです。