8

私はバルクロードのパフォーマンスを向上させるために取り組んでいます。数億のレコード+毎日。

データテーブルの代わりにインターフェイスを使用するためにこれを移動し、IDatareaderパフォーマンスが大幅に向上しました(1分あたり500,000レコード以上)。現在の設定は次のとおりです。

  • 区切られたファイルを解析するためのカスタムキャッシュリーダー。
  • バッファリングされたストリームでストリームリーダーをラップします。
  • IDatareaderオブジェクトを列挙し、インターフェイスを実装するカスタムオブジェクトリーダークラス。
  • 次にSqlBulkCopyサーバーに書き込みます

パフォーマンスボトルネックの大部分は直接にありSqlBulkCopy.WriteToServerます。プロセスをユニットテストすると、プロセスだけを除いてWriteToServer、約1分で戻ります。WriteToServerさらに15分以上かかります+。単体テストの場合、それは私のローカルマシン上にあるので、データベースが存在するのと同じドライブであるため、ネットワークを介してデータをコピーする必要はありません。

ヒープテーブルを使用しています(インデックスなし、クラスター化または非クラスター化、パフォーマンスに大きな違いはなく、さまざまなバッチサイズで遊んだことがあります)。

ロード時間を短縮する必要があるので、誰かがこのターンアップからもう少し血を搾り出す方法があることを願っています。

4

1 に答える 1

1

SSISを直接使用してみませんか?

とにかく、構文解析からIDataReaderへの処理を行った場合は、すでに正しい方向に進んでいます。SqlBulkCopy自体を最適化するには、SQLServerに焦点を当てる必要があります。重要なのは、最小限のログ操作です。次のMSDN記事を読む必要があります。

ターゲットがBツリー(つまり、クラスター化インデックス付きテーブル)の場合、残念ながら、パフォーマンスの高い一括挿入の最も重要な信条の1つ、つまりソートされた入力行セットは宣言できません。このように単純なため、ADO.Net SqlClientにはSSPROP_FASTLOADOPTIONS -> ORDER(Column)(OleDb)に相当するものがありません。エンジンはデータがすでに並べ替えられていることを認識していないため、プランに並べ替え演算子を追加します。これは、こぼれた場合を除いてそれほど悪くはありません。こぼれないように、小さなバッチサイズ(〜10k)を使用してください。私の元のポイントを参照してください。これらはすべて、OleDB MSDN仕様を掘り下げるのではなく、SSISで設定するための単なるオプションとクリックです...

データストリームが最初からソートされていない場合、または宛先がヒープである場合、上記のポイントはミュートです。

ただし、最小限のロギングを達成することは、まともなパフォーマンスのために依然として必須です。

于 2013-03-20T15:13:18.563 に答える