BI experience

C’est quoi le In Memory OLTP ?

| 0 Commentaires

Sur les deux articles précédents, nous avons décrit les options présentes ou pas aux niveaux des différentes versions et éditions d’SQL server.
Encore faut-il comprendre à quoi servent ces options afin de savoir si dans notre cas client elles pourraient nous être indispensables…

Je vous propose lors des articles à venir de décrire ces options en restant sur un angle BI pour une lecture plus facile et orientée.

Commençons donc par l’option « In Memory OLTP ». Cette option apporte performance pour les traitements transactionnels en :
- supprimant des verrous entre les transactions exécutées simultanément.
- optimisant en mémoire, les algorithmes de stockage des données, les accès et les traitements des données.

Les objets qui permettent de bénéficier de ces performances sont :

  • Les « Memory optimized tables » : ces types de tables sont utilisées par exemple
    • pour les « table-valued parameters » : permettant de faire du chargement en bulk de plusieurs lignes de données en une fois.
    • dans les procédures stockées, pour les jeux de données intermédiaires stockés dans des tables de type de « Memory optimized tables » . Ces dernières hériteront des avantages des « non durable memory optimized tables  » : accès efficace aux données et absence d’E/S

Ce type d’objet ne réduit pas l’utilisation du processeur.
(si la plupart des requêtes effectuent des opérations d’agrégation sur de grandes plages de données  : utiliser plutôt des index columnstore)

  • Les « non durable tables memory optimized tables » : Le stockage principale de ces tables est la mémoire principale. Les modifications apportées à ces tables n’entraînent aucune E/S
  • Les « natively compiled T-SQL modules » (procédures stockées, déclencheurs et fonctions scalaires ) permettent d’accélérer encore plus l’exécution d’une transaction individuelle en réduisant les cycles processeur requis pour traiter les opérations.

Les scénarios BI qui peuvent nous intéresser :

Use case 1 : Remplacer certains objets standards de la tempdb :
- les « tables temporaires » (#temp) par les « Non durable tables memory optimized tables » qui réduisent généralement l’utilisation du processeur
- ou encore les « variables de table » par les « table-valued parameters » qui suppriment complètement les E/S de journal.

Use case 2 : au niveau de l’ETL

- Pour charger et mettre à jour d’importants volumes de données provenant de nombreuses sources différentes : utiliser des « non durable tables memory optimized tables » pour la mise en lots des données. Elles suppriment complètement les E/S et optimisent l’efficacité de l’accès aux données.

-Pour accélérer les transformations sur la table de mise en lots : utiliser des « natively compiled T-SQL modules« . De plus pour toujours plus de performance, il sera possible de paralléliser ces transformations.

J’espère que ce point est un peu plus clair…Dites moi ce que vous en pensez…Si vous avez déjà utilisés ces options…

Laisser un commentaire

Champs Requis *.

*