Guide d'architecture

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

sql

C 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

sql

Ce 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

sql

Le 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.

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.

© 2026 - Ryware.