Columnstore-Indizes: Abfrageleistung

Artikel
07/12/2024

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Empfehlungen zum Erreichen der sehr schnellen Abfrageleistung, die Columnstore-Indizes vom Design her bereitstellen können sollten.

Columnstore-Indizes können eine bis zu 100-fach bessere Leistung für Analyse- und Data Warehousing-Arbeitsauslastungen und eine bis zu 10-fach bessere Datenkomprimierung als herkömmliche Rowstore-Indizes erreichen. Diese Empfehlungen unterstützen Sie beim Erzielen der schnellen Abfrageleistung, für die Columnstore-Indizes entwickelt wurden. Weitere Erläuterungen zur Columnstore-Leistung finden Sie am Ende.

Empfehlungen zur Verbesserung der Abfrageleistung

Im Folgenden finden Sie einige Empfehlungen zum Erreichen der hohen Leistung, für die Columnstore-Indizes entwickelt wurden.

1. Organisieren Sie Daten, um weitere Zeilengruppen im Rahmen eines vollständigen Tabellenscans zu beseitigen.

Nutzen Sie die Einfügereihenfolge. Im Allgemeinen werden in einem herkömmlichen Data Warehouse die Daten in zeitlicher Reihenfolge eingefügt. Die Analyse erfolgt in der Zeitdimension. Beispiel: Analyse der Umsätze nach Quartal. Für diese Art der Arbeitsauslastung wird das Löschen der Zeilengruppe automatisch durchgeführt. In SQL Server 2016 (13.x) können Sie die Anzahl der Zeilengruppen ermitteln, die als Teil der Abfrageverarbeitung ausgelassen werden.
Nutzen Sie den gruppierten Rowstore-Index. Wenn das allgemeine Abfrageprädikat für eine Spalte (z. B. C1) gilt, die nicht mit der Einfügereihenfolge der Zeile verbunden ist, können Sie einen gruppierten Rowstore-Index für die Spalte C1 erstellen und durch das Löschen des gruppierten Rowstore-Indexes einen gruppierten Columnstore-Index erstellen. Wenn Sie bei der Erstellung des gruppierten Columnstore-Indexes explizit MAXDOP = 1 verwenden, wird der resultierende gruppierte Columnstore-Index nach Spalte C1 sortiert. Bei Angabe von MAXDOP = 8 können Sie eine Überlappung der Werte über acht Zeilengruppen beobachten. Ein häufiges Szenario für diese Strategie, wenn Sie zu Beginn einen Columnstore-Index mit großer Datenmenge erstellen. Beachten Sie bei einem nicht gruppierten Columnstore-Index (NCCI), dass die grundlegende Rowstore-Tabelle über einen gruppierten Index verfügt. Die Zeilen sind bereits sortiert. In diesem Fall wird der resultierende Columnstore-Index automatisch sortiert. Beachten Sie unbedingt Folgendes: Der Columnstore-Index behält die Reihenfolge der Zeilen nicht inhärent bei. Wenn neue Zeilen eingefügt oder ältere Zeilen aktualisiert werden, müssen Sie den Vorgang ggf. wiederholen, da die Abfrageleistung der Analyse abnehmen kann.
Nutzen Sie die Tabellenpartitionierung. Sie können den Columnstore-Index partitionieren und dann durch Entfernen der Partition die Anzahl der zu scannenden Zeilengruppen reduzieren. In einer Faktentabelle werden beispielsweise die Einkäufe von Kunden gespeichert. Anhand eines allgemeinen Abfragemusters lassen sich die Einkäufe eines bestimmten Kunden in einem Quartal ermitteln. In diesem Fall können Sie die Einfügereihenfolge mit der Partitionierung für die Spalte „Customer“ kombinieren. Jede Partition enthält zeitlich sortierte Zeilen für einen bestimmten Kunden. Sie sollten auch die Verwendung von Tabellenpartitionierung in Betracht ziehen, wenn Daten aus dem Columnstore entfernt werden müssen. Das Auslagern und Abschneiden von Partitionen, die nicht mehr benötigt werden, ist eine effiziente Strategie zum Löschen von Daten, ohne Fragmentierung zu generieren, die durch kleinere Zeilengruppen eingeführt wird.
Vermeiden Sie das Löschen großer Datenmengen. Das Entfernen von komprimierten Zeilen aus einer Zeilengruppe ist kein synchroner Vorgang. Es wäre aufwendig, eine Zeilengruppe zu dekomprimieren, die Zeile zu löschen und sie dann erneut zu komprimieren. Wenn Sie also Daten aus komprimierten Zeilengruppen löschen, werden diese Zeilengruppen weiterhin überprüft, auch wenn sie weniger Zeilen zurückgeben. Wenn die Anzahl der gelöschten Zeilen für mehrere Zeilengruppen groß genug ist, damit diese in weniger Zeilengruppen zusammengeführt werden können, erhöht die Neuorganisation des Columnstore die Qualität des Indexes, und die Abfrageleistung wird verbessert. Wenn bei der Datenlöschung normalerweise ganze Zeilengruppen entfallen, sollten Sie die Verwendung von Tabellenpartitionierung, das Auslagern von Partitionen, die nicht mehr benötigt werden, und das Abschneiden von Zeilen anstelle einer Löschung in Betracht ziehen.

