Tables optimisées en mémoire - peuvent-elles vraiment être si difficiles à maintenir?

J'étudie les avantages de la mise à niveau de MS SQL 2012 vers 2014. L'un des principaux arguments de vente de SQL 2014 est les tables optimisées en mémoire, qui rendent apparemment les requêtes ultra-rapides.

J'ai constaté qu'il y a quelques limitations sur les tables optimisées en mémoire, telles que:

• Aucun (max)champ dimensionné
• Maximum ~ 1 Ko par ligne
• Pas de timestampchamps
• Aucune colonne calculée
• Aucune UNIQUEcontrainte

Tous ces éléments sont considérés comme des nuisances, mais si je veux vraiment les contourner afin d'obtenir des avantages en termes de performances, je peux faire un plan.

Le vrai coup de pied est le fait que vous ne pouvez pas exécuter une ALTER TABLEinstruction, et vous devez passer par ce rigmarole chaque fois que vous ajoutez un champ à la INCLUDEliste d'un index. De plus, il semble que vous devez exclure les utilisateurs du système afin d'apporter des modifications de schéma aux tables MO sur la base de données en direct.

Je trouve cela totalement scandaleux, dans la mesure où je ne peux vraiment pas croire que Microsoft aurait pu investir autant de capital de développement dans cette fonctionnalité, et la laisser si difficile à maintenir. Cela m'amène à la conclusion que j'ai dû avoir le mauvais bout du bâton; Je dois avoir mal compris quelque chose au sujet des tables optimisées en mémoire qui m'a amené à croire qu'il est beaucoup plus difficile de les maintenir qu'il ne l'est réellement.

Alors, qu'est-ce que j'ai mal compris? Avez-vous utilisé des tables MO? Existe-t-il une sorte de commutateur ou de processus secret qui les rend pratiques à utiliser et à entretenir?

Non, la mémoire est vraiment non polie. Si vous êtes familier avec Agile, vous connaîtrez le concept de «produit minimal livrable»; en mémoire c'est ça. J'ai l'impression que MS avait besoin d'une réponse à SAP Hana et ses semblables. C'est ce qu'ils pourraient obtenir débogué dans le délai d'une version 2014.

Comme pour toute autre chose, la mémoire a des coûts et des avantages associés. Le principal avantage est le débit qui peut être atteint. L'un des coûts est les frais généraux liés à la gestion du changement, comme vous l'avez mentionné. Cela n'en fait pas un produit inutile, à mon avis, cela réduit simplement le nombre de cas où il fournira un avantage net. Tout comme les index columnstore peuvent désormais être mis à jour et les index peuvent être filtrés, je ne doute pas que la fonctionnalité de la mémoire s'améliorera au cours des prochaines versions.

SQL Server 2016 est désormais généralement disponible. Comme je le supposais, l' OLTP en mémoire a reçu un certain nombre d'améliorations. La plupart des modifications implémentent des fonctionnalités dont les tables traditionnelles bénéficient depuis un certain temps. Je suppose que les futures fonctionnalités seront publiées en même temps pour les tables en mémoire et traditionnelles. Les tables temporelles en sont un exemple. Nouveau dans cette version, il est pris en charge par les tables en mémoire et sur disque .

L'un des problèmes de la nouvelle technologie - en particulier une version V1 qui a été révélée assez fort comme n'étant pas complète - est que tout le monde saute dans le train et suppose qu'il convient parfaitement à chaque charge de travail. Ce n'est pas. Le point fort de Hekaton est les charges de travail OLTP de moins de 256 Go avec beaucoup de recherches de points sur 2-4 sockets. Cela correspond-il à votre charge de travail?

De nombreuses limitations concernent les tables en mémoire associées à des procédures compilées en mode natif. Vous pouvez bien sûr contourner certaines de ces limitations en utilisant des tables en mémoire mais pas en utilisant des procédures compilées en mode natif, ou du moins pas exclusivement.

