Zunächst einmal, was ich nicht frage. Ich frage nicht, wie meine Einstellung sein soll.
Viele empfehlen, den Wert über den Standardwert hinaus zu erhöhen, und ich verstehe mit Sicherheit, warum dies bei B-Tree-basierten Abfragen der Fall ist. Ich habe jedoch über die (fast) lineare Skalierbarkeit von In-Memory-Clustered-Columnstore-Indizes gelesen und frage mich, ob ein zu hoher Kostenschwellenwert dazu führen kann, dass SQL Server spaltenbasierte Abfragen für CPU-Kerne aushungert.
Die Frage lautet also: Behandelt SQL Server Columnstore-Indizes anders, wenn es um die 'Kostenschwelle für Parallelität' geht, und sollte dies dazu führen, dass ich meine Entscheidung über meine anfängliche Einstellung ändere?
sql-server
sql-server-2014
columnstore
Dave Markle
quelle
quelle
TL; DR: Die vorgeschlagene Anfangseinstellung von 50, über die Sie gelesen haben, bleibt ein guter Ausgangspunkt. MAXDOP von 1 physischen Kern pro NUMA-Knoten ist eine gute Einstellung für einen Server wie unseren, der sowohl OLTP- als auch OLAP-Workloads bedient.
Corrolary: SQL Server ist wirklich sehr, sehr gut darin, was es tut.
Meine Hauptsorge bei dieser Einstellung war, ob ich die parallele Ausführung auf einem Clustered-Columnstore-basierten Index für ziemlich kurze Abfragen verhindern würde oder nicht. Würde eine Einstellung von 50 dazu führen, dass eine Abfrage unter 1 Sekunde viel länger dauert? Würde die Einstellung "Kostenschwelle für Parallelität" einfach ignoriert, da Columnstore-Indizes mit CPUs so gut skaliert werden können?
A: Ja. Bei einer Konfiguration mit einer lächerlichen Einstellung von 30.000 wurde die Parallelität für Columnstore-Indizes für meine Workloads effektiv deaktiviert. Das Ausprobieren anderer, immer noch obszöner Werte (1.500) verhinderte die Parallelität von Workloads, deren Ausführung nominell etwa eine Sekunde dauerte, aber Abfragen, die nominell in etwa 10 oder mehr Sekunden ausgeführt wurden, zeigten parallele Ausführungspläne.
F: Ist eine Standardeinstellung von 50, wie in einigen Checklisten angegeben, ein sicherer Wert, der die Parallelität für meine auf Spaltenspeichern basierenden Abfragen nicht verhindert?
Über meinen Server, meine Arbeitslast und meine Ergebnisse:
Zwei getestete Workloads:
SELECT COUNT(DISTINCT <low cardinality column>) FROM table;SELECT COUNT(DISTINCT <high cardinality column>) FROM table;Die Abfrage der Spalte mit hoher Kardinalität dauerte 84 Sekunden (verstrichen) bei Schwellenwerten über 1500 und etwa 14 Sekunden (verstrichen) bei Schwellenwerten unter dieser Zahl. Die Abfrage der Spalte mit niedriger Kardinalität dauerte etwa 250 ms (verstrichen) bei Schwellenwerten von 500 und darunter und 18 (verstrichene) Sekunden bei Schwellenwerten über 1500. (Ich habe nicht versucht, den genauen Punkt zu messen, an dem die Pläne gewechselt wurden.) Interessanterweise Wenn die Parallelität gesperrt ist, steigt die Gesamt-CPU-Zeit für die Abfrage mit niedriger Kardinalität dramatisch an. Möglicherweise verwendet der Server den Stapelmodus für diese Abfrage nicht mehr.
Heh, letztendlich führt das Ausführen von Tests zu mehr Fragen, aber das ist alles Blog-Futter und geht über den Rahmen dieser Frage hinaus.
quelle
Ich möchte dem Artikel von Joe Chang hinzufügen, dass Sie diesen Artikel von Paul White lesen sollten , in dem er ein Trace-Flag behandelt, das CTFP für die von Ihnen ausgeführte Abfrage im Wesentlichen auf 0 setzt. Ich weiß, dass es nicht genau das ist , wonach Sie suchen, aber zusammen mit MAXDOP-Tests können Sie eine gute Vorstellung davon bekommen, ob Ihre parallele Abfrage überhaupt für Spaltenspeicher-Indexe von Vorteil ist. Ich habe es in letzter Zeit ein wenig ausprobiert (ich schwöre bei dev), anstatt den Plan, Parallelität zu erzwingen, künstlich zu komplizieren.
quelle