Hinweis

Ab SQL Server 2019 (15.x) wird der Tupelverschiebungsvorgang von einem Mergetask im Hintergrund unterstützt, der automatisch kleinere OPEN-Deltazeilengruppen komprimiert, die für einen bestimmten Zeitraum vorhanden waren (wie durch einen internen Schwellenwert festgelegt), oder COMPRESSED-Zeilengruppen zusammenführt, aus denen eine große Anzahl von Zeilen gelöscht wurde. Dies verbessert die Qualität des Columnstore-Index im Lauf der Zeit.
Wenn das Löschen von großen Datenmengen aus dem Columnstore-Index erforderlich ist, empfiehlt es sich, diesen Vorgang nach und nach in kleinere Löschbatches aufzuteilen. Dies ermöglicht es dem Mergetask im Hintergrund, kleinere Zeilengruppen zu mergen und die Indexqualität zu verbessern, sodass nach dem Löschen von Daten keine Wartungsfenster für Indexumstrukturierung vorgesehen werden müssen.
Weitere Informationen zu Columnstore-Begriffen und -Konzepten finden Sie unter Columnstore-Indizes: Überblick

2. Planen Sie ausreichend Arbeitsspeicher für eine parallele Erstellung von Columnstore-Indizes ein

Bei der Erstellung eines Columnstore-Indexes handelt es sich standardmäßig um einen parallel ausgeführten Vorgang, sofern der verfügbare Arbeitsspeicher nicht eingeschränkt ist. Die parallele Indexerstellung erfordert mehr Arbeitsspeicher als die serielle Erstellung des Index. Wenn ausreichend Arbeitsspeicher verfügbar ist, dauert das Erstellen eines Columnstore-Indexes 1,5-mal so lange wie das Erstellen einer B-Struktur für die gleichen Spalten.

Der Speicherplatz, der für das Erstellen eines Columnstore-Indexes erforderlich ist, hängt von der Anzahl von Spalten, der Anzahl der Zeichenfolgenspalten, dem Grad der Parallelität (Degree of Parallelism, DOP) und von den Eigenschaften der Daten ab. Wenn die Tabelle beispielsweise weniger als 1 Million Zeilen aufweist, verwendet SQL Server nur einen Thread, um den Columnstore-Index zu erstellen.

Wenn die Tabelle mehr als eine Million Zeilen aufweist, SQL Server aber keine ausreichend dimensionierte Speicherzuweisung abrufen kann, um den Index mit MAXDOP zu erstellen, verringert SQL Server MAXDOP automatisch nach Bedarf, um es auf den verfügbaren Arbeitsspeicher zu beschränken. In bestimmten Fällen muss DOP auf eins verringert werden, um den Index mit eingeschränktem Arbeitsspeicher zu erstellen.

Ab SQL Server 2016 (13.x) wird die Abfrage immer im Batchmodus ausgeführt. In früheren Versionen wird die Batchausführung nur verwendet, wenn DOP größer als 1 ist.

Erläuterungen zur Columnstore-Leistung

