Home
Datenquellen
Controllflow
DataFlow
SSIS
ToC
Impressum
 

Vergleich der Performancewerte für die unterschiedlichen Datenquellen und -Ziele

Können in Integration Services Daten schneller in eine Datenbank oder in eine Textdatei geschrieben werden? Wie schnell geht das lesen von den unterschiedlichen Datenquellen?

Hier geht es um nackte Performancewerte.

Damit die Performancewerte miteinander verglichen werden konnten, wurde mit Hilfe der Data Generator Source jeweils 500.000 Datensätze erzeugt und in unterschiedliche Datenziele geschrieben. Danach werden die Daten wieder gelesen und in das endgültiges Datenziel der Trash-Adapter geschrieben.

Folgende Fälle wurden untersucht:
 

Datenziel (Adapter) Datenquelle (Adapter)
Flatfile Flatfile
Flatfile Flatfile mit Option Fastparse
Rohdatendatei Rohdatendatei
Tabelle in Datenbank
OLE-DB Option Fast
Tabelle in Datenbank
OLE-DB
Tabelle in Datenbank
SQL Server Ziel
Tabelle in Datenbank
OLE-DB
Tabelle in Datenbank
ADO.Net Adapter
Tabelle in Datenbank
ADO.Net Adapter
ADO.Net Recordset im Speicher ADO.Net Recordset im Speicher
Tabelle in Datenbank
OLE-DB ohne Fast
Tabelle in Datenbank
OLE-DB

Der Gesamtzeitbedarf wurden durch die Verwendung von Scripttasks in den Events PreExeute und Post Execute der jeweiligen Task Datenflußtask gemessen.

Der Vorlauf und die Ergebnisse

Für den Vorlauf wurde eine Integerspalte und eine Textspalte mit einer Länge von 50 Zeichen erzeugt. Gemessen wurde das schreiben und das einlesen.
Es wurden jeweils drei Messungen durchgeführt. Der Durchschnittswert entscheidet.

 

Zugriff Durchschnitts-
wert in Ms
Unterschied
Flatfile mit Fastparse 18.099,64 100,00%
Rohdatendatei 18.517,35 102,31%
Flatfile 18.557,15 102,53%
Staging Tabelle (SQL Server Ziel) 21.361,34 118,02%
Staging Tabelle (OLE-DB Fast) 25.900,95 143,10%
ADO.Net 26.144,51 144,45%
Recordset im Speicher 54.342,28 300,24%
Staging Tabelle (OLE-DB slow) 585.311,99 3.233,83%

Die ersten drei Optionen, Flatfile mit der Option Fastparse, das Rohdatenformat und die einfache Textdatei liegen so eng zusammen, dass eine zusätzliche Messung notwendig ist.

Das Datenziel SQL-Server ist knapp 20% Prozent schneller als die nächste Option zum schreiben der Daten in eine Tabelle auf dem SQL Server. Es gibt allerdings einige Einschränkungen, die bei diesem Datenziel beachtet werden müssen:

  • Das Paket muss auf der gleichen Maschine laufen wie der SQL Server 2005. Eine Verbindung auf ein Remotesystem wird nicht unterstützt.
  • Der SQL Server muss der SQL Server 2005 (jede Edition) sein.
  • Es ist nicht möglich die Zeilen pro Batch und die maximale Einfügungscommitgröße festzulegen. Das bedeutet, alle Datensätze werden innerhalb einer Transaktion in die Tabelle geschrieben. Das Transaktionslog wird entsprechend stark belastet.

Der Zugriff über ADO.Net ist langsamer als der Zugriff über OLE-DB. Wenn mehrere Spalten verarbeitet werden ist dieser Unterschied größer. Das kommt daher, da wesentliche Teile in SSIS in nativen Kode geschrieben wurde; der ADO.Net Adapter wurde in C# geschrieben.

Das Recordset im Speicher, ist nur für die Übergabe von kleinen Datenmengen brauchbar. Erstens beansprucht es sehr viel Hauptspeicher und ist zudem auch langsam. Dies mag auf den ersten Blick überraschen. Das einlesen der Daten wurde durch eine Scripttranformation durchgeführt. Hier wird eine Menge Zeit gebraucht.

Das Schreiben der Daten über OLE-DB ohne den Modus schnelles Laden ist mit weiten Abstand am langsamsten. Diese Option sollte nicht ohne zwingenden Grund verwendet werden. Müssen allerdings Trigger und/oder Constrains in der Zieltabelle berücksichtigt werden, gibt es keine andere Wahl.

Das Finale mit den Ergebnissen

Für den Endscheidungskampf wurde die Regel geändert:

  • 500.000 Datensätze
  • allerdings 5 Textfelder mit einer Länge von 50 Zeichen und 10 Felder mit Zahlen
  • nur die drei schnellsten Verfahren wurden ausgewählt
Zugriff Durchschnitts-
wert in Ms
Unterschied
Rohdatendatei 91.528,86 100%
Flatfile mit Fastparse 97.964,79 107,03%
Flatfile 98.285,30 107,38%

Je mehr Spalten geschrieben werden, umso deutlicher wird der Performancevorteil wenn die Daten über die Rohdatendatei gelesen und geschrieben werden.

Genau die gleiche Aussage gilt bei der Option Fastparse für das einlesen von Textdateien. Allerdings wird die Option Rohdatendatei nie eingeholt.

Die Warnung

Bitte testen Sie die beiden Demopakete nicht auf einen Produktionsrechner.
Beim Starten dieser Pakete wird die CPU des Rechner, auf dem das Paket ausgeführt wird über mehrere Minuten mit 100 Prozent ausgelastet.

Die beiden Demopakete finden Sie hier. Der Verbindungs-Manager muss für Ihre Umgebung angepasst werden. Bitte aktivieren Sie den entsprechenden Sequenzcontainer für die Messung.

Zusammenfassung

Durch die Auswahl der möglichen Datenflussquellen und - ziele können sehr große Performanceunterschiede festgestellt werden. Für das Zwischenspeichern von Daten ist das Rohdatenziel die optimale Wahl.

Komponentenindex:

erstellt am 14.8.2006