次の方法で共有

Azure Stream Analytics から Azure SQL Database のスループット パフォーマンスを向上させる

この記事では、Azure Stream Analytics を使用して Azure SQL Database にデータを読み込むときに、書き込みスループットのパフォーマンスを向上させるヒントについて説明します。

Azure Stream Analytics の SQL 出力では、オプションとして並列書き込みがサポートされています。 このオプションを使用すると、複数の出力パーティションが宛先テーブルに並列で書き込まれる 、完全 並列ジョブ トポロジが可能になります。 ただし、Azure Stream Analytics でこのオプションを有効にすると、データベースの構成とテーブル スキーマに大きく依存するため、スループットを向上させるには不十分な場合があります。 インデックス、クラスタリング キー、インデックスの塗りつぶし係数、圧縮の選択は、テーブルの読み込み時間に影響します。 データベースを最適化して、内部ベンチマークに基づいてクエリと読み込みのパフォーマンスを向上させる方法の詳細については、 SQL Database のパフォーマンス ガイダンスを参照してください。 SQL Database に並列で書き込む場合、書き込みの順序は保証されません。

ソリューションの全体的なスループットを向上させるために役立つ各サービス内の構成をいくつか次に示します。

Azure Stream Analytics

  • [パーティション分割の継承 ] – この SQL 出力構成オプションを使用すると、前のクエリ ステップまたは入力のパーティション構成を継承できます。 これを有効にすると、ディスク ベースのテーブルに書き込み、ジョブの 完全並列 トポロジを使用すると、スループットが向上します。 他の多くの出力に対して、このパーティション分割は既に自動的に行われています。 このオプションを使用して行われる一括挿入では、テーブル ロック (TABLOCK) も無効になります。

    注

    入力パーティションが 8 個を超える場合は、入力パーティション分割スキームを継承することは適切でない可能性があります。 この上限は、単一の ID 列とクラスター化インデックスを持つテーブルで確認されました。 この場合は、クエリで INTO 8 を使用して、出力ライターの数を明示的に指定することを検討してください。 スキーマとインデックスの選択に基づいて、観察内容が異なる場合があります。

  • バッチ サイズ - SQL 出力構成では、ターゲット テーブル/ワークロードの性質に基づいて、Azure Stream Analytics SQL 出力の最大バッチ サイズを指定できます。 バッチ サイズは、一括挿入トランザクションごとに送信されたレコードの最大数です。 クラスター化列ストア インデックスでは、 約 100K のバッチ サイズを使用すると、並列処理、最小ログ記録、およびロックの最適化が可能になります。 ディスク ベースのテーブルでは、バッチ サイズが大きいほど一括挿入中にロックエスカレーションがトリガーされる可能性があるため、10K (既定) 以下がソリューションに最適な場合があります。

  • 入力メッセージのチューニング – パーティション分割とバッチ サイズの継承を使用して最適化した場合、パーティションごとのメッセージあたりの入力イベントの数を増やすと、書き込みスループットをさらに高めるのに役立ちます。 入力メッセージのチューニングにより、Azure Stream Analytics 内のバッチ サイズを指定されたバッチ サイズまで指定できるため、スループットが向上します。 これを実現するには、EventHub または BLOB で 圧縮 を使用するか、入力メッセージのサイズを増やします。

SQL Azure

  • パーティション テーブルとパーティション インデックス – パーティション キー (PartitionId など) と同じ列を持つテーブルで パーティション SQL テーブルとパーティション インデックスを使用すると、書き込み中のパーティション間の競合を大幅に削減できます。 パーティション テーブルの場合は、PRIMARY ファイル グループに パーティション関数 と パーティション構成 を作成する必要があります。 これにより、新しいデータの読み込み中に既存のデータの可用性も向上します。 ログ IO の制限は、SKU をアップグレードすることで増やすことができるパーティションの数に基づいてヒットする可能性があります。

  • 一意のキー違反を回避 する – Azure Stream Analytics アクティビティ ログに 複数のキー違反警告メッセージ が表示される場合は、復旧時に発生する可能性のある一意の制約違反の影響をジョブが受けないようにします。 これは、インデックスに IGNORE_DUP_KEY オプションを設定することで回避できます。

Azure Data Factoryおよびインメモリテーブル

  • In-Memory テーブルを一時テーブルとして 使用する –In-Memory テーブル では、非常に高速なデータ読み込みが可能ですが、データはメモリに収まる必要があります。 ベンチマークでは、インメモリ テーブルからディスク ベース テーブルへの一括読み込みは、ID 列とクラスター化インデックスを持つディスク ベース のテーブルに 1 つのライターを使用して直接一括挿入するよりも約 10 倍高速であることが示されています。 この一括挿入のパフォーマンスを活用するには、メモリ内テーブルからディスク ベースのテーブルにデータをコピーする Azure Data Factory を使用してコピー ジョブ を設定します。

パフォーマンスの落とし穴の回避

データの一括挿入は、データの転送、insert ステートメントの解析、ステートメントの実行、トランザクション レコードの発行の繰り返しオーバーヘッドが回避されるため、1 回の挿入でデータを読み込むよりもはるかに高速です。 代わりに、より効率的なパスをストレージ エンジンに使用してデータをストリーミングします。 ただし、このパスのセットアップ コストは、ディスク ベース テーブル内の 1 つの insert ステートメントよりもはるかに高くなります。 通常、損益分岐点は約 100 行であり、その後の一括読み込みはほぼ常により効率的です。

受信イベントのレートが低い場合は、100 行未満のバッチ サイズを簡単に作成できるため、一括挿入が非効率的になり、ディスク領域が多すぎます。 この制限を回避するには、次のいずれかのアクションを実行します。

  • すべての行に対して単純な挿入を行うための INSTEAD OF トリガー を作成します。
  • 前のセクションで説明したように、In-Memory 一時テーブルを使用します。

このような別のシナリオは、非クラスター化列ストア インデックス (NCCI) に書き込むときに発生します。一括挿入が小さすぎるとセグメントが多くなりすぎるため、インデックスがクラッシュする可能性があります。 この場合、代わりにクラスター化列ストア インデックスを使用することをお勧めします。

まとめ

要約すると、SQL 出力用の Azure Stream Analytics のパーティション分割された出力機能を使用して、ジョブを SQL Azure のパーティション テーブルに合わせて並列化すると、スループットが大幅に向上します。 In-Memory テーブルからディスク ベース テーブルへのデータ移動を調整するために Azure Data Factory を利用すると、スループットが桁違いに向上する可能性があります。 可能であれば、メッセージ密度の向上も、全体的なスループットを向上させる大きな要因になる可能性があります。

次のステップ

  • Last updated on