ストアドプロシージャよりもSSISパッケージを使用する利点は？
ストアドプロシージャを使用して必要なETL要件を実行できる場合、代わりにSSISパッケージを使用する利点はありますか？私のETLのものは大きなものではありません。
古い技術を使っているような気がします。私はSQLが好きです。ストアドプロシージャがすぐになくなることはないため、古いテクノロジは時代遅れではありません。
ETLがほとんどEとLで、Tがほとんどない場合、およびカーソルに依存しないようにSPを作成できる場合は、SPのみのルートで問題ないでしょう。
より複雑なプロセス、特に重い変換、緩やかに変化するディメンション、データマイニングルックアップなどを伴うプロセスの場合、SSISには3つの利点があります。
まず、メモリを非常に効率的に管理します。これにより、T-SQLのみと比較してパフォーマンスが大幅に向上する可能性があります。
次に、グラフィカルインターフェイスを使用すると、手作りのT-SQLよりもはるかに簡単に、大きく複雑で信頼性の高い変換を構築できます。
そして3番目に、SSISを使用すると、追加の外部ソースと簡単にやり取りできるため、データのクレンジングなどに非常に便利です。
私は、マルチテラバイトのSQL ServerデータウェアハウスのストアドプロシージャETLの土地に住んでいました。この決定は、.NETが1.0だった2001年に行われたため、VB6はプログラミング言語の代替手段であり、SSISはまだ存在していませんでした-DTSでした。何かのように、長所と短所があったと言えるでしょう。
いくつかの考慮事項：
- チームの全員がSQLを理解していれば、ストアドプロシージャを簡単に調べることができます。 SQLは広く知られているスキルであり、多くのETLライター/リーダーがある場合にメリットがあります。 SSISが何をしているのかを理解するには、SSISのカジュアルユーザー以上のものが必要です。高レベルのグラフィカルフローはドキュメントにとっては素晴らしいですが、誰かが根性を理解する必要がある場合は、SSISをよく理解しているはずです。
- SQLはモジュール化するのが面倒です。 UDFを使用すると、パフォーマンスが大幅に低下します。同様のコードを複数の場所で記述し、それを行うことを嫌いますが、ETLシナリオでは、多くの場合、パフォーマンスが重要です。 SSISは、タスクのモジュール化と分解を支援します。
- SSISでソース管理を簡単に使用できると期待しないでください。 SQL-問題ありません。 SSISは、チェックインできるひどいXMLファイルを使用しますが、以前のバージョンと比較して、何がいつ変更されたかを確認してください。
- 必要に応じてモジュール化することは困難ですが、SPをモジュール化して考える必要があります。一時テーブルを使用して、処理を分割します。使用する前に、これらの一時テーブルにインデックスを配置します。一度にやり過ぎないようにしましょう。すべてにコメントしてください。
- カーソルを使用している場合、それは間違っています。選択した言語で記述したいくつかの外部コンソールアプリをチェーンして、SQLが切り捨てられなかったいくつかのことを行うことを恐れないでください。
ところで-私がその会社を去った後、彼らはついにデータベースをSQL 2000から2008にアップグレードし、ゆっくりとストアドプロシージャからSSISに移行しました。私の新会社ではSSISを所有していますが、使用した後、カスタムで記述された.NET ETLが私たちの目的により適していることに全員が同意しました。誰もが自分のルートをたどります。決定は、メンテナンスとパフォーマンス、およびチームのスキルセットと地域のジョブプールのスキルセットのバランスを取る必要があります。
私はSSISパッケージを削除し、ストアドプロシージャを使用している最中です。私たちにとって、ストアドプロシージャは非常に優れています：1）メンテナンスがはるかに簡単です。入札が不要で、プロジェクトを作成してパッケージを入札にインポートする必要がないため、単純なストアドプロシージャを変更するための手順がはるかに少なくなります。 2）現在のすべてのパッケージは、基本的にテーブル内のデータを切り捨ててから、直接マッピングを使用して、同じサーバー上の他のいくつかのテーブルからデータを再取り込みします。作成するSQLの挿入/選択は非常に簡単です。 3）彼らははるかに速く走ります。カーソルもループ構造もありません。単純なSQLだけです。 4）ロジックのフローを追跡するために、右クリックして小さな入札ウィンドウで作業するためにすべての時間を費やす必要はありません。私たちは皆、基本的なTSQLを知っており、それで十分です。
それはあなたが何をしているのかに依存します。ただし、私の経験から、SSISパッケージの改善の余地は途方もないです。非常にヒットしたストアドプロシージャの一部をSSISパッケージに入れると、データウェアハウス環境で10倍の改善が見られました。 SSISのメモリ使用率（この状況ではとにかく）はすべての違いをもたらしました。
繰り返しますが、あなたが何をしているのかを知ることが重要です。たとえば、データ変換が同じサーバー上でテーブルからテーブルへの変換である場合、SQLステートメントは通常、SSISデータフローよりも優れています。
SPまたは2つを選択してSSISで作成し、両方をテストすることをお勧めします。
すべてのSQLの質問の答えは、次のように始まります。
SSISを使用するとパフォーマンスが大幅に向上します。リンクサーバーを使用しているストアドプロシージャの方が処理能力が高く、リンクサーバーが必要な行を制限する前にテーブル全体をメモリにプルする傾向があるため、特に優れています。参加する。実行に7時間以上かかるストアドプロシージャがありました。これを各サーバーからのデータに分解し、SSISでローカルデータソースをそれぞれに設定して、リンクサーバー経由で行われるように各データソースに対してローカルで処理を実行できるようにしました。ジョブの実行には6分かかります。これは大きな利益です。
カラリン
私たちは、2つの世界のベストを獲得するために組み合わせた方法を使用しています。SSISを使用して外部ソースからデータを取得し、それをステージングデータベースに並行してロードします。次に、SSISパッケージを使用してパイプラインを調整し、制御フロー内の適切なSPをトリガーします。
データフローは管理/変更が難しく、大きな利点がないため、変換ロジックはすべてSPに組み込まれています。1）変更とトラブルシューティングが簡単ですSPパッケージよりも2）ありません外部パッケージの呼び出しを除いて、SSISのコンポーネントを簡単に再利用する方法3）SPのSVN差分は機能し、SSISパッケージの差分はひどい:)
また、SSISを使用してSPを並行して実行し、全体的なパフォーマンスを向上させます。
SSISにはいくつかの基本的な機能がありません。SQL文を使用した開発を生のテキストファイルに対して実行できるInformaticaタイプのパッケージがなく、SQLサーバーにはOracleのようなエラーロギングDMLがありません。 MicrosoftがMergeステートメントの追加を発表したとき、もちろん、最も重要な機能の1つであるエラーバケットを実装することを本当に考えました。行レベルでのエラー処理は重要であり、SQLステートメントを使用してデータのバッチを追加する場合、1つのレコードが失敗すると、そのバッチ全体がロールバックされます。
バージョン6.5以降、SQL Serverを使用しています。そして、私の経験から、ほとんどのETLは単純であり、T-SQLは完全に正常に機能し、機能するだけでなく非常に適切に機能します。高速で信頼性が高く、単純な構造化プログラミングです。 SSISで実行できることはすべて、T-SQLで実行できることを知っている人なら何でも実行できると思います。
私の経験では、プロのSSISに重い人のほとんどは、グラフィカルツールで育ち、プログラミング方法を本当に知らない経験の浅い開発者です。
SSISのいくつかの機能を試しましたが、すべてに満足できませんでした。私はデータフローのことをはっきり言って、私が見たパフォーマンスに本当に満足していませんでした。私がやったことは、それぞれがストアドプロシージャを実行するSQLタスクの制御フローを持つSSISパッケージを開発することでした。
これにより、SQLサーバーがほとんどのE、T、およびLを実行したことが確認されました。データフローコンポーネントを使用すると、データは実際にはSQLサーバーからパッケージを実行しているマシンに移動するため、それほど効率的ではないと思います。
とは言っても、サードパーティのアプリケーション/データベース/ DWシステムとやり取りしなければならなかった場合、私はDataflowを最適化しようと試みたと思います（私はそれに取り組んでからしばらく経っています）。
明らかな技術的な制限はありません。ストアドプロシージャは、複雑なETL操作ではSSISパッケージよりも従うのが難しい場合がありますが、すべてのシナリオに当てはまるわけではありません。また、パッケージ（SSISおよびDTS）が「ジョブ」としてより簡単に認識されることもわかりました。スケジュールされたジョブによって実行されるストアドプロシージャは、スケジュールされたジョブを見ることができないため、開発者に見落とされがちです。
とはいえ、ストアドプロシージャとDTS/SSISパッケージによってETLが同様に実行されるのを見てきましたが、ストアドプロシージャが複雑なコードの大規模な混乱でない限り、適切と思われます。あるメソッドが別のメソッドよりも優れたパフォーマンスを発揮することはありませんでした（ただし、複雑なETLを実行するストアドプロシージャを見たことはありません）。
パフォーマンスは通常のspよりも速くなります。データを取得するために複雑な一時テーブル、カーソル、インデックスを作成する必要はありません。
データクリーニングはSSISの利点です。
増分処理はssisでのみ可能です。
パッケージ構成ファイルを作成して、任意のサーバーに展開できます。ユーザーはサーバーの詳細とログイン情報を提供できます。
グラフィカル・ユーザー・インターフェース。
ロギング、エラー処理は、ssisに最適です。
小規模なプロジェクトで、SQLの確かなスキルとビジネス要件を理解している場合は、先に進んでください。
そうでなければ、複雑なデータ抽出、重い変換タスクに直面するでしょう。 SSISまたは別のETLツールで十分です。
乾杯
SQLサーバー間のデータ転送には、SPより上のSSISを使用します。上記のように、10倍の改善が簡単に実現できます。SPをSSISパッケージ
余談ですが、SSISは基本的にXMLファイルの集まりであり、さまざまな方法（ドキュメントなど）で操作/使用できます。