OLTP en mémoire dans SQL Server 2016 : quelles sont les améliorations

Des performances In-Memory renforcées

Comparée à la technologie In-Memory de SQL Server 2014, celle dans SQL Server 2016 améliore les performances des requêtes. Par exemple, les mêmes transactions, effectuées sur des tables optimisées de SQL Server 2014 seront 30 fois plus rapide lorsqu’elles seront exécutées sur des tables optimisées avec SQL Server 2016.

Plus de mémoire pour les tables optimisées

Avec SQL Server 2014, Microsoft recommandait un maximum de 256 Go de mémoire pour ces tables optimisées. Cette recommandation repose sur le nombre de fichiers CHECKPOINT supportés, utilisés pour la procédure de récupération.  Dans SQL Server 2016, le maximum recommandé est 2 To de mémoire pour les tables optimisées. Evidemment, quelle que soit la quantité de données dans les tables optimisées pour le In-Memory, toutes les données de ces tables doivent pouvoir être contenues en mémoire.

Collation

Dans SQL Server 2014, il est obligatoire d’utiliser des collations BIN2 pour toutes les colonnes de chaînes qui utilisent tout ou partiellement un index key. De plus, dans des procédures stockées, et compilées en mode natif, vous devez également utiliser les collations BIN2 pour toutes les comparaisons entre valeurs de caractères.

Même si ce n’est plus une exigence dans le moteur OLPT en mémoire de SQL Server 2016 – vous pouvez utiliser toutes formes de collations pour comparer les valeurs de caractères dans les procédures stockées compilées en mode natif -, il se peut que vous rencontriez une perte significative de performances lorsque vous utilisez des collations autres que BIN2

Modifications des données

L’OLTP In-Memory dans SQL Server 2014 ne permet pas de modifier les tables optimisées en mémoire une fois celles-ci créées. Si vous devez modifier les schémas ou reconstruire l’index, vous devez supprimer ou  re-créer les tables optimisées (via  les commandes DROP TABLE et CREATE TABLE). Avec SQL Server 2016, ce n’est plus obligé ; vous pouvez modifier les tables optimisées après leur création, via la commande ALTER TABLE – pour, par exemple,  ajouter, modifier ou ôter des colonnes à ces tables optimisées, ou ajouter, supprimer et reconstruire des indexes. Voici quelques exemples : 

- Exemple 1 – Modifier une table optimisée pour ajouter 2 colonnes avec une contrainte NOT NULL et une définition DEFAULT, tout en utilisant WITH VALUES pour ajouter des valeurs à des lignes existantes

Fig1 : ajouter 2 colonnes pour attribuer des valeurs des lignes existantes

- Exemple 2 –  Modifier une table optimisée pour changer CarrierTrackingNumber, de nvarchar(25) en nvarchar(50)

Fig2 : Modifier  CarrierTrackingNumber, de nvarchar(25) en nvarchar(50)

- Exemple 3 – Modifier une table optimisée pour supprimer une colonne UnitPriceDiscount

Figure 3 : Supprimer une colonne UnitPriceDiscount

- Exemple 4 – Modifier une table optimisée pour reconstruire un index non-cluster avec un nouveau BUCKET_COUNT

Figure 4 : Reconstruire un index non-cluster avec un nouveau BUCKET_COUNT

Le support de Transact-SQL étendu

Dans SQL Server 2014, les procédures stockées compilées en mode natif ne supportent pas toutes les spécificités du langage Transact-SQL. Celles-ci sont supportées dans les procédures stockées en mode interprété. Heureusement, les procédures stockées compilées en mode natif  de SQL Server 2016 supportent un pan plus étendu de Transact-SQL :

• LEFT / RIGHT OUTER JOIN
• SELECT DISTINCT
• Les opérateurs OR et NOT
• Appels aux procédures stockées imbriquées
• UNION et UNION ALL
• Toutes les fonctions mathématiques intégrées

Transparent Data Encryption (TDE)

Dans SQL Server 2014, la fonction TDE n’est pas compatible avec les tables optimisées. Cela signifie que les données stockées dans ces tables sur un filegroup MEMORY_OPTIMIZED_DATA ne sont pas chiffrées sur le disque. Cette limite n’est plus et la fonction TDE est entièrement compatible avec les tables optimisées de SQL Server 2016. Toutes les données sont chiffrées sur le disque.

AlwaysOn

Dans SQL Server 2014, la visibilité des données des tables optimisées sur des replicas secondaires est retardée par des transactions. Ce n’est pas le cas avec SQL Server 2016 : comme avec les tables sur disque, les données sont toutes visibles immédiatement.

Nombre de sockets

Dans SQL Server 2016, plusieurs améliorations ont été apportées aux algorithmes qui motorisent l’OLTP en mémoire. Grâce à cela, le moteur OLTP en mémoire de cette version est bien plus efficace sur plusieurs sockets. Par exemple, comparé à SQL Server 2014, le dimensionnement sera plus efficace avec une machine à 4 sockets avec SQL Server 2016.

Traduit et adapté par la rédaction