Index columnstore SQL Server : guide pratique
Columnstore peut transformer de grosses charges analytiques, mais il ne remplace pas universellement la conception rowstore. La vraie question n'est pas de savoir si columnstore est moderne. La vraie question est de savoir si la table et les schémas d'accès justifient ses compromis.
Pourquoi columnstore ressemble à une boîte noire
Beaucoup d'équipes découvrent columnstore via des benchmarks ou un projet data warehouse réussi puis le généralisent trop loin. Columnstore excelle pour compresser de gros jeux de données et scanner rapidement beaucoup de lignes pour l'analytique. Il est bien moins convaincant pour les singleton lookups, les chemins OLTP étroits ou les petites tables qui n'atteignent jamais une taille suffisante.
Point important : un clustered columnstore peut remplacer l'organisation clustered rowstore sur certaines tables analytiques, mais l'application de la clé primaire peut toujours nécessiter un index rowstore nonclustered.
Exemples de conception columnstore
Ces exemples montrent la difference pratique entre clustered et nonclustered columnstore, ainsi que la verification DMV utile apres chargement des donnees.
Creer un index clustered columnstore sur une table fact
sqlC est le schema classique de type warehouse lorsque scans et aggregations dominent la charge.
CREATE TABLE dbo.FactSales
(
SalesKey bigint NOT NULL,
OrderDateKey int NOT NULL,
CustomerKey int NOT NULL,
ProductKey int NOT NULL,
Quantity int NOT NULL,
NetAmount decimal(18,2) NOT NULL
);
CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSales
ON dbo.FactSales; Ajouter un index nonclustered columnstore a une table rowstore
sqlCe schema est utile quand l acces OLTP depend toujours du rowstore mais que le reporting profite d une projection analytique compressee.
CREATE TABLE dbo.SalesOrderDetail
(
SalesOrderDetailID bigint NOT NULL PRIMARY KEY,
SalesOrderID bigint NOT NULL,
ProductID int NOT NULL,
OrderQty int NOT NULL,
UnitPrice money NOT NULL,
ModifiedDate datetime2 NOT NULL
);
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_SalesOrderDetail_Analytics
ON dbo.SalesOrderDetail (SalesOrderID, ProductID, OrderQty, UnitPrice, ModifiedDate); Verifier la sante des rowgroups apres chargement
sqlLe succes de columnstore depend de la qualite des rowgroups, pas seulement de l existence de l index.
SELECT
OBJECT_NAME(object_id) AS table_name,
row_group_id,
state_desc,
total_rows,
deleted_rows,
size_in_bytes / 1024.0 / 1024.0 AS size_mb
FROM sys.dm_db_column_store_row_group_physical_stats
WHERE object_id = OBJECT_ID('dbo.FactSales')
ORDER BY row_group_id; Où chaque modèle d'indexation s'intègre
Clustered columnstore
Idéal pour les grandes tables de type fact dominées par les scans, les agrégations et les charges analytiques sensibles à la compression, où l'accès transactionnel ligne par ligne n'est pas dominant.
Nonclustered columnstore
Utile lorsqu'une table a encore besoin d'un comportement rowstore pour l'accès transactionnel principal, mais que les requêtes analytiques peuvent profiter d'une projection compressée en plus.
Rowstore traditionnel
Reste le bon choix par défaut pour de nombreuses tables OLTP dépendantes de prédicats sélectifs, de singleton lookups, de mises à jour chaudes ou d'une latence transactionnelle stable.
Patrons de conception pratiques
Tables fact orientées analytique
- - Considérez clustered columnstore lorsque scans et agrégations dominent
- - Alignez les chemins de chargement et le partitionnement avec le mouvement et la rétention des données
- - Mesurez la qualité des rowgroups et la compression après des charges réelles, pas seulement en staging
Tables mixtes opérationnelles et reporting
- - Gardez rowstore comme chemin principal lorsque les lookups transactionnels restent critiques
- - Ajoutez nonclustered columnstore de manière sélective pour accélérer le reporting
- - Validez le surcoût d'écriture et l'impact maintenance avant de généraliser le design
Cycle de vie et maintenance
- - Révisez partitionnement, tailles de lots et archivage ensemble
- - Confirmez que la stratégie d'index supporte toujours contraintes et requêtes opérationnelles
- - Traitez columnstore comme une partie du design de table, pas comme un simple bouton de tuning
Erreurs courantes avec columnstore
Utiliser columnstore sur de petites tables
Si la table est trop petite, le moteur profite peu de la compression et des scans. La complexité augmente alors que le gain reste faible.
Oublier les chemins d'accès ponctuels
Une table qui sert des lookups fréquents ou des seeks très sélectifs a souvent encore besoin d'une conception rowstore-first, même si des requêtes de reporting existent.
Ignorer les patterns de chargement
Mauvaises tailles de lots, mouvements de partitions maladroits ou schémas d'écriture intensifs peuvent dégrader les rowgroups et annuler le gain attendu.
Traitez columnstore comme une décision de workload
Columnstore est puissant lorsque la table se comporte comme un actif analytique : beaucoup de lignes, valeur de compression, gros scans et accès axés sur les agrégations. Il n'est pas automatiquement meilleur parce qu'il est plus récent ou parce qu'un benchmark le favorise.
Le bon design commence par les schémas d'accès, pas par des catégories marketing. Si la majorité des requêtes sont transactionnelles et sélectives, rowstore reste le choix le plus sûr. Si la table se comporte comme une fact table, columnstore mérite une vraie étude.
Articles SQL Server associés
Utilisez le guide performance pour les fondamentaux du tuning et le guide support pour la couverture opérationnelle.
Services de support DBA SQL Server
Ce que couvre un support DBA SQL Server managé, quand choisir une couverture continue et quelles lacunes opérationnelles créent le plus de risque.
Comment optimiser les performances SQL Server
Parcourez waits, statistiques, index, plans, TempDB et télémétrie opérationnelle dans le bon ordre.
FAQ
Quand utiliser un clustered columnstore index dans SQL Server ?
Il est généralement le plus pertinent sur de grandes tables analytiques ou de type data warehouse où les scans et agrégations dominent et où les lookups transactionnels ne sont pas la charge principale.
Un index columnstore peut-il remplacer un clustered index de clé primaire ?
Un clustered columnstore peut remplacer l'organisation clustered rowstore sur certaines tables, mais l'application de la clé primaire peut toujours nécessiter un index rowstore nonclustered.
Columnstore est-il meilleur que rowstore pour l'OLTP ?
En général non comme règle globale. Le rowstore traditionnel reste le meilleur défaut pour beaucoup de tables OLTP à cause des lookups sélectifs, des mises à jour fréquentes et des accès transactionnels prévisibles.