SQL Server: Performance-Optimierung

Wie schnell sind 100.000 UPDATEs?

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Folgen Sie diesem Geschwindigkeitstest für 100.000 UPDATEs und hören Sie ein paar Worte zum Deltastore des Clustered Columnstore Index.
06:22

Transkript

Was natürlich auch interessant ist, ist die Frage, wie lange dauern denn UPDATES? Was ist denn da die schnellste Alternative? Und zu diesem Zweck habe ich den Test für die Selects adaptiert. Das heißt, jetzt werden nicht so und so viele Selects durchgeführt, sondern es werden entsprechende UPDATES durchgeführt, die auch nach einem zufälligen Wert auf Daten zugreifen, und dann diese schlicht und ergreifend an der Stelle in irgend einer Form modifizieren. Ich zeige Ihnen mal wie die Skripte aussehen. So, schön dass Sie mir ins SQL Server Management Studio gefolgt sind. Vorab es gibt auch hier zwei verschiedene Skripts, und zwar einmal für den Test mit allen Kernen des Rechners, das heißt, da hat der SQL Server die Wahl alle Kerne zu benutzen, und die zweite Variante hier, die wieder mit dem MAXDOP, genau wie bei dem SELECT schon, entsprechend künstlich limitiert wird. Das Skript selber ist relativ ähnlich zu dem was Sie beim SELECT schon gesehen haben. Das heißt, ich habe wieder einige Variablen hier für den counter, für den maximalen counter. Ich habe sogar hier die dummy Variablen drin gelassen, für den Fall, dass man die in irgendeiner Form für Tests benötigt oder Ähnliches, konkret werden die hier nicht mehr verwendet. Und dann schaue ich mir wieder an, wie viel Zeilen gibt es, lösche wieder den Bufferpool, nehme die Startzeit, lasse das ganze laufen, und zum Schluss gebe ich die verstrichene Zeit ein an der Stelle. Das Gleiche dann erst einmal für den Heap, dann für den Clustered Index, für den Nonclustered Index, und für den ClusteredColumnstore Index und so weiter, und so fort. Wie gesagt, das zweite Skript ist identisch bis auf den Unterschied, dass hier überall an entsprechender Stelle MaxDop1 zu finden ist. Und ich würde sagen, ich starte jetzt die Tests, und wenn die durchgelaufen sind, sehen wir uns gleich auf der Ergebnisfolie wieder. So, alle Skripte sind gelaufen, die Ergebnisse notiert, und sie stellen sich wie folgt dar: Clustered Columnstore Index in der Mitte, weit abgeschlagen, mit Abstand die längsten Laufzeiten von 261, beziehungsweise 332 Sekunden, und auch da einmal mit 8 Kernen und dann einmal mit MaxDop1 als Einschränkung. Am schnellsten auf der anderen Seite war Memory Optimized, das heißt, die Tabelle die nicht auf die Platten persistiert, das ist eine reine Speicheroperation, da sind 100.000 Updates, ein Klacks an der Stelle, 2 oder 3 Sekunden eher relativ langsam noch. Dazwischen liegen dann, relativ knapp beieinander die gewöhnlichen Indizes, also einmal Non clustered Index und einmal Clustered Index, und Memory Optimized mit einer Persistierung auf die Platten, ist entsprechend relativ noch dabei. Es ist ein bisschen schneller mit 17 und 3 Sekunden, aber auch da ist der Unterschied nicht mehr wirklich groß an der Stelle. Letztendlich ein nicht besonders überraschendes Ergebnis, und es zeigt, wenn Sie nur im Speicher Operationen durchführen, und auf eine Persistierung ganz verzichten können, was möglicherweise gar nicht mal so abwegig ist, man muss überlegen, von welchem Fall quasi man ausgehen kann, ob es quasi etwas wie Zwischenergebnisse sind, oder kurz notierte Ergebnisse, die dann in irgendeiner Form weiterverarbeitet werden, und später vielleicht aggregiert, entsprechend persistiert werden, dann ist das durchaus eine gute Sache an der Stelle. Für die gewöhnlichen Indizes, also gerade Clustered und Nonclustered Indizes, also die man in den meisten Fällen für die Tabellen aus gutem Grund verwendet, macht das durchaus einen guten Eindruck, es ist langsamer, es ist Faktor 10 langsamer, aber die Geschwindigkeit ist dennoch relativ akzeptabel an der Stelle. Und wenn Sie natürlich Memory Optimized möchten mit einer Persistierung auf die I/O Systeme, auf die Platten, dann sind Sie mit 17 und 13 Sekunden entsprechend, so im, ja, fast schon Mittelfeld an der Stelle. Das ist natürlich relativ schnell, die zweitschnellste Lösung, da müssten Sie allerdings, wie gesagt, ich hatte es in einem der vorherigen Kapitel schon mal angesprochen, natürlich mit dem geänderten Transaktionsverhalten umgehen können, ansonsten auch hier eine attraktive Alternative. Ein Hinweis noch in Sachen Clustered Columnstore Index, jede Änderung, die Sie machen, sei es INSERT, DELETE oder UPDATE, wird nicht direkt im Index vollzogen, sondern im sogenannten Deltastore zwischengespeichert. Das heißt, je mehr Änderungen Sie machen desto mehr wird der Clustered Columnstore Index in seinem Verhalten, in seinen Eigenschaften von einem Clustered Columnstore Index halt, zu einem B-Tree sich ändern. Warum passiert das? Clustered Columnstore Indexes ist eigentlich nicht updatefähig. Microsoft greift da in die Trickkiste, Änderungen werden in dem Deltastore erst mal zwischengespeichert, und wenn die CPU Zeit findet und genügend Änderungen stattgefunden haben, dann ist es so, dass die einzelnen Row Groups, das ist wiederum die Aufteilung, für Gruppen von Zeilen, dass diese dann entsprechend komprimiert ist und Sie sehen das hier in dieser Abfrage. Das Ergebnis sieht so aus, dass alle row_groups komprimiert sind, und es nur eine gibt, die ein state von 1 und ein state_description von OPEN hat, das bedeutet, das sind Zeilen die sich nicht direkt in komprimierter Form in der Datenbank befinden, sondern schlicht und ergreifend einfach nur in einem B-Tree in dem Moment, in einem Clustered Index befinden, an der Stelle. Das bedeutet wiederum, je mehr Änderungen, desto schlechteres Verhalten in der Regel, zumindest was die Kompression betrifft, dafür um so besseres Verhalten was die Abfragegeschwindigkeit betrifft. Um alle Row Groups zu schließen haben Sie die Möglichkeit, den Index einfach neu aufzubauen, dann wird der auch entsprechend optimal ausbalanciert, das heißt, alle Row Groups wird versucht, sollen die gleiche Anzahl von Zeilen bekommen. Sie sehen das hier in total_rows, das ist ein bisschen wild quasi an der Stelle, nichtsdestotrotz aber sind, würden Sie die Abfrage ausführen und würden Sie nach unten scrollen, würden Sie sehen das höchstwahrscheinlich oder mit ziemlicher Sicherheit, die Row Groups bis auf eine, auch in der Tat alle komprimiert sind. Das nur so als kleiner Hinweis. Das heißt, wenn Sie viele Änderungen an Clustered Columnstore Indizes machen, haben Sie den Effekt, dass daraus langsam aber sicher ein Index wird quasi, beziehungsweise ein B-Tree Index.

SQL Server: Performance-Optimierung

Lernen Sie den Umgang mit Indizis und Tools, um die Leistungsfähigkiet Ihrer SQL Server Datenbank effektiv zu erhöhen.

3 Std. 20 min (32 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:04.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!