Quelle est l'anatomie d'un index columnstore?

L'une des nouvelles fonctionnalités du nom de code de SQL Server 2012 Denaliest l' index Columnstore.

Je connais bien les anciens index de magasin de lignes classiques, comme la structure de l'arbre b, les différences de stockage entre le niveau feuille et les pages arbre b, les effets des champs inclus, l'optimisation de leur utilisation, l'ordre des clés, etc.

J'ai du mal à obtenir de bonnes informations sur les éléments internes d'un index columnstore.

Comment est-il structuré?
Y a-t-il un arbre b? Une autre structure en place?
Comment les données sont-elles organisées?
Quels types d'opérateurs spécifiques sont les mieux adaptés pour l'utiliser?
Y a-t-il d'autres anti-motifs à éviter lors de leur utilisation?

Beaucoup de ce que je peux en savoir est fondamentalement l'opposé exact d'un index "normal", c'est-à-dire pas de classement des clés, pas de champs inclus, non clusterisé UNIQUEMENT.

Toutes les idées sont appréciées.

— JNK
source

Il y a beaucoup de fanout sur les implémentations techniques des bases de données de magasin de colonnes sur la page wikipedia. J'imagine que l'index est juste une structure de données de stockage de colonnes pour une seule colonne avec ses clés. Peut-être qu'il utilise un index bitmap, peut-être un BTree.

— ConcernedOfTunbridgeWells

C'est en fait pour plusieurs colonnes. Je suppose également que, comme pour les autres implémentations SS, ce sera un peu différent des autres produits

— JNK

Pour MySQL, mais la même chose s'applique: developer.bazaarvoice.com/why-columns-are-cool Aussi Sybase IQ est le grand-papa

— gbn

@ConcernedOfTunbridgeWells - Les index columnstore utilisent-ils des index bitmap? Non. Les index Columnstore utilisent une représentation de données propriétaire basée sur Vertipaq. Ce n'est pas la même chose qu'un index bitmap et n'en utilise pas. Mais il présente des avantages similaires aux index bitmap, tels que la réduction du temps nécessaire pour filtrer sur une colonne avec un petit nombre de valeurs distinctes.

— Martin Smith

Remus Rusanu, membre de l'équipe Microsoft qui a développé cette fonctionnalité, vient de publier un article à ce sujet: Inside the SQL Server 2012 COLUMNSTORE Indexes

— Nick Chammas

Structure du magasin de colonnes

Les données du magasin de colonnes sont physiquement stockées dans un ou plusieurs segments (unités d'allocation LOB régulières) par colonne, et peuvent également être partitionnées de la manière habituelle. Chaque segment contient environ un million de lignes de valeurs hautement compressées ou de références de valeurs (plusieurs techniques de compression sont disponibles). Une référence de valeur renvoie à une entrée dans l'un des deux dictionnaires de hachage .

Les dictionnaires sont épinglés en mémoire pendant l'exécution de la requête, les ID de valeur de données du segment étant consultés dans le dictionnaire chaque fois que l'exécution nécessite la valeur de données réelle (cette recherche est différée aussi longtemps que possible pour des raisons de performances).

Les segments ont également un enregistrement d'en-tête contenant des métadonnées telles que les valeurs minimale et maximale stockées dans le segment. Les informations de l'en-tête peuvent souvent être utilisées pour éliminer les partitions complètes du traitement au moment de l'exécution. Les informations d'enregistrement d'en-tête sont stockées dans la structure racine de données LOB habituelle, donc l'élimination d'un segment signifie que le moteur de stockage peut ignorer complètement la lecture des pages de données LOB à partir du stockage physique. La maximisation du potentiel d'élimination peut nécessiter une conception soignée , notamment une dépendance à l' égard de l'ordre des index clusterisés au moment de la création de l'index Columnstore.

Opérateurs de plans spécifiques

SQL Server 2012 introduit un nouveau mode d'exécution appelé mode batch. Dans ce mode, des paquets d'environ 1000 lignes sont transmis entre les opérateurs, améliorant considérablement l'efficacité d'utilisation du processeur. Dans chaque paquet, les données en colonnes sont représentées comme un vecteur. Tous les opérateurs de plan ne prennent pas en charge le fonctionnement en mode batch, mais des exemples de ceux qui incluent l'analyse d'index Columnstore, la jointure interne de hachage, la construction de table de hachage par lots, le filtre bitmap, l'agrégat de hachage (pas les agrégats scalaires ), le filtre et le calcul scalaire (pour la projection et l'expression) évaluation). Les plans d'exécution des requêtes ont été améliorés pour afficher le mode d'exécution estimé et réel.

Anti-Patterns

Il existe un grand nombre de restrictions dans la première version, notamment des contraintes sur les types de données autorisés . Les types les plus courants sont pris en charge; les types de données non pris en charge incluentDECIMAL avec une plus grande précision de 18 chiffres, (N)VARCHAR(MAX), UNIQUEIDENTIFIER, types CLR, et (VAR)BINARY.

L' utilisation de types de chaînes , OUTER JOIN, IN,EXISTS , NOT IN, OR,UNION ALL peut entraîner des performances significativement réduite (exécution en mode ligne), à moins que des solutions de contournement sont employés qui impliquent généralement réécritures inhabituelles de syntaxe comme indiqué dans les articles liés à cette section.

Plus d'information

Remus Rusanu a blogué un excellent aperçu ici .

— Paul White
source