De toute évidence, vous devez tester si le gain de performances est substantiel dans votre environnement, et si tel est le cas, si les compromis en valent la peine. Si vous obtenez de grands gains de performances sur les tables en mémoire, je ne sais pas pourquoi vous vous inquiétez de la quantité de maintenance que vous allez effectuer sur les colonnes INCLUDE. Vos index en mémoire couvrent par définition. Celles-ci ne devraient vraiment être utiles que pour éviter les recherches sur la plage ou les analyses complètes des index non clusterisés traditionnels, et ces opérations ne sont pas vraiment censées se produire dans les tables en mémoire (encore une fois, vous devez profiler votre charge de travail et voir quelles opérations s'améliorer et qui ne le font pas - ce n'est pas tout gagnant-gagnant). À quelle fréquence détruisez-vous les colonnes INCLUDE dans vos index aujourd'hui?

Fondamentalement, si cela ne vaut pas encore la peine pour vous sous sa forme V1, ne l'utilisez pas. Ce n'est pas une question à laquelle nous pouvons répondre pour vous, sauf pour vous dire que de nombreux clients sont prêts à vivre avec les limitations et utilisent la fonctionnalité avec grand avantage malgré eux.

SQL Server 2016

Si vous êtes en route vers SQL Server 2016, j'ai blogué sur les améliorations que vous verrez dans OLTP en mémoire, ainsi que l'élimination de certaines des limitations . Notamment:

• Augmentation de la taille maximale durable de la table: 256 Go => 2 To
• Colonnes LOB / MAX, index sur les colonnes annulables, suppression des exigences de classement BIN2
• Modifier et recompiler des procédures
• Un certain support pour ALTER TABLE - il sera hors ligne mais vous devriez être en mesure de modifier et / ou de supprimer / recréer les index (cela ne semble pas être pris en charge sur les versions CTP actuelles, alors ne prenez pas cela comme une garantie)
• Déclencheurs DML, contraintes FK / check, MARS
• OU, NON, DANS, EXISTE, DISTINCT, UNION, JOINTS EXTÉRIEURS
• Parallélisme

Vous ne pouvez pas cliquer avec le bouton droit sur une table optimisée en mémoire, pour afficher un concepteur et ajouter de nouvelles colonnes comme vous le souhaitez, à partir de Sql Server Management Studio. Vous ne pouvez pas non plus cliquer dans le nom de la table pour renommer la table. (SQL 2014 au moment où j'écris ceci.)

Au lieu de cela, vous pouvez cliquer avec le bouton droit sur la table et créer une commande de création de script dans une nouvelle fenêtre de requête. Cette commande de création peut être modifiée en ajoutant de nouvelles colonnes.

Ainsi, pour modifier la table, vous pouvez stocker les données dans une nouvelle table, table temporaire ou variable de table. Ensuite, vous pouvez supprimer et recréer la table avec le nouveau schéma et enfin recopier dans les données réelles . Ce jeu de shell à 3 conteneurs est seulement un peu moins pratique pour la plupart des cas d'utilisation.

Mais, vous n'auriez aucune raison de vous soucier des tables Memory Optimized s'il n'y a pas de problème de performances que vous essayez de résoudre.

Ensuite, vous devrez évaluer si les limitations et les solutions de contournement en valent la peine pour votre cas d'utilisation. Avez-vous un problème de performances? Avez-vous essayé tout le reste? Est-ce que cela améliorera vos performances de 10 à 100x? L'utiliser ou ne pas l'utiliser finira probablement par être un peu plus compliqué que ce soit.

vous pouvez utiliser OLTP en mémoire dans les serveurs opérationnels sans problème majeur. nous avons utilisé cette technologie dans une entreprise bancaire et de paiement,

En général, nous pouvons utiliser des tables optimisées en mémoire lorsque la charge de travail est trop élevée. en utilisant OLTP en mémoire, vous pouvez atteindre de meilleures performances jusqu'à 30X! Microsoft corrige la plupart de ces limitations dans SQL Server 2016 et 2017. Les tables à mémoire optimisée ont une architecture complètement différente de celle des tables sur disque.

les tables optimisées en mémoire sont de deux types. tables durables et tables non durables. Les tables durables et non durables conservent les données de la table en mémoire. De plus, les tables durables conservent les données sur les disques pour les données de récupération et le schéma. la plupart des scénarios opérationnels, nous devrions utiliser des tables durables car les données perdues sont critiques ici. dans certains scénarios, par exemple le chargement ETL et la mise en cache, nous pouvons utiliser des tables non durables.

vous pouvez utiliser ces ebooks et apprendre à utiliser cette technologie:

Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718