 |
 |
 |
 |
 |
 |
 |
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:
- Data Generator Source Adapter
- Trash Data Destination
- Datenflusstask
- Events
- Scripttask
- Flatfilequelle
- Flatfiledatenziel
- Recordsetziel
- DatenReader-Quelle
- Datenreader-Ziel
- OLE-DB-Quelle
- OLE-DB-Ziel
- Rohdatendatei-Quelle
- Rohdatendatei-Ziel
- SQL-Server-Ziel
erstellt am 14.8.2006