Columnstore-Indizes erzielen eine hohe Abfrageleistung durch die Kombination der Hochgeschwindigkeits-In-Memory-Modusbatchverarbeitung mit Techniken, die E/A-Anforderungen erheblich reduzieren. Da bei analytischen Abfragen eine große Anzahl von Zeilen gescannt werden, sind diese in der Regel E/A-gebunden, sodass eine E/A-Reduzierung während der Abfrageausführung maßgeblich für das Design der Columnstore-Indizes ist. Sobald die Daten in den Arbeitsspeicher gelesen wurden, ist es wichtig, dass die Anzahl der In-Memory-Vorgänge reduziert wird.

Columnstore-Indizes reduzieren die E/A-Vorgänge und optimieren die In-Memory-Vorgänge mithilfe einer hohen Datenkomprimierung sowie der Columnstore-Löschung, der Löschung von Zeilengruppen und der Batchverarbeitung.

Datenkomprimierung

Columnstore-Indizes erzielen eine bis zu 10 Mal höhere Datenkomprimierung als Rowstore-Indizes. Dadurch werden die zum Ausführen der Analyseabfragen erforderlichen E/A-Vorgänge erheblich verringert, wodurch die Abfrageleistung verbessert wird.

Columnstore-Indizes lesen komprimierte Daten vom Datenträger, was bedeutet, dass weniger Datenbytes in den Arbeitsspeicher gelesen werden müssen.
Columnstore-Indizes speichern Daten in komprimierter Form im Arbeitsspeicher, wodurch E/A-Vorgänge reduziert werden, da die Häufigkeit der Lesevorgänge der gleichen Daten in den Arbeitsspeicher verringert wird. Beispielsweise können Columnstore-Indizes bei zehnfacher Komprimierung zehnmal mehr Daten im Arbeitsspeicher aufbewahren als bei der Speicherung der Daten in unkomprimierter Form. Wenn sich mehr Daten im Arbeitsspeicher befinden, ist es wahrscheinlicher, dass der Columnstore-Index die benötigten Daten im Arbeitsspeicher findet, ohne dass zusätzliche Lesevorgänge vom Datenträger anfallen.
Columnstore-Indizes komprimieren Daten nach Spalten anstatt nach Zeilen, wodurch hohe Komprimierungsraten erzielt und die Größe der auf dem Datenträger gespeicherten Daten reduziert werden. Jede Spalte wird separat komprimiert und gespeichert. Daten in einer Spalte haben immer den gleichen Datentyp und tendenziell auch ähnliche Werte. Die Datenkomprimierungstechniken sind sehr gut, um höhere Komprimierungsraten zu erreichen, wenn die Werte ähnlich sind.
Wenn eine Faktentabelle beispielsweise Kundenadressen und eine Spalte für das Land/die Region enthält, beträgt die Gesamtzahl der möglichen Werte weniger als 200. Einige dieser Werte werden mehrmals wiederholt. Wenn die Faktentabelle 100 Millionen Zeilen enthält, lässt sich die Länder-/Regionsspalte problemlos komprimieren und erfordert nur sehr wenig Speicherplatz. Eine zeilenweise Komprimierung kann auf diese Weise nicht von der Ähnlichkeit der Spaltenwerte profitieren. Daher werden hierbei mehr Bytes verwendet, um die Werte in der Länder-/Regionsspalte zu komprimieren.

Spaltenlöschung

Columnstore-Indizes überspringen den Lesevorgang von Spalten, die für das Ergebnis der Abfrage nicht erforderlich sind. Durch die sogenannte Spaltenlöschung werden die E/A-Vorgänge für die Abfrageausführung weiter reduziert, wodurch die Abfrageleistung verbessert wird.

Die Spaltenlöschung ist möglich, da die Daten nach Spalten organisiert und komprimiert sind. Im Gegensatz dazu werden beim zeilenweisen Speichern von Daten die Werte der einzelnen Zeilen physisch zusammen gespeichert und können nicht problemlos getrennt werden. Der Abfrageprozessor muss eine ganze Zeile einlesen, um bestimmte Spaltenwerte abrufen zu können, wodurch die Zahl der E/A-Vorgänge erhöht wird, da zusätzliche Daten unnötigerweise in den Arbeitsspeicher gelesen werden.
Wenn eine Tabelle beispielsweise 50 Spalten hat und die Abfrage nur 5 dieser Spalten verwendet, ruft der Columnstore-Index nur die 5 Spalten vom Datenträger ab. Das Einlesen der anderen 45 Spalten wird übersprungen. Dadurch werden die E/A-Vorgänge um weitere 90 % reduziert, vorausgesetzt, dass alle Spalten eine ähnliche Größe aufweisen. Wenn die gleichen Daten in einer Zeilengruppe gespeichert sind, muss der Abfrageprozessor die zusätzlichen 45 Spalten lesen.

