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.

Voir aussi l'article "Pagination dans SQL Server 2012"

En fait, MS SQL Server n'a pas des contraintes au niveau d'instruction SELECT pour limiter l'ensemble de données retourné par les numéros des lignes. Par exemple, récupérer un bloc de commandes d'un client trié par leur dates à partir de 10 000 et jusqu'au 12 000.

SELECT O.*
  FROM orders O INNER JOIN customers C
    ON O.customer_code = C.customer_code
  ORDER BY O.qty_date ASC
  LIMIT 10000, 12000

Les fonctions de classements introduites dans la version MS SQL 2005 et notamment la fonction row_number() ont fait la vie quotidien du développeur plus facile. Mais cette solution reste palliative plutôt puisque l'instruction LIMIT se traite au niveau du moteur de la base de données ainsi que les fonctions de classement se traitent au niveau utilisateur. Ensuite, la performance de LIMIT est supérieur. La différence devient plus significative si la taille de vos tables et de blocs récupérés est assez grand (centaines milles et millions de lignes).

Dans cette article je vous présente les différentes méthodes de pagination (paging, sélection par bloc). Pour les tests j'ai utilisé MS SQL Server 2005 Service Pack 2 (9.00.3054.00)installé sur l'ordinateur pas trop puissant : Intel double coeur 1,8 GHz, 2 Go de mémoire vive (512 Mo est disponible pour SQL Server), disque dur 250 Go 7200 rpm. La taille de la base de données est 5 Go environ.