web-dev-qa-db-ja.com

SSISとT-SQLの結合パフォーマンス、同じサーバー上の差分データベース

SSISルックアップとT-SQL結合のパフォーマンスの違いを調査しています。 2つのテーブルを結合したい。テーブルは同じSQLサーバーインスタンス、異なるデータベースにあります。

小さなテーブル結合が疑われますが、その差は最小限かごくわずかです。この場合、私たちのチームは、図を書くよりもコーディング/スクリプト化が簡単なT-SQLを好みます。さらに、DevOpsパースペクティブでは、DBプロジェクトでスクリプトをコンパイル/ビルドできます。残念ながら、SSISはT-SQLを正しくコンパイルしません。SSIS実行SQLステートメントに「testabcd」と書いても、プロジェクトは引き続きビルド/コンパイルされます。

ただし、処理に時間がかかる多数の行の場合、何が速くなりますか？インデックスと統計情報を持つT-SQL、またはすべてメモリ内で実行されるSSIS？

私はこれらの記事をさまざまな視点で読み、チームはコンセンサスを得ようとしています。

https://derekdb.wordpress.com/2012/03/13/ssis-lookup-or-t-sql-join/http://www.sqlservercentral.com/blogs/jamesserra/2011/08/29/when-to-use-t_2D00_sql-or-ssis-for-etl /

T-SQLエンジンとSSISが同じハードウェアであるCPUとメモリを備えていると仮定します。同じ仕様で、内部アルゴリズムの観点からパフォーマンスの速度を知りたいのですが。

sql-serversql-server-2016ssisperformanceperformance-tuning
1
user162241

同じスペックの場合、パフォーマンスを知りたい

データが単一のSQL Serverインスタンス上にある場合、TSQL結合は常にSSISルックアップより高速である必要があります。これは実際には近くありません。 TSQLクエリは、インデックスと統計、およびコストベースのクエリオプティマイザーを活用します。結合はSQL Serverインスタンス内で実行されます。この場合、結合は効率的であるだけでなく、SSISパイプラインよりもメモリとディスクリソースが多くなります。

SSISルックアップは、主に宛先側のルックアップ、異種データシナリオ、およびクエリ処理エンジンのないソース（フラットファイルなど）を対象としています。

さらに、データソースが単一のSQL Serverインスタンスであり、宛先が単一の（おそらく異なる）SQL Serverインスタンスである場合、個人的にはany SSISデータフロー変換をほとんど使用しません。代わりに、抽出側の変換には常にソースシステムSQLを使用し、宛先側の変換にはステージアンドマージを使用します。

6
David Browne - Microsoft

Integration Servicesの目的を完全に誤解していると思います。間違ったツールを使用しても、作業は完了しますが、それは効率的ではなく、非常に賢明でもありません。

以下は、いくつかの主要な理由を説明しています。

SSISを使用する理由

  1. さまざまなソースを操作するための事前にパッケージ化されたコード（Oracle、MySQL）

  2. 異種ソース間の大規模なETLに最適（そして大規模な挿入、つまりバルクに最適）

  3. インスタンスから独立しています。ポータブル。

  4. デザインを変えるのが面倒。

TSQL（手順）を使用する理由

  1. 変更が簡単
  2. 一連のSQLステートメントである事前に記録されたステートメント
  3. インスタンス内に存在します。輸送が難しい。
  4. 小規模な操作向けに設計されています。
1
clifton_h