Testing

Les index columnstore en SQL Server 2012

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

Multiples index simples en OLAP (Décisionnel)

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) :

MongoDB vs SQL Server ?

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.

Pagination dans SQL Server 2012

Bonne nouvelle pour les développeurs ! Enfin, SQL Server 2012 introduit l'instruction de pagination ORDER BY OFFSET au niveau de la requête SQL. Est-ce que cela veut dire que les anciennes méthodes ne sont plus valables ? Faisons-nous les tests pour y répondre...

Scénario de test

L'archive des scripts SQL de test comprit un fichier par une étape :

Pagination avec des examples sous SQL Server

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.

SQL et niveau d'isolement des transactions

Un peu de thèorie

Tout d'abord rappelons-nous qu'une transaction est une séquence d'étapes qui effectue une unité logique de travail. La transaction garantit que toutes les étapes seront exécutée ou aucune d'elles ne doit être validées. D'autre part la propriété d'isolation des transactions assure que les modifications effectuées par une transaction sont isolées des autres transactions concurrentes. Dans cette article nous allons voir l'utilisation des différents niveaux d'isolement des transactions lors des applications pratiques en SQL Server 2005/2008

Subscribe to RSS - Testing