Zeilengruppenlöschung

Bei vollständigen Tabellenscans entspricht ein großer Prozentsatz der Daten in der Regel nicht den Abfrageprädikatskriterien. Mithilfe von Metadaten kann der Columnstore-Index das Einlesen der Zeilengruppen überspringen, die keine für das Abfrageergebnis erforderlichen Daten enthalten. Dabei werden keine tatsächlichen E/A-Vorgänge durchgeführt. Durch die sogenannte Zeilengruppenlöschung werden die E/A-Vorgänge für vollständige Tabellenscans weiter reduziert, wodurch die Abfrageleistung verbessert wird.

Wann muss ein Columnstore-Index einen vollständigen Tabellenscan durchführen?

Ab SQL Server 2016 (13.x) können Sie einen oder mehrere reguläre nicht gruppierte B-Strukturindizes für einen gruppierten Columnstore-Index genauso wie für einen Rowstore-Heap erstellen. Die nicht gruppierten B-Strukturindizes können eine Abfrage mit einem Gleichheitsprädikat oder einem Prädikat mit einem kleinen Wertebereich beschleunigen. Bei komplexeren Prädikaten kann der Abfrageoptimierer sich für einen vollständigen Tabellenscan entscheiden. Ohne die Fähigkeit, Zeilengruppen zu überspringen, wäre ein vollständiger Tabellenscan sehr zeitaufwändig, insbesondere bei großen Tabellen.

Wann profitiert eine Analyseabfrage von einer Zeilengruppenlöschung für einen vollständigen Tabellenscan?

Ein Einzelhandelsunternehmen hat beispielsweise seine Vertriebsdaten mithilfe einer Faktentabelle mit gruppiertem Columnstore-Index modelliert. Bei jedem neuen Verkauf werden verschiedene Attribute der Transaktion gespeichert, einschließlich des Verkaufsdatums eines Produkts. Obwohl Columnstore-Indizes keine sortierte Reihenfolge sicherstellen, werden die Zeilen in dieser Tabelle interessanterweise nach Datum sortiert geladen. Mit der Zeit wächst diese Tabelle. Auch wenn das Einzelhandelsunternehmen Verkaufsdaten der letzten 10 Jahre speichert, muss bei einer Analyseabfrage nur ein Aggregat für das letzte Quartal berechnet werden. Mit Columnstore-Indizes können Sie es vermeiden, auf die Daten der vorherigen 39 Quartale zuzugreifen, indem nur die Metadaten für die Datumsspalte untersucht werden. Dies entspricht einer zusätzlichen Reduzierung der Datenmenge, die in den Arbeitsspeicher gelesen und verarbeitet wird, von 97 %.

Welche Zeilengruppen werden bei einem vollständigen Tabellenscan übersprungen?

Um zu bestimmen, welche Zeilengruppen gelöscht werden sollen, verwendet der Columnstore-Index Metadaten, um die Mindest- und Maximalwerte jedes Spaltensegments für jede Zeilengruppe zu speichern. Wenn keiner der Spaltensegmentbereiche die Kriterien für Abfrageprädikate erfüllt, wird die gesamte Zeilengruppe übersprungen, ohne tatsächliche E/A-Vorgänge auszuführen. Dies funktioniert, da die Daten in der Regel in sortierter Reihenfolge geladen werden, und auch wenn eine Sortierung der Zeilen nicht garantiert werden kann, befinden sich ähnliche Datenwerte häufig innerhalb derselben Zeilengruppe oder in einer benachbarten Zeilengruppe.

Weitere Informationen über Zeilengruppen finden Sie unter Richtlinien zum Entwerfen von Columnstore-Indizes.

Batchmodusausführung

