Les index de type columnstore sont introduit en SQL Server 2012.

Un index columnstore optimisé en mémoire xVelocity regroupe et stocke les données de chaque colonne, puis joint l'ensemble des colonnes pour remplir l'index tout entier. Cela diffère des index classiques qui regroupent et stockent les données de chaque ligne, puis joignent l'ensemble des lignes pour remplir l'index tout entier.

Je vous propose faire un simple test pour voir l’efficacité.

Est-il profitable de créer les index simples sur les colonnes des dimensions ? Afin de rentrer dans les détails je vous propose faire quelques tests simples.

Les particularités

Pour utiliser N index de la même table dans la même requête le moteur doit confronter (l'intersection en cas "AND") les N sous-ensembles au moyen de "Merge Join" (le coût O(n) environ), "Hash Match" (le coût O(n * log2 n) environ) ou une autre méthode i.e. "Bitmap".

Les particularités d'OLAP (relationnel) :

Quelques épisodes de la vie NoSQL vue par YesSQL.

Ce sujet a été monté lors de la validation technique d'un projet. Le scénario des tests est :

• estimer l'insertion intensive des données depuis les nombreuses unités (par exemple, les capteurs)
• comparer la simplicité et la performance des requêtes « typiques »

Le test d'insertion, ou l'Expulsion du Paradis

J'ai limité l'insertion des données depuis les multiples capteurs par 10 millions lignes ce que est corresponde à 1 heure de travail environ.