アクティビティ データのストレージ

  • [アーティクル]

このトピックでは、アクティビティ データのストレージ、および時間の経過と共に拡張されたアクティビティ テーブルが原因で発生するパフォーマンス関連の問題について説明します。また、実行中のアクティビティと完了したアクティビティ用のテーブルを分離することで、これらのパフォーマンスに関する問題を BAM で解決する方法についても説明します。 さらに、データのクエリ用のオンライン時間帯と、BAM のパーティション分割を使用してパフォーマンスを向上する方法についても説明します。

アクティビティ データのストレージでは、原則的には、アクティビティの種類ごとに異なるテーブルを保持します。これらのテーブルでは、各レコードがそれぞれ異なるアクティビティ インスタンス (実行中または完了済みなど) を表します。

次の例は、アクティビティが注文書の場合のテーブルを示しています。

発注番号 受け取り時間 City Quantity 出荷時間 納品時間
123 午前 8:00 Seattle 150 午前 8:24 12:45pm
124 午前 8:30 Seattle 234 午前 8:45 午後 1 時 20 分
125 午前 8:35 レドモンド 87 午前 9:05 午後 2:30
126 午前 8:45 Seattle 450 午前 9:20 午後 3:10
127 午前 8:55 レドモンド 200 午前 9:30 <NULL>
128 8:57am Seattle 340 午前 9:20 午後 3:05
129 午前 9:12 Seattle 120 午前 9:45 <NULL>
130 午前 9:30 レドモンド 25 午前 10:15 <NULL>
131 9:45 Seattle 250 午前 10:35 <NULL>
132 午前 10:00 レドモンド 100 <NULL> <NULL>
133 午前 10:15 Seattle 230 <NULL> <NULL>
134 午前 10:25 レドモンド 45 <NULL> <NULL>

このテーブルでは、BAM によって新しい注文書が受け取られると、新しい行が挿入され、いくつかの列 (受け取り時間、市、数量など) に Null 以外の値が設定されます。 その後、この注文書を承認して出荷すると、出荷時間が Null 以外の値に設定されます。 最後に、出荷情報を受け取って確認すると、納品時間が Null 以外の値に設定されます。

この簡単な実装のパフォーマンスは、時間と共に急速に低下します。 最初のパフォーマンスは、SQL Server で実行できるトランザクションの数 (基本的に CPU によって決まります) によって制限されますが、しばらくすると急速に低下します。 同時に、ディスク IO に対するキューの長さの平均値も、許容制限値を超えて増加します。

ディスク IO の平均キュー長が許容される制限を超えて増加する方法を示すスクリーンショット。
BAM の書き込みパフォーマンスとディスク キューの長さ

このパフォーマンス低下の原因は、完了したビジネス プロセスのインスタンスの数が増加するにつれて、テーブルのサイズが増加するためです。 たとえば、最初はストアド プロシージャの UPDATE ステートメントで、クラスター化インデックスを使って注文書番号が検索され、ページの一部がメモリに読み取られます。 注文処理のインスタンスは独立している (処理にかかる時間がそれぞれ異なる) ため、次のストアド プロシージャの呼び出しでは、注文処理の他のインスタンスが処理される場合があります。その場合、別のデータ ページをメモリに読み取る必要があります。 注文書レコードの合計数が少ない場合であれば、SQL Server では、すべてのデータ ページがメモリにキャッシュされます。 レコード数が非常に多くなると、キャッシュ ヒット率が低下し、操作ごとに物理ディスクの読み取りが必要になります。 レコード数が多くなるような状況では、テーブルに対するクエリ アクティビティのパフォーマンスが低下する可能性は非常に高くなります。

BAM テーブル

この問題を回避するために、BAM では 2 つの異なるテーブルを使用します。次の図のように、1 つは実行中のアクティビティ用に使用し、もう 1 つは完了したアクティビティ用に使用します。

BAM が 2 つの個別のテーブルを使用する方法を示す画像。
BAM テーブル

この図の考え方は、更新が行われる比較的小さなテーブルと、アクセス (INSERT のみ) 数が増加し、徐々に拡張されるもう 1 つのテーブルを管理することです。 上記の例では、現在処理中の注文書のみがアクティブ テーブルに格納され、既に配送が完了したすべての注文書が完了済みテーブルに格納されます。

このテーブルの構造では、トリガーが原因で最初のうち 1 つのテーブルの INSERT と UPDATE の速度が遅くなりますが、書き込みのパフォーマンスは時間がたっても安定した状態に保たれます。

アクティビティ データ用のオンライン時間帯

アクティビティのストレージでは、主に現在のアクティビティや最近完了したアクティビティをクエリします。 BAM では、古くなった完了済みのアクティビティをアーカイブし、BAM プライマリ インポート データベースから削除します。 したがって、アクティビティ データが BAM 経由で流れるので、構成可能なオンライン時間帯の期間内はクエリに使用できます。

BAM のパーティション分割

アクティビティ ストレージでは、パフォーマンスを向上し、ダウンタイムを避けるために、アクティビティの完了時のタイムスタンプに基づくパーティション分割を使用します。 BAM では、完了したテーブルを、同一フォーマットの空のテーブルと定期的に交換することにより、この機能を実現します。 BAM によってこの処理が実行されると、次の図のように、その後に完了したアクティビティが新しいテーブルに格納され、古いアクティビティはクエリのためだけに保持されます。

さらに完了したアクティビティが新しいテーブルに入る方法を示す画像。BAM ではクエリに対してのみ古いものが保持されます。
BAM のパーティション交換

オンライン時間帯の期間を完全に過ぎたパーティションは、BAM によってアーカイブされ、削除されます。 ユーザー操作が複雑にならないように、次のコードを使用して、フォームのパーティション ビューを管理します。

SELECT * FROM Active   
UNION ALL   
SELECT * FROM Completed   
UNION ALL

BAM では、パーティションを作成または削除するたびにこのビューを自動的に再作成します。

BAM のパーティション分割に関する注意事項を次に示します。

  • パーティション ビューの名前は 、bam_<ActivityName>_AllInstances です。 このビューは、直接クエリを実行するためのビューではありませんが、BAM の構成のトラブルシューティングに役立つ場合があります。 クエリによるデータの取得は、このビューの上部に作成するビジネス ユーザーのカテゴリごとの特定のビューに対して実行してください。 詳細については、「 インスタンス データのクエリ」を参照してください。

  • オンライン ウィンドウを設定するには、プライマリ インポート データベースのテーブル bam_Metadata_Activitiesの現在のアクティビティのレコードの OnlineWindowTimeUnit と OnlineWindowLength の値を変更します。

  • DTS パッケージ BAM_DM_<ActivityName> は、パーティション分割とアーカイブ/消去を実行します。 このパッケージが実行されるたびに、別のパーティションを切り捨て、オンライン時間帯の期間を過ぎたすべてのパーティションをアーカイブおよび削除します。

  • アーカイブ データベースを構成していない場合、BAM は古いデータをアーカイブしないで削除します。

参照

BAM 動的インフラストラクチャ