Was ist die Anatomie eines Columnstore-Index?

Eine der neuen Funktionen in SQL Server 2012 mit Codenamen Denaliist der Columnstore-Index.

Ich weiß einiges über reguläre alte Zeilenspeicherindizes, wie die B-Tree-Struktur, Speicherunterschiede zwischen Blattebene und B-Tree-Seiten, Auswirkungen eingeschlossener Felder, Optimierung ihrer Verwendung, Reihenfolge der Schlüssel usw.

Ich habe Schwierigkeiten, gute Informationen über die Interna eines Columnstore-Index zu erhalten.

Wie ist es aufgebaut?
Gibt es einen B-Baum? Eine andere Struktur?
Wie sind Daten organisiert?
Welche speziellen Operatoren eignen sich am besten für die Verwendung?
Gibt es noch andere Anti-Patterns, die bei der Verwendung vermieden werden sollten?

Vieles, was ich über sie herausfinden kann, ist im Grunde das genaue Gegenteil eines "normalen" Index, dh keine Reihenfolge der Schlüssel, keine eingeschlossenen Felder, NUR nicht gruppiert.

Beliebige Einsichten sind willkommen.

— JNK
quelle

Auf der Wikipedia-Seite gibt es eine Menge Fanout zu technischen Implementierungen von Column-Store-Datenbanken. Ich stelle mir vor, der Index ist nur eine Spaltenspeicher-Datenstruktur für eine einzelne Spalte zusammen mit ihren Schlüsseln. Möglicherweise wird ein Bitmap-Index verwendet, möglicherweise ein BTree.

— ConcernedOfTunbridgeWells

Es ist eigentlich für mehrere Spalten. Ich gehe auch davon aus, dass es wie bei anderen SS-Implementierungen ein wenig anders sein wird als bei anderen Produkten

— JNK

Für MySQL gilt aber das Gleiche: developer.bazaarvoice.com/why-columns-are-cool Auch Sybase IQ ist der

— Urvater

@ConcernedOfTunbridgeWells - Verwenden Columnstore-Indizes Bitmap-Indizes? Nein. Columnstore-Indizes verwenden eine proprietäre Datendarstellung basierend auf Vertipaq. Es ist nicht dasselbe wie ein Bitmap-Index und verwendet keinen. Es hat jedoch einige ähnliche Vorteile wie Bitmap-Indizes, z. B. die Reduzierung der Zeit, die zum Filtern einer Spalte mit einer kleinen Anzahl unterschiedlicher Werte benötigt wird.

— Martin Smith

Remus Rusanu, ein Mitglied des Microsoft-Teams, das diese Funktion entwickelt hat, hat gerade einen Beitrag

— Nick Chammas

Columnstore-Struktur

Columnstore-Daten werden physisch in einem oder mehreren Segmenten (regulären LOB-Zuordnungseinheiten) pro Spalte gespeichert und können auch auf die übliche Weise partitioniert werden. Jedes Segment enthält ungefähr eine Million Zeilen mit hochkomprimierten Werten oder Wertereferenzen (verschiedene Komprimierungstechniken sind verfügbar). Ein Wertverweis verweist auf einen Eintrag in einem von bis zu zwei Hash-Wörterbüchern .

Wörterbücher werden während der Abfrageausführung im Speicher abgelegt , wobei Datenwert-IDs aus dem Segment immer dann im Wörterbuch gesucht werden, wenn die Ausführung den tatsächlichen Datenwert erfordert (diese Suche wird aus Leistungsgründen so lange wie möglich zurückgestellt).

Segmente haben auch einen Kopfdatensatz, der Metadaten wie die im Segment gespeicherten Minimal- und Maximalwerte enthält. Informationen aus dem Header können häufig verwendet werden, um vollständige Partitionen zur Ausführungszeit von der Verarbeitung auszuschließen. Header-Datensatzinformationen werden in der üblichen LOB-Datenstammstruktur gespeichert. Wenn Sie also ein Segment entfernen, kann die Storage Engine das Lesen der LOB-Datenseiten aus dem physischen Speicher vollständig überspringen. Die Maximierung des Eliminierungspotenzials kann sorgfältiges Design erfordern , einschließlich einer Abhängigkeit von der Clustered-Index-Reihenfolge zum Zeitpunkt der Erstellung des Columnstore-Index.

Spezifische Planbetreiber

SQL Server 2012 führt einen neuen Ausführungsmodus ein, der als Stapelmodus bezeichnet wird. In diesem Modus werden Pakete mit ungefähr 1000 Zeilen zwischen Operatoren übertragen, wodurch die Prozessorauslastung erheblich verbessert wird. In jedem Paket werden Spaltendaten als Vektor dargestellt. Nicht alle Planoperatoren unterstützen den Batch-Modus. Beispiele hierfür sind Columnstore-Index-Scan, Hash-Inner-Join, Batch-Hash-Tabellenerstellung, Bitmap-Filter, Hash-Aggregat (keine skalaren Aggregate), Filter und Compute-Scalar (für Projektion und Ausdruck) Auswertung). Die Ausführungspläne für Abfragen wurden erweitert, um den geschätzten und den tatsächlichen Ausführungsmodus anzuzeigen.

Anti-Patterns

In der ersten Version gibt es eine große Anzahl von Einschränkungen, einschließlich Einschränkungen für zulässige Datentypen . Die meisten gängigen Typen werden unterstützt. nicht unterstützte Datentypen umfassen DECIMALmit einer Genauigkeit von mehr als 18 Stellen, (N)VARCHAR(MAX), UNIQUEIDENTIFIER, CLR - Typen und (VAR)BINARY.

Verwendung von Abkürzungen , OUTER JOIN, IN,EXISTS , NOT IN, OR, dazu UNION ALLführen kann , erheblich reduziert Leistung (Row Modusausführung), es sei denn , Abhilfen eingesetzt werden , dass typischerweise ungewöhnliche Syntax umschreibt beteiligt ist, wie in den verknüpften Einträgen in diesem Abschnitt dargestellt.

Mehr Informationen

Remus Rusanu hat einen großen Überblick gebloggt hier .

— Paul White
quelle