Bei der Batchmodusausführung handelt es sich um die gemeinsame Verarbeitung eines Rowsets, in der Regel bis zu 900 Zeilen, aus Gründen der Ausführungseffizienz. Die Abfrage SELECT SUM (Sales) FROM SalesData aggregiert beispielsweise den Gesamtumsatz aus der Tabelle „SalesData“. Bei der Batchmodusausführung berechnet die Abfrageausführungs-Engine das Aggregat in Gruppen von 900 Werten. Dadurch werden Metadaten, Zugriffskosten und andere Aufwandsarten auf alle Zeilen in einem Batch verteilt, anstatt die Kosten für jede Zeile zu zahlen, wodurch der Codepfad erheblich reduziert wird. Bei der Batchmodusverarbeitung kommen, sofern möglich, komprimierte Daten zum Einsatz. Zugleich werden einige der Exchange-Operatoren beseitigt, die bei der Zeilenmodusverarbeitung verwendet werden. Dies beschleunigt die Ausführung von Analyseabfragen in beträchtlichem Maße.

Nicht alle Abfrageausführungsoperatoren können im Batchmodus ausgeführt werden. DML-Vorgänge, wie z. B. Einfügen, Löschen oder Aktualisieren, werden z. B. Zeile für Zeile ausgeführt. Batchmodusoperatoren richten sich an Operatoren, um die Abfrageleistung wie Scan, Join, Aggregate, Sort und so weiter zu beschleunigen. Da der Columnstore-Index in SQL Server 2012 (11.x) eingeführt wurde, gibt es eine nachhaltige Initiative, um die Operatoren zu erweitern, die im Batchmodus ausgeführt werden können. Die folgende Tabelle führt die Operatoren auf, die im Batchmodus gemäß der Produktversion ausgeführt werden.

Batchmodusoperatoren	Einsatz	SQL Server 2012 (11.x)	SQL Server 2014 (12.x)	SQL Server 2016 (13.x) und SQL-Datenbank¹	Kommentare
DML-Vorgänge (Insert, Delete, Update, Merge)		Nein	Nein	Nein	DML ist kein Batchmodusvorgang, da es nicht parallel ist. Auch wenn die serielle Batchmodusverarbeitung aktiviert wird, kommt es zu keiner maßgeblichen Leistungssteigerung, wenn DML im Batchmodus verarbeitet wird.
Columnstore Index Scan	SCAN	Nicht verfügbar	ja	ja	Bei Columnstore-Indizes kann das Prädikat mittels Push an den SCAN-Knoten übertragen werden.
Columnstore-Indexscan (nicht gruppiert)	SCAN	ja	Ja	Ja	ja
Index Seek		Nicht verfügbar	Nicht verfügbar	Nein	Es wird ein Suchvorgang im Zeilenmodus durch einen nicht gruppierten B-Strukturindex durchgeführt.
Compute Scalar	Ausdruck, dessen Auswertung einen Skalarwert ergibt.	ja	Ja	ja	Es gibt jedoch einige Einschränkungen hinsichtlich des Datentyps. Dies gilt für alle Batchmodusoperatoren.
Verkettung	UNION und UNION ALL	Nein	ja	ja
filter	Anwenden von Prädikaten	ja	Ja	ja
Hash Match	Hashbasierte Aggregatfunktionen, äußerer Hashjoin, rechter Hashjoin, linker Hashjoin, rechter innerer Join, linker innerer Join	ja	Ja	ja	Einschränkungen für die Aggregation: keine Mindest-/Maximalwerte für Zeichenfolgen. Verfügbare Aggregationsfunktionen: sum/count/avg/min/max. Einschränkungen für Join: keine nicht übereinstimmenden Typ-Joins für nicht ganzzahlige Typen.
Merge Join		Nein	Nein	Nein
Multithread-Abfragen		ja	Ja	ja
Nested Loops		Nein	Nein	Nein
Singlethread-Abfragen unter MAXDOP 1		Nein	nein	ja
Singlethread-Abfragen mit einem seriellen Abfrageplan		Nein	nein	ja
Sortieren	Order by-Klausel für SCAN mit Columnstore-Index	Nein	nein	ja
Top Sort		Nein	nein	ja
Window Aggregates		Nicht verfügbar	Nicht verfügbar	ja	Neuer Operator in SQL Server 2016 (13.x).

¹ Gilt für SQL Server 2016 (13.x), SQL-Datenbank Premium-Ebenen, Standardebenen – S3 und höher sowie alle vCore-Ebenen und das Analyseplattformsystem (PDW)

Weitere Informationen finden Sie im Handbuch zur Architektur der Abfrageverarbeitung.

Aggregatweitergabe

Ein normaler Ausführungspfad zur Aggregatberechnung, um die qualifizierenden Zeilen aus dem SCAN-Knoten abzurufen und die Werte im Batchmodus zu aggregieren. Dadurch wird eine gute Leistung bereitgestellt. Ab SQL Server 2016 (13.x) kann der Aggregatvorgang jedoch mittels Push an den SCAN-Knoten weitergegeben werden, um die Leistung der Aggregatberechnung in erheblichem Maße zusätzlich zur Ausführung im Batchmodus zu verbessern, sofern folgende Bedingungen erfüllt sind:

Bei den Aggregaten handelt es sich um MIN, MAX, SUM, COUNT und COUNT(*).
Der Aggregatoperator muss sich über dem SCAN-Knoten oder über dem SCAN-Knoten mit GROUP BY befinden.
Dieses Aggregat ist kein eindeutiges Aggregat.
Die Aggregatspalte ist keine Zeichenfolgenspalte.
Die Aggregatspalte ist keine virtuelle Spalte.
Der Datentyp für die Eingabe und Ausgabe muss einer der folgenden sein und in 64 Bit passen:
- tinyint, int, bigint, smallint, bit
- smallmoney, money, decimal und numeric mit einer Genauigkeit von <= 18
- smalldate, date, datetime, datetime2, time

Die Aggregatweitergabe wird beispielsweise in den beiden folgenden Abfragen durchgeführt:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Zeichenfolgenprädikatweitergabe

Beim Entwurf eines Data Warehouse-Schemas besteht die empfohlene Schemamodellierung darin, ein Sternschema oder Schneeflockenschema zu verwenden, das aus einer oder mehreren Faktentabellen und vielen Dimensionstabellen besteht. Die Faktentabelle speichert die Unternehmensmessungen oder -transaktionen, und die Dimensionstabelle speichert die Dimensionen, anhand derer die Fakten analysiert werden müssen.

Bei einem Fakt kann es sich beispielsweise um einen Datensatz für den Verkauf eines bestimmten Produkts in einer bestimmten Region handeln, während die Dimension eine Reihe von Regionen, Produkten usw. darstellt. Die Fakten- und Dimensionstabellen sind über eine Primär-/Fremdschlüsselbeziehung miteinander verbunden. Die am häufigsten verwendeten Abfragen verbinden eine oder mehrere Dimensionstabellen mit der Faktentabelle.

Betrachten Sie z.B. eine Dimensionstabelle namens Products. Ein typischer Primärschlüssel wäre ProductCode, der in der Regel als Zeichenfolgendatentyp dargestellt wird. Für die Abfrageleistung hat es sich bewährt, einen Ersatzschlüssel zu erstellen (in der Regel eine Spalte mit ganzen Zahlen), um aus der Faktentabelle auf die Zeile in der Dimensionstabelle zu verweisen.

Der Columnstore-Index führt die Analyseabfragen mit Joins/Prädikaten mit Schlüsseln auf numerischer Basis bzw. Ganzzahlbasis sehr effizient aus. Bei vielen Kundenworkloads wurden jedoch zeichenfolgenbasierte Spalten verwendet, die Fakt-/Dimensionstabellen verknüpfen. Dies führte dazu, dass die Abfrageleistung mit Columnstore-Indizes nicht gut war. SQL Server 2016 (13.x) verbessert die Leistung von Analyseabfragen mit zeichenfolgenbasierten Spalten erheblich, indem die Prädikate mit Zeichenfolgenspalten an den SCAN-Knoten weitergegeben werden.

Die Weitergabe von Zeichenfolgenprädikaten nutzt zur Verbesserung der Abfrageleistung das primäre bzw. sekundäre Wörterbuch, das für die Spalten erstellt wurde. Nehmen Sie z. B. ein Zeichenfolgenspaltensegment in einer Zeilengruppe, bestehend aus 100 unterschiedlichen Zeichenfolgenwerten. Das bedeutet, dass bei einer Million Zeilen auf jeden einzelnen Zeichenfolgenwert durchschnittlich 10.000 Mal verwiesen wird.

Bei der Zeichenfolgenprädikatweitergabe berechnet die Abfrageausführung das Prädikat anhand der Werte im Wörterbuch. Wenn sich dies qualifiziert, werden alle Zeilen mit Bezug auf den Wörterbuchwert automatisch qualifiziert. Dies verbessert die Leistung auf zwei Arten:

Es wird nur die qualifizierte Zeile zurückgegeben, wodurch die Anzahl der Zeilen reduziert wird, die aus dem SCAN-Knoten übertragen werden müssen.
Die Anzahl von Zeichenfolgenvergleichen wird maßgeblich verringert. In diesem Beispiel sind nur 100 Zeichenfolgenvergleiche gegenüber einer Millionen Vergleiche erforderlich. Wie im Folgenden beschrieben gibt es einige Einschränkungen:
- Keine Zeichenfolgenprädikatweitergabe für Deltazeilengruppen. Es gibt kein Wörterbuch für Spalten in Deltazeilengruppen.
- Keine Weitergabe von Zeichenfolgenprädikaten, wenn die Einträge im Wörterbuch eine Größe von 64 KB überschreiten.
- Ausdrücke, die als NULL-Werte ausgewertet werden, werden nicht unterstützt.

Segmenteliminierung

Datentypauswahlen haben möglicherweise erhebliche Auswirkungen auf die Abfrageleistung basierend auf allgemeinen Filterprädikaten für Abfragen im Columnstore-Index.

In Columnstore-Daten bestehen Zeilengruppen aus Spaltensegmenten. Es gibt Metadaten für jedes Segment, damit Segmente, ohne sie zu lesen, schnell eliminiert werden können. Diese Segmentlöschung wird auf numerische, Datums- und Uhrzeitdatentypen und den Datentyp „datetimeoffset“ angewendet, wobei der Datentyp „Datetimeoffset“ kleiner oder gleich zwei skaliert wird. Ab SQL Server 2022 (16.x) werden die Funktionen zur Segmentlöschung auf Zeichenfolgen, binäre, guid-Datentypen und den Datentyp „datetimeoffset“ für die Skalierung größer als zwei erweitert.

Nach dem Upgrade auf eine Version von SQL Server, die die Eliminierung von Zeichenfolgen min/max (SQL Server 2022 (16.x) und höher unterstützt, optimiert der Columnstore-Index dieses Feature erst, wenn es mit NEUERSTELLUNG oder DROP/CREATE neu erstellt wird.

Die Segmenteliminierung gilt nicht für LOB-Datentypen, z. B. die (max.) Länge des Datentyps.

Derzeit unterstützen nur SQL Server 2022 (16.x) und höher für gruppierte Columnstore-Indizes die Zeilengruppenlöschung für das Präfix von LIKE-Prädikaten, z. B. column LIKE 'string%'. Die Segmenteliminierung wird für die Verwendung von LIKE ohne Präfix wie z. B. column LIKE '%string' nicht unterstützt.

In Azure Synapse Analytics und ab SQL Server 2022 (16.x) können Sie geordnete gruppierte Columnstore-Indizes erstellen, die das Sortieren nach Spalten ermöglichen, um die Segmenteliminierung zu unterstützen, insbesondere für Zeichenkettenspalten. In geordneten gruppierten Columnstore-Indizes ist die Segmenteliminierung für die erste Spalte im Indexschlüssel am effektivsten, da sie sortiert ist. Leistungsgewinne aufgrund der Segmenteliminierung bei anderen Spalten in der Tabelle sind weniger vorhersagbar. Weitere Informationen zu sortierten gruppierten Columnstore-Indizes finden Sie unter Verwenden eines sortierten gruppierten Columnstore-Indexes für große Data Warehouse-Tabellen.

Mit der Abfrageverbindungsoption SET STATISTICS IO können Sie die Segmenteliminierung in Aktion ansehen. Suchen Sie nach der Ausgabe, z. B. der folgenden, um anzugeben, dass die Segmenteliminierung erfolgte. Zeilengruppen bestehen aus Spaltensegmenten, sodass dies auf eine Segmenteliminierung hinweisen kann. Im folgenden SET STATISTICS IO-Ausgabebeispiel für eine Abfrage wurden von der Abfrage ungefähr 83 % der Daten übersprungen:

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

Freigeben über