Considérations matérielles pour l’OLTP en mémoire dans SQL Server
L’OLTP en mémoire n’utilise pas la mémoire et le disque de la même façon que les tables basées sur des disques classiques. L’amélioration des performances que vous voyez avec OLTP en mémoire dépend du matériel que vous utilisez. Dans cet article, nous abordons plusieurs considérations générales relatives au matériel et fournissons des instructions génériques pour le matériel à utiliser avec OLTP en mémoire.
Remarque
Cet article était un blog publié le 1er août 2013 par l’équipe Microsoft SQL Server 2014. La page web du blog est supprimée.
UC
OLTP en mémoire ne nécessite pas de serveur haut de gamme pour prendre en charge une charge de travail OLTP à débit élevé. Nous vous recommandons d’utiliser un serveur de milieu de gamme avec deux sockets processeur. En raison de l’augmentation du débit activé par OLTP en mémoire, deux sockets seront probablement suffisants pour vos besoins métier.
Nous vous recommandons d’activer le multithreading simultané (SMT) avec OLTP en mémoire. Avec certaines charges de travail OLTP, nous avons constaté des gains de performances allant jusqu’à 40 % lors de l’utilisation de SMT.
Mémoire
Toutes les tables à mémoire optimisée résident entièrement en mémoire. Par conséquent, vous devez disposer d’une mémoire physique suffisante pour les tables elles-mêmes et maintenir la charge de travail en cours d’exécution sur la base de données : la quantité de mémoire dont vous avez réellement besoin dépend vraiment de la charge de travail, mais comme point de départ, vous avez besoin de suffisamment de mémoire disponible pour environ deux fois la taille des données. Vous avez également besoin de suffisamment de mémoire pour le pool de mémoires tampons si la charge de travail fonctionne également sur des tables sur disque traditionnelles.
Pour déterminer la quantité de mémoire utilisée par une table à mémoire optimisée donnée, exécutez la requête suivante :
select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;
Les résultats montrent la mémoire utilisée pour les tables optimisées en mémoire et leurs index. Les données de la table incluent les données utilisateur et toutes les versions de ligne antérieures qui sont toujours requises par les transactions en cours d’exécution ou qui n’ont pas encore été propre mises à jour par le système. La mémoire utilisée par les index de hachage est constante et ne dépend pas du nombre de lignes de la table.
Il est important de garder à l’esprit quand vous utilisez OLTP en mémoire que votre base de données entière n’a pas besoin de s’adapter à la mémoire. Vous pouvez avoir une base de données multi Teraoctet et bénéficier toujours d’OLTP en mémoire, tant que la taille de vos données chaudes (autrement dit, les tables à mémoire optimisée) ne dépassent pas 256 Go. Le nombre maximal de fichiers de données case activée point que SQL Server peut gérer pour une base de données unique est de 4 000, chaque fichier étant de 128 Mo. Bien que cela donne un maximum théorique de 512 Go, afin de garantir que SQL Server peut continuer à fusionner des fichiers case activée point et ne pas atteindre la limite de 4 000 fichiers, nous prenons en charge jusqu’à 256 Go. Cette limite applique uniquement les tables optimisées en mémoire ; il n’existe aucune limitation de taille sur les tables traditionnelles basées sur disque dans la même base de données SQL Server.
Les tables à mémoire optimisée non durable (NDT), c’est-à-dire les tables à mémoire optimisée avec DURABILITY=SCHEMA_ONLY ne sont pas conservées sur le disque. Bien que les NDT ne soient pas limités par le nombre de fichiers case activée point, seuls 256 Go sont pris en charge. Les considérations relatives aux lecteurs de journal et de données dans le reste de ce billet ne s’appliquent pas aux tables non durables, car les données existent uniquement en mémoire.
Lecteur de journal
Les enregistrements de journal se rapportant aux tables à mémoire optimisée sont écrits dans le journal des transactions de base de données avec les autres enregistrements de journal SQL Server.
Il est toujours important de placer le fichier journal sur un lecteur qui a une faible latence, de sorte que les transactions n’ont pas besoin d’attendre trop longtemps et d’empêcher la contention sur les E/S de journal. Votre système s’exécute aussi rapidement que votre composant le plus lent (loi d’Amdahl). Vous devez vous assurer que, lors de l’exécution d’OLTP en mémoire, votre appareil d’E/S de journal ne devient pas un goulot d’étranglement. Nous recommandons l’utilisation d’un dispositif de stockage avec une faible latence, au moins SSD.
Les tables optimisées en mémoire utilisent moins de bande passante de journal que les tables basées sur disque, car elles ne journalisent pas les opérations d’index et ne journalisent pas les enregistrements UNDO. Cela peut aider à soulager la contention d’E/S du journal.
Lecteur de données
La persistance des tables mémoire optimisées à l’aide de fichiers case activée point utilise des E/S de streaming. Par conséquent, ces fichiers n’ont pas besoin d’un lecteur avec une faible latence ou des E/S aléatoires rapides. Au lieu de cela, le principal facteur pour ces lecteurs est la vitesse des E/S séquentielles et de la bande passante de l’adaptateur de bus hôte (HBA). Par conséquent, vous n’avez pas besoin de disques SSD pour les fichiers case activée point ; vous pouvez les placer sur des broches hautes performances (par exemple, SAS), tant que leur vitesse d’E/S séquentielle répond à vos besoins.
Le facteur le plus important qui intervient dans la détermination des besoins en vitesse est votre objectif de délai de récupération [RTO, Recovery Time Objective] lors du redémarrage du serveur. Lors de la récupération de la base de données, toutes les données dans les tables à mémoire optimisée doivent être lues à partir du disque, en mémoire. La récupération de base de données se produit à la vitesse de lecture séquentielle de votre sous-système d’E/S ; le disque est le goulot d’étranglement.
Pour répondre à des exigences strictes en matière de RTO, nous vous recommandons de répartir les fichiers case activée point sur plusieurs disques, en ajoutant plusieurs conteneurs au groupe de fichiers MEMORY_OPTIMIZED_DATA. SQL Server prend en charge la charge parallèle de fichiers de point de contrôle à partir de plusieurs lecteurs ; la récupération se produit à la vitesse globale des lecteurs.
En termes de capacité de disque, nous vous recommandons d’avoir 2 à 3 fois la taille des tables optimisées en mémoire disponibles.