Par Techopedia Staff, 25 janvier 2017
À retenir: l' hôte Eric Kavanagh discute de l'informatique en mémoire et de SAP HANA avec les invités Dr. Robin Bloor, Dez Blanchfield et Bill Ellis de l'IDERA.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Eric Kavanagh: D'accord, mesdames et messieurs. Bonjour et bienvenue encore une fois. Il est 16 heures, heure de l'Est un mercredi et les deux dernières années, ce qui signifie qu'il est temps, encore une fois, pour Hot Technologies. Oui, en effet, je m'appelle Eric Kavanagh, je serai votre hôte pour la conversation d'aujourd'hui.
Et les amis, nous allons parler de trucs sympas aujourd'hui. Nous allons plonger dans le monde de la mémoire, le titre exact est «Dans le futur: une rampe pour l'informatique en mémoire». C'est à la mode ces jours-ci, et pour cause, principalement parce que la mémoire est tellement plus rapide que de compter sur des disques en rotation. Le défi, cependant, est que vous devez réécrire beaucoup de logiciels. Parce que le logiciel d'aujourd'hui, pour la plupart, a été écrit en pensant au disque et cela change vraiment l'architecture de l'application. Si vous concevez l'application pour attendre un disque en rotation, vous faites les choses différemment que si vous avez toute la puissance de la technologie en mémoire.
Il y a vraiment une place dans la tienne, frappe-moi sur Twitter, @eric_kavanagh. J'essaie toujours de revenir en arrière et de retweeter chaque fois que quelqu'un me mentionne.
Comme je l'ai dit, nous parlons en mémoire aujourd'hui, et en particulier de SAP HANA. La vôtre a vraiment passé l'année dernière à bien connaître la communauté SAP, et c'est un environnement fascinant, je dois dire. Chapeau aux gens qui dirigent cette opération et qui sont en première ligne, car SAP est une très bonne opération. Ce qu'ils font vraiment très bien, c'est faire des affaires. Ils sont également excellents en technologie, bien sûr, et ils ont vraiment investi massivement dans HANA. En fait, je me souviens - c'était probablement il y a environ six ou sept ans - que nous travaillions pour l'US Air Force en fait, et nous avons fait venir quelqu'un de SAP pour nous donner un premier aperçu du monde de HANA et ce qui était prévu. Et pour dire le moins, les gens des SAP Labs avaient consacré beaucoup de temps et d'efforts à comprendre comment construire cette architecture qui est complètement différente, encore une fois, des environnements traditionnels, car vous avez tout en mémoire. Donc, ils parlent de faire à la fois transactionnel et analytique sur les mêmes données en mémoire, par opposition à la manière traditionnelle, qui est de les extraire, de les mettre dans un cube, par exemple, de les analyser là-bas, par opposition à transactionnelles, qui arrive d'une manière très différente.
C'est un espace intéressant et nous allons découvrir auprès d'un autre fournisseur en fait, IDERA, un peu sur la façon dont tout cela va fonctionner, et sur ce qu'est la rampe d'accès, franchement. Donc, nous allons entendre le Dr Robin Bloor, notre propre analyste en chef ici au Bloor Group; Dez Blanchfield, notre data scientist puis bon ami Bill Ellis de l'IDERA. Donc, avec cela, je vais remettre les clés au Dr Robin Bloor, qui les enlèvera.
Dr Robin Bloor: Oui, comme le disait Eric, le moment où nous avons été informés pour la première fois par SAP HANA était de retour il y a de nombreuses années, maintenant. Mais c'était très intéressant, ce moment particulier était très intéressant. Nous rencontrions une ou deux sociétés qui offraient, d'une manière ou d'une autre, une technologie en mémoire. Il était tout à fait clair que la mémoire allait venir. Et ce n'est vraiment que lorsque SAP s'est levé et a soudainement lancé HANA. Je veux dire, ce fut un choc quand j'ai vu SAP faire ça. C'était, genre, c'était un choc parce que je m'attendais à ce que ça vienne d'ailleurs. Je m'attendais à ce que ce soit, vous savez, Microsoft ou Oracle ou IBM ou quelqu'un comme ça. L'idée que SAP le faisait était vraiment très surprenante pour moi. Je suppose que cela n'aurait pas dû être parce que SAP est l'un des fournisseurs stratégiques et à peu près, vous savez, tout ce qui se passe dans l'industrie vient de l'un d'eux.
Quoi qu'il en soit, tout ce qui concerne la mémoire, je veux dire, nous avons réalisé, nous en parlions, que dès que vous allez en mémoire - il ne s'agit pas de mettre des données en mémoire, il s'agit de s'engager idée que la couche mémoire est l'enregistrement système - dès que vous migrez l'enregistrement système vers la mémoire, le disque commence à devenir un support de transfert d'une sorte et cela devient une chose différente. Et j'ai pensé que c'était très excitant quand cela a commencé à se produire. Donc, vraiment, c'est fini pour faire tourner le disque. Le disque tournant ne sera bientôt disponible que dans les musées. Je ne sais pas combien de temps cela va arriver, mais en gros, le disque à semi-conducteurs est maintenant sur la courbe de la loi de Moore, il est déjà dix fois plus rapide que la rouille en rotation, comme ils l'appellent maintenant, et très bientôt il sera encore plus rapide et cela signifie que les cas d'utilisation pour le disque sont de moins en moins nombreux.
Et le fait curieux, le SGBD traditionnel, en fait, beaucoup de logiciels traditionnels ont été construits pour tourner le disque, il supposait le disque tournant. Il avait toutes sortes de capacités au niveau physique qui étaient minutieusement programmées, afin d'exploiter le disque en rotation, ce qui rend la récupération des données aussi rapide que possible. Et tout cela est emporté. En train de disparaître, tu sais? Et puis, il y avait évidemment une ouverture très - je ne sais pas, lucrative, je suppose, ce sera finalement - pour une base de données en mémoire qui tentait d'occuper la position que les grandes bases de données, Oracle et Microsoft, SQL Serveur et DB2 d'IBM, il occupait l'espace en mémoire et c'était très intéressant de regarder ce qui avance et de le faire.
Parlons de la cascade de mémoire; cela mérite juste d'être mentionné. C'est aussi, la raison de mentionner cela, la raison pour laquelle j'ai ajouté cela, vraiment, c'était juste pour faire savoir à tout le monde, quand je parle de mémoire ici, toutes ces couches dont je parle sont en fait de la mémoire. Mais vous vous rendez compte soudainement quand vous regardez cela, c'est un magasin hiérarchique, ce n'est pas seulement de la mémoire. Et donc, à peu près tout ce que nous avons appris il y a très longtemps sur le magasin hiérarchique s'applique également. Et cela signifie également que toute base de données en mémoire doit se frayer un chemin à travers cela, certains la parcourent simplement sur la RAM elle-même, vous savez. Et il ne fait que s'agrandir et de plus en plus et il est maintenant mesuré en mégaoctets. Mais vous avez le cache L1 qui est cent fois plus rapide que la mémoire, le cache L2 30 fois plus rapide que la mémoire et le cache L3 environ 10 fois plus rapide que la mémoire. Donc, vous savez, il y a beaucoup de technologie - enfin, pas mal de technologie - a adopté la stratégie d'utiliser ces caches comme, en quelque sorte, un espace de stockage sur le chemin de l'exécution des choses, en particulier la technologie des bases de données. Donc, vous savez, c'est une influence.
Ensuite, nous avons l'émergence de 3D XPoint et d'IBM PCM. Et c'est presque la vitesse de la RAM, c'est essentiellement ce que ces deux fournisseurs vantent. Les cas d'utilisation sont probablement différents. L'expérimentation précoce avec ceci n'est pas encore terminée. Nous ne savons pas comment cela va avoir un impact sur l'utilisation de la RAM et la technologie de la base de données en mémoire. Vous avez alors la RAM contre le SSD. Actuellement, la RAM est environ 300 fois plus rapide mais, bien sûr, ce multiple diminue. Et SSD contre disque qui est environ 10 fois plus rapide, si je comprends bien. Voilà le genre de situation que vous avez. C'est un magasin hiérarchique. En regardant les choses autrement, en mémoire, bien sûr, c'est complètement différent. Ainsi, le diagramme du haut montre deux applications, toutes deux accédant peut-être à une base de données, mais accédant certainement à des données sur la rouille en rotation. Et la façon dont vous faites réellement circuler les choses à travers le réseau, en fonction des dépendances, est que vous avez ETL. Donc, cela signifie que, vous savez, les données vont sur la rouille tournante puis sortent de la rouille tournante pour aller n'importe où, et pour arriver n'importe où, elles retournent sur la rouille tournante, qui est en trois mouvements. Et gardez à l'esprit que la mémoire peut être cent mille fois plus rapide que la rotation du disque, et vous vous rendez certainement compte que prendre des données et les mettre en mémoire rend tout cela très différent.
Donc, vous pourriez avoir pensé que ce qui se passerait serait sur ce qui est à l'écran ici, vous pourriez avoir pensé que, d'une manière ou d'une autre, l'ETL passerait en fait de données en données en mémoire. Mais en réalité, cela pourrait ne pas faire cela; en fait, vous pourriez avoir la situation à droite ici où deux applications peuvent réellement déclencher la même mémoire. Une base de données en mémoire pourrait certainement vous donner cette capacité, tant que vous avez le verrouillage et tout le reste orchestré autour d'elle. Donc, cela ne modifie pas seulement la vitesse des choses, cela modifie la façon dont vous configurez réellement les applications et les flux de données entiers.
C'est donc un énorme impact. Donc, la mémoire est perturbatrice, non? Et nous devrions tirer cela de ce que j'ai dit. Le traitement en mémoire est actuellement un accélérateur mais cela va devenir la norme. Il sera utilisé, appliqué en fonction de la valeur de l'application, et c'est donc très, très intéressant, que SAP sortira en fait une version de leur logiciel ERP qui est en mémoire. Et des améliorations de latence jusqu'à trois ordres de grandeur sont tout à fait possibles, et même plus que cela, en fonction de la façon dont vous le faites. Ainsi, vous obtenez d'énormes améliorations de vitesse en allant en mémoire. Et le résultat, le S / 4 de SAP HANA - qu'ils ont publié, je pense, eh bien, les gens disent qu'il est toujours en cours de publication, mais il a certainement été publié l'année dernière - c'est un jeu qui change la donne compte tenu de la base de clients SAP. Je veux dire, il y a 10 000 entreprises qui utilisent l'ERP de SAP et presque toutes sont de grandes entreprises, vous savez. Donc, l'idée de tous avoir une incitation à aller en mémoire et à utiliser leurs fondamentaux, car l'ERP est presque toujours une application fondamentale que les entreprises exécutent, c'est juste un énorme changement de jeu et ce sera très intéressant. Mais bien sûr, tout cela sonne très bien, mais il doit être configuré intelligemment et il doit être bien surveillé. Ce n'est pas aussi simple qu'il y paraît.
Cela dit, je pense que je vais passer le ballon à qui est ce type? Oh, l'Australien, Dez Blanchfield.
Dez Blanchfield: Très drôle. Toujours un acte difficile à suivre, Dr Robin Bloor. Merci de m'avoir invité aujourd'hui. Donc, gros sujet, mais passionnant. J'ai donc choisi une image que j'évoque souvent lorsque je pense au Data Lake moderne et aux entrepôts de données d'entreprise, et à mes petits trésors de données. J'ai donc ici ce magnifique lac entouré de montagnes et de vagues qui sortent, et les vagues s'écrasent sur ces rochers. C'est, en quelque sorte, comment je visualise mentalement à quoi cela ressemble à l'intérieur d'un grand lac de données de nos jours. Les vagues étant des travaux par lots, et des analyses en temps réel lancées sur les données, les roches. Et quand j'y pense comme un lac physique, cela me rappelle un peu le réveil que, vous savez, l'ampleur des entrepôts de données que nous construisons maintenant, la raison pour laquelle nous avons créé cette monnaie et la durée de un lac de données, c'est qu'elles sont très grandes et très profondes, et parfois vous pouvez avoir des tempêtes. Et quand nous le faisons, vous devez toujours résoudre ce qui crée la tempête.
Donc, dans le thème de cette chose, il me semble que cet appel de sirène de l'informatique en mémoire est en effet très fort et pour une bonne raison. Elle entraîne de nombreux gains commerciaux et techniques importants. C'est une discussion de quelques heures un autre jour. Mais le passage général à l'informatique en mémoire, tout d'abord, je veux juste couvrir comment nous sommes arrivés ici et ce qui rend cela possible, car il, en quelque sorte, jette les bases de où certains des défis peuvent se situer en premier et ce dont nous devons être conscients et de penser à, dans notre monde qui consiste à s'éloigner des vieux disques rotatifs traditionnels contenant des données et à être paginés sur et hors du disque et en mémoire et hors mémoire et dans les processeurs, jusqu'à présent, nous supprimons presque l'une de ces couches entières, étant le disque en rotation. Parce que rappelez-vous, au tout début de l'informatique, sur le plan architectural, nous ne nous sommes pas éloignés depuis longtemps du mainframe ou du milieu de gamme de ce que nous pensions à l'origine comme mémoire de base et stockage de batterie, vous savez.
Comme l'a dit le Dr Robin Bloor, l'approche que nous avons adoptée pour déplacer les données autour de l'architecture informatique n'a pas vraiment changé de façon spectaculaire depuis un certain temps, depuis quelques décennies, en fait. Si vous pensez au fait que, vous savez, l'informatique moderne, techniquement, existe, si vous pardonnez le jeu de mots, depuis une soixantaine d'années, vous savez, six décennies et plus et c'est dans le sens où vous pouvez acheter une boîte sur l'étagère, pour ainsi dire. Le passage à une nouvelle architecture est vraiment venu dans mon esprit lorsque nous sommes passés de la pensée autour des mainframes et des médiums, et des architectures de mémoire de base et de stockage de batterie, aux courageux ou aux superordinateurs, en particulier les goûts de Seymour Cray, où des choses comme les fonds de panier transversaux est devenu une chose. Au lieu d'avoir un seul itinéraire pour déplacer des données à travers le fond de panier ou la carte mère, comme on l'appelle de nos jours. Et la mémoire en ligne, vous savez, de nos jours, les gens ne pensent pas vraiment à ce que cela signifie réellement lorsqu'ils disent DIMM et SIMM. Mais, SIMM est une mémoire en ligne unique et DIMM est une mémoire en ligne double et nous avons plus complexe que cela depuis et il existe des dizaines de types de mémoire différents pour différentes choses: certains pour la vidéo, certains uniquement pour les applications générales, certains intégrés dans les processeurs.
Il y a donc eu un grand changement vers une nouvelle façon de stocker et d'accéder aux données. Nous sommes sur le point de passer par ce même changement dans une autre génération entière, mais pas tant dans le matériel lui-même que dans l'adoption du matériel dans la logique métier et dans la couche logique des données, et c'est un autre grand changement de paradigme dans mon esprit .
Mais brièvement sur la façon dont nous sommes arrivés ici. Je veux dire, la technologie matérielle s'est améliorée et s'est considérablement améliorée. Nous sommes passés de processeurs et l'idée d'un noyau était un concept assez moderne. Nous tenons pour acquis maintenant que nos téléphones ont deux ou quatre cœurs et nos ordinateurs ont deux ou quatre, voire huit, cœurs sur le bureau et huit et 12 et plus sur, vous savez, les 16 et 32 même sur la plate-forme serveur . Mais c'est en fait une chose assez moderne que les cœurs sont devenus une capacité à l'intérieur des processeurs et que nous sommes passés de 32 bits à 64 bits. Deux grandes choses se sont produites là-bas: nous avons obtenu des vitesses d'horloge plus élevées sur plusieurs cœurs afin de pouvoir faire les choses en parallèle et chacun de ces cœurs pouvait exécuter plusieurs threads. Tout d'un coup, nous avons pu exécuter beaucoup de choses sur les mêmes données en même temps. L'espacement des adresses de 64 bits nous a donné jusqu'à deux téraoctets de RAM, ce qui est un concept phénoménal, mais c'est une chose maintenant. Ces architectures de fond de panier à chemins multiples, vous savez, les cartes mères, il était une fois, vous ne pouviez faire les choses que dans une seule direction: en arrière et en avant. Et comme à l'époque avec l'informatique Cray et certaines des conceptions de supercalculateurs de l'époque, et maintenant dans les ordinateurs de bureau et les PC courants montés en rack, en quelque sorte, de qualité bureau, parce que la plupart des systèmes modernes Les PC ont maintenant traversé cette ère de mainframe, de milieu de gamme et de micro-bureaux et nous les avons transformés en serveurs.
Et une grande partie de cette capacité de supercalculateur, cette conception de qualité supercalculateur, a été intégrée dans les composants courants du commerce. Vous savez, ces jours-ci, l'idée de prendre des PC montés en rack très bon marché et de les mettre dans des racks par centaines, voire des milliers, et d'exécuter des logiciels open source sur eux comme Linux et de déployer SAP HANA dessus, vous sais, nous tenons souvent cela pour acquis. Mais c'est une toute nouvelle chose passionnante et elle vient avec ses complexités.
Les logiciels se sont également améliorés, en particulier la gestion de la mémoire et le partitionnement des données. Je n'entrerai pas dans beaucoup de détails à ce sujet, mais si vous regardez le grand changement au cours des 15 dernières années, voire moins, comment la mémoire est gérée, en particulier les données en RAM et comment les données sont partitionnées en RAM, de sorte que, comme le Dr Robin Bloor l'a indiqué plus tôt ou auquel il a été fait allusion, vous savez, les choses peuvent lire et écrire en même temps sans se toucher, plutôt que d'avoir des temps d'attente. Beaucoup de fonctionnalités très puissantes comme la compression et le cryptage sur puce. Le chiffrement devient une chose plus importante et nous ne devons pas nécessairement le faire dans les logiciels, dans la RAM, dans l'espace CPU, maintenant que cela se produit sur la puce de manière native. Cela accélère considérablement les choses. Et le stockage et le traitement des données distribuées, encore une fois, ce que nous pensions autrefois être le truc des superordinateurs et du traitement parallèle, nous prenons maintenant cela pour acquis dans l'espace de SAP HANA et Hadoop et Spark, etc.
Donc, tout l'intérêt de cette informatique haute performance, les capacités HPC sont venues à l'entreprise et maintenant l'entreprise profite des avantages qui en découlent en termes de gains de performances et d'espace technologique et d'avantages techniques et commerciaux, car, vous savez, le temps réduit pour évaluer est considérablement diminué.
Mais j'utilise cette image d'une histoire que j'ai lue il y a quelque temps d'un homme qui a construit un boîtier PC en Lego, car cela me vient toujours à l'esprit quand je pense à certaines de ces choses. Et c'est ça, cela semble être une excellente idée au moment où vous commencez à le construire, puis vous y arrivez à mi-chemin et vous vous rendez compte qu'il est en fait vraiment difficile de rassembler tous les morceaux de Lego et de faire une chose solide, assez solide pour mettre une carte mère et ainsi de suite, cela va construire un boîtier pour un ordinateur personnel. Et finalement, vous vous rendez compte que tous les petits morceaux ne collent pas correctement et vous devez faire un peu attention aux petits morceaux que vous collez pour le rendre solide. Et c'est une idée très mignonne, mais c'est un réveil lorsque vous arrivez à mi-chemin et que vous réalisez: "Hmm, j'aurais peut-être juste dû acheter un boîtier PC à 300 $, mais je vais le terminer maintenant et en apprendre quelque chose."
Pour moi, c'est une excellente analogie avec ce que c'est que de construire ces plates-formes très complexes, parce que c'est bien beau de le construire et de se retrouver avec un environnement où vous avez des routeurs et des commutateurs et des serveurs et des racks. Et vous avez des CPU, RAM et système d'exploitation regroupés. Et vous mettez quelque chose comme HANA dessus pour le traitement distribué en mémoire et le stockage et la gestion des données. Vous créez la pile SAP en plus de cela, vous obtenez les capacités de la base de données, puis vous chargez vos données et votre logique métier et vous commencez à lui appliquer des lectures, des écritures et des requêtes, etc. Vous devez rester au courant des E / S et vous devez planifier les choses et gérer les charges de travail et la mutualisation, etc. Cette pile devient très complexe, très rapidement. C'est une pile complexe en soi si ce n'est que sur une seule machine. Multipliez cela par 16 ou 32 machines, cela devient très, très non trivial. Lorsque vous multipliez jusqu'à des centaines, voire des milliers de machines, pour passer de 100 téraoctets à une échelle de pétaoctets, c'est un concept effrayant, et ce sont les réalités avec lesquelles nous avons affaire maintenant.
Donc, vous vous retrouvez ensuite avec quelques choses qui ont également contribué à changer ce monde, et c'est que l'espace disque est devenu ridiculement bon marché. Vous savez, il était une fois où vous dépensiez 380 à 400 000 dollars sur un gigaoctet de disque dur alors que c'était un énorme tambour de la taille d'un - quelque chose qui avait besoin d'un chariot élévateur pour le ramasser. De nos jours, c'est à un ou deux cents par gigaoctet d'espace disque de base. Et RAM a fait la même chose. Soit dit en passant, ces deux courbes en J dans ces deux graphiques représentent chacune une décennie, donc en d'autres termes, nous examinons deux blocs de 10 ans, 20 ans de réduction de prix. Mais je les ai divisés en deux courbes en J parce que finalement celle de droite est devenue une ligne pointillée et vous ne pouviez pas voir le détail de, donc je l'ai redimensionnée. Il y a 20 ans, un gigaoctet de RAM était de l'ordre de six millions et demi de dollars. De nos jours, si vous payez plus de trois ou quatre dollars pour un gigaoctet de RAM pour le matériel de base, vous êtes volé.
Ces baisses importantes de réduction des prix au cours des deux dernières décennies ont signifié que nous pouvons maintenant aller au-delà de l'espace disque et directement dans la RAM, non seulement au niveau des mégaoctets, mais maintenant au niveau du téraoctet et traiter la RAM comme c'est le disque. Le défi avec cela, cependant, était que la RAM était nativement éphémère - cela signifie quelque chose qui dure pendant une courte période de temps - donc, nous avons dû trouver des moyens de fournir de la résilience dans cet espace.
Et donc, mon point ici est que l'informatique en mémoire n'est pas pour les timides. Jongler avec ces données en mémoire à très grande échelle et leur traitement est un défi intéressant; comme je l'ai indiqué plus tôt, ce n'est pas pour les timides. Donc, une chose que nous avons apprise de cette expérience avec le calcul en mémoire à grande échelle et à haute densité est que la complexité que nous construisons engendre des risques dans un certain nombre de domaines.
Mais regardons-le d'un point de vue de surveillance et de réponse. Lorsque nous pensons aux données, elles commencent dans l'espace disque, elles se trouvent dans des bases de données sur des disques, nous les poussons en mémoire. Une fois qu'il est en mémoire et distribué et qu'il existe des copies, nous pouvons en utiliser de nombreuses copies, et si des modifications sont apportées, il peut être reflété au niveau de la mémoire au lieu d'avoir à allumer et éteindre et à travers le fond de panier à deux niveaux différents, il entre et sort de la mémoire. Nous nous sommes retrouvés avec cette plate-forme matérielle hyperscale qui nous permet de le faire maintenant. Lorsque nous parlons d'hyperscaling, c'est plus difficile à des niveaux ridiculement denses, et de la mémoire à très haute densité, un nombre très élevé de CPU, de cœurs et de threads. Nous avons maintenant des pathologies de réseau très complexes pour prendre en charge cela, car les données doivent se déplacer à travers le réseau à un moment donné si elles doivent aller entre les nœuds et les clusters.
Donc, nous nous retrouvons avec la redondance des pannes de périphériques devenant un problème et nous devons surveiller les périphériques et des morceaux de celui-ci. Nous devons avoir une redondance résiliente des pannes de données intégrée à cette plate-forme et la surveiller. Nous devons avoir la résilience de base de données distribuée intégrée, nous devons donc surveiller la plate-forme de base de données et l'empiler à l'intérieur. Nous devons surveiller la planification du traitement distribué, ce qui se passe à l'intérieur de certains processus jusqu'à l'interrogation et la requête et le chemin que prend la requête et la façon dont la requête est structurée et exécutée. À quoi cela ressemble-t-il, quelqu'un a-t-il effectué un SELECT * sur «bla» ou a-t-il réellement effectué une requête très intelligente et bien structurée qui va lui fournir la quantité minimale et nominale de données provenant de l'architecture du fond de panier? Nous avons des charges de travail multi-locataires, plusieurs utilisateurs et plusieurs groupes exécutant la même ou plusieurs charges de travail et des travaux par lots et une planification en temps réel. Et nous avons ce mélange de traitement par lots et en temps réel. Certaines choses fonctionnent juste régulièrement - toutes les heures, tous les jours, toutes les semaines ou tous les mois - d'autres sont sur demande. Il se peut que quelqu'un soit assis avec une tablette et souhaite faire un rapport en temps réel.
Et encore une fois, nous arrivons à ce point entier, que la complexité qui se produit dans ces derniers n'est pas seulement un défi maintenant, c'est assez effrayant. Et nous avons cette vérification de la réalité qu'un seul problème de performance, un seul problème de performance en soi, peut avoir un impact sur l'ensemble de l'écosystème. Et donc, nous nous retrouvons avec ce défi très amusant de savoir, eh bien, où sont les impacts? Et nous avons ce défi de, sommes-nous réactifs ou proactifs? Sommes-nous en train de regarder la chose en temps réel et de voir que quelque chose se fait "bang" et d'y répondre? Ou avons-nous vu une certaine forme de tendance et réalisé que nous devons nous y impliquer de manière proactive? Parce que la clé est que tout le monde veut quelque chose de rapide, bon marché et facile. Mais nous nous retrouvons avec ces scénarios, ce à quoi j'aime me référer et ma ligne préférée de l'énigme Donald Rumsfeld - qui, selon moi, s'applique à tous ces scénarios de grande complexité - et c'est cela, nous avons connu des connus parce que c'est quelque chose nous avons conçu et construit et il fonctionne comme prévu. Nous avons des inconnues connues en ce que nous ne savons pas qui dirige quoi, quand et où, si c'est à la demande. Et nous avons des inconnues inconnues et ce sont les choses que nous devons surveiller et vérifier. Parce que la réalité est, nous le savons tous, que vous ne pouvez pas gérer quelque chose que vous ne pouvez pas mesurer.
Donc, pour avoir les bons outils et la bonne capacité pour surveiller la planification de notre CPU, recherchez les temps d'attente, découvrez pourquoi les choses doivent attendre dans les files d'attente de planification des pipelines. Que se passe-t-il dans la mémoire, quelle sorte d'utilisation est effectuée, quelle sorte de performance nous obtenons de la mémoire? Est-ce que les choses sont partitionnées correctement, sont-elles distribuées, avons-nous suffisamment de nœuds qui en conservent des copies pour faire face aux charges de travail qui y sont lancées? Que se passe-t-il avec l'exécution des processus loin des processus du système d'exploitation? Les travaux eux-mêmes en cours d'exécution, les applications individuelles et les démons qui les prennent en charge? Que se passe-t-il à l'intérieur de ces processus, en particulier la structuration des requêtes et comment ces requêtes sont-elles exécutées et compilées? Et la santé de ces processus tout au long de la pile? Vous savez, encore une fois, revenir aux temps d'attente, est-ce qu'il est correctement planifié, doit-il attendre, où attend-il, attend-il les lectures en mémoire, les E / S, le CPU, les E / S sur le réseau pour l'utilisateur final? ?
Et puis, revenons à ce point que je viens de mentionner juste avant de conclure et c'est-à-dire, comment abordons-nous la résolution des problèmes et les temps de réponse à ceux-ci? Sommes-nous en train de regarder en temps réel et de réagir aux choses, ce qui est le scénario le moins idéal, mais même dans ce cas, il vaut mieux que nous le fassions que de ne pas savoir et que le service d'assistance appelle et dise que quelque chose s'est mal passé et que nous devons le retrouver ? Ou le faisons-nous de manière proactive et examinons-nous ce qui s'en vient? En d'autres termes, voyons-nous que nous manquons de mémoire et devons ajouter plus de nœuds? Faisons-nous une analyse des tendances, faisons-nous une planification des capacités? Et dans tout cela, surveillons-nous les temps d'exécution historiques et pensons-nous à la planification de la capacité ou la surveillons-nous en temps réel et replanifions-nous de manière proactive et effectuons-nous l'équilibrage de charge? Et sommes-nous conscients des charges de travail qui s'exécutent en premier lieu? Savons-nous qui fait quoi dans notre cluster et pourquoi?
Les calculs en mémoire sont très puissants, mais avec cette puissance, c'est presque une de ces choses, comme un pistolet chargé et vous jouez avec des munitions réelles. Vous pouvez éventuellement vous tirer une balle dans le pied si vous ne faites pas attention. Ainsi, cette puissance de calcul en mémoire signifie simplement que nous pouvons exécuter beaucoup plus et rapidement sur des ensembles de données très distribués et discrets. Mais alors cela a alors une demande plus élevée provenant des utilisateurs finaux. Ils s'habituent à ce pouvoir et ils le veulent. Ils ne s'attendent plus à ce que les travaux prennent des semaines à s'exécuter et les rapports apparaissent dans du vieux papier ordinaire. Et puis, sous tout cela, nous avons la maintenance quotidienne entourée de correctifs, de mises à jour et de mises à niveau. Et si vous pensez au traitement 24h / 24 et 7j / 7 avec le calcul en mémoire, la gestion de ces données, la gestion des charges de travail à travers elles, tout est en mémoire, techniquement sur la plateforme éphémère, si nous allons commencer à appliquer des correctifs et des mises à jour et des mises à niveau dans là, cela s'accompagne de toute une série d'autres défis de gestion et de surveillance. Nous devons savoir ce que nous pouvons mettre hors ligne, quand nous pouvons le mettre à niveau et quand nous le remettons en ligne. Et cela m'amène à mon dernier point: à mesure que nous devenons de plus en plus complexes dans ces systèmes, ce n'est pas quelque chose qu'un humain peut faire simplement en suçant son pouce et en tirant son oreille. Il n'y a plus, en quelque sorte, d'approches intestinales. Nous avons vraiment besoin des outils appropriés pour gérer et fournir ce haut niveau de performances en matière de calcul et de gestion des données.
Et dans cet esprit, je vais céder la parole à notre ami d'IDERA et entendre comment ils ont abordé ce défi.
Bill Ellis: Merci beaucoup. Je partage mon écran et c'est parti. Donc, c'est vraiment humiliant de ne considérer que toutes les technologies, et toutes les personnes qui nous ont précédés, pour rendre ces choses disponibles en 2017, disponibles. Nous allons parler de l'analyse de la charge de travail pour SAP HANA - essentiellement, une solution de surveillance de base de données: complète, sans agent, fournit en temps réel et construit une histoire, et ainsi vous pouvez voir ce qui s'est passé dans le passé. SAP S / 4 HANA offre le potentiel de meilleur, plus rapide et moins cher. Je ne dis pas que c'est bon marché, je dis juste que c'est moins cher. En quelque sorte, ce qui se passait traditionnellement était que vous disposiez d'une instance de production principale - probablement exécutée sur Oracle dans un magasin plus grand, potentiellement SQL Server - et ensuite vous utilisiez ce processus ETL et vous disposiez de plusieurs versions de la vérité . Et cela coûte très cher car vous payiez pour le matériel, le système d'exploitation, la licence Oracle pour chacun de ces environnements individuels. Et puis en plus de cela, il faudrait que les gens réconcilient une version de la vérité avec la version suivante de la vérité. Et donc, ce traitement ETL à plusieurs versions était juste lent et très, très lourd.
Et donc, HANA, essentiellement une instance HANA, peut potentiellement remplacer toutes ces autres instances. Donc, c'est moins cher car c'est une plate-forme matérielle, un système d'exploitation, au lieu de multiples. Et donc le S / 4 HANA, vraiment, il change tout et vous regardez essentiellement l'évolution de SAP de R / 2 à R / 3, les différents packs d'améliorations. Maintenant, le système hérité est disponible jusqu'en 2025, vous avez donc huit ans avant d'être vraiment obligé de migrer. Bien que nous voyions des gens, vous savez, se tremper dans les pieds parce qu'ils savent que cela arrive et, finalement, vous savez, ECC fonctionnera sur HANA et vous devrez donc vraiment vous y préparer et comprendre la technologie.
Donc, une base de données, pas de processus ETL, pas de copies à réconcilier. Donc, encore une fois, plus vite, mieux et moins cher. HANA est en mémoire. SAP fournit le logiciel, vous fournissez le matériel. Il n'y a pas de tables agrégées. L'une des choses qu'ils suggèrent, en quelque sorte, lorsque vous pensez à cela, c'est que vous ne voulez pas vous lancer, nous allons simplement acheter le plus grand serveur disponible. Ils suggèrent que vous, en quelque sorte, dimensionnez correctement votre paysage SAP à l'avance et ils disent essentiellement, ne migrez pas 20 années de données. Je pense que l'archivage est quelque chose qui est sous-utilisé dans l'informatique, dans l'ensemble, pas seulement dans les magasins SAP. Et donc la prochaine chose est que SAP a réellement passé beaucoup de temps à réécrire son code natif pour ne pas utiliser SELECT *. SELECT * renvoie toutes les colonnes de la table et c'est particulièrement cher dans une base de données en colonnes. Et donc, ce n'est pas une bonne idée pour SAP HANA. Donc, pour les magasins qui ont beaucoup de personnalisation, beaucoup de rapports, c'est quelque chose que vous voudrez rechercher et vous voudrez spécifier des noms de colonnes au fur et à mesure de votre migration vers HANA.
Nous aimons dire que HANA n'est pas une panacée. Comme toutes les bases de données, toutes les technologies, il doit être surveillé, et comme mentionné précédemment, vous avez besoin de chiffres pour gérer les excès, mesure par mesure. Et l'une des choses dont je parle dans le domaine IDERA est que chaque transaction commerciale interagit avec le système d'enregistrement, et dans ce cas, ce sera HANA. Et ainsi, HANA devient le fondement de la performance de vos transactions SAP, l'expérience de l'utilisateur final. Et donc, il est essentiel qu'il continue de fonctionner à vitesse maximale. Cela devient un seul point d'échec, et en parlant aux gens, c'est quelque chose qui peut surgir là où vous avez un utilisateur final et peut-être utiliser ces données en temps réel et ils ont une requête ad hoc qui n'est potentiellement pas tout à fait droite. Peut-être qu'ils ne rejoignent pas les tables et qu'ils ont créé une jointure externe, un produit partisan, et qu'ils consomment essentiellement beaucoup de ressources. Maintenant, HANA le reconnaîtra finalement et tuera cette session. Et donc il y a la partie cruciale de notre architecture qui va vous permettre de réellement capturer cela dans l'histoire, afin que vous puissiez voir ce qui s'est passé dans le passé et reconnaître ces situations.
Jetons donc un coup d'œil à l'analyse de la charge de travail pour SAP HANA. Ceci est la version 1, nous vous invitons donc vivement à nous rejoindre dans le voyage, et ceci est un produit IDERA. C'est complet, mais simple. En temps réel avec tendance. Santé de l'hôte, santé de l'instance. Nous suivons les états d'attente, les requêtes SQL, les consommateurs de mémoire et les services. Voici donc à quoi ressemble l'interface graphique et vous pouvez voir dès le départ qu'elle est activée sur le Web. J'ai en fait ouvert cette solution en cours d'exécution sur mon système. Il y a des choses cruciales que vous voulez regarder. Nous avons, en quelque sorte, subdivisé en différents espaces de travail. Le type le plus crucial est ce qui se passe au niveau de l'hôte à partir d'une utilisation du processeur et de la mémoire. Vous ne voulez certainement pas passer à un point de vue d'échange ou de raclée. Et ensuite, vous travaillez essentiellement sur ce qui se passe dans les tendances, à partir du temps de réponse, des utilisateurs, des instructions SQL, c'est-à-dire de ce qui stimule l'activité sur le système.
L'une des choses avec IDERA est que, vous savez, rien ne se passe sur une base de données tant qu'il n'y a pas d'activité. Et cette activité sont des instructions SQL qui proviennent de l'application. Ainsi, la mesure des instructions SQL est absolument vitale pour pouvoir détecter la cause première. Alors, allons-y et explorons. Ainsi, au niveau de l'hôte, nous pouvons réellement jeter un œil à la mémoire, suivre au fil du temps, utiliser le processeur de l'hôte. Revenez en arrière, vous pouvez regarder les instructions COBSQL. Maintenant, l'une des choses que vous allez voir dans notre côté architecture est que ces informations sont stockées hors de HANA, donc si quelque chose devait arriver à HANA, nous capturons essentiellement des informations jusqu'à, Dieu nous en préserve, une situation d'indisponibilité . Nous pouvons également capturer tout ce qui se passe sur le système afin que vous ayez une visibilité claire. Et l'une des choses que nous allons faire est de présenter les instructions SQL dans un ordre pondéré. Donc, cela va prendre en compte le nombre d'exécutions, et c'est donc la consommation de ressources agrégée.
Et vous pouvez donc entrer dans les mesures individuelles ici - quand cette instruction SQL s'est-elle exécutée? Et puis, la consommation de ressources est largement motivée par le plan d'exécution, et nous sommes donc en mesure de capturer cela de manière continue. HANA est en mémoire. C'est très parallèle. Il a des index principaux sur chaque table, que certains magasins choisissent de créer un index secondaire pour résoudre certains problèmes de performances. Et donc, en quelque sorte, savoir ce qui s'est passé avec le plan d'exécution pour certaines instructions SQL peut être très précieux. Nous allons également regarder les services, la consommation de mémoire une fois de plus, tracée au fil du temps. L'architecture: il s'agit donc d'une solution autonome que vous pouvez télécharger à partir de notre site Web et l'architecture est qu'elle est compatible avec le Web.
Vous pouvez demander à plusieurs utilisateurs de se connecter à une instance particulière. Vous pouvez surveiller les instances locales de SAP HANA. Et nous conservons un historique continu de quatre semaines dans notre référentiel et c'est autogéré. Pour déployer cela, c'est plutôt simple. Vous avez besoin d'un serveur Windows. Vous devez le télécharger. La plupart des serveurs Windows auront un framework .NET intégré et il est fourni avec une licence. Et donc vous iriez à l'assistant d'installation qui est piloté par Setup.exe et il ouvrirait en fait un écran, un accord de licence, et vous travailleriez simplement dans ce plan en cliquant sur "Suivant". Et donc, où voulez-vous que HANA être installé? Viennent ensuite les propriétés de la base de données, et ce sera votre connexion à SAP HANA, il s'agit donc de la surveillance sans agent de l'instance HANA. Et puis nous donnerons essentiellement un aperçu, c'est le port sur lequel nous communiquons par défaut. Cliquez sur "Installer" et il démarre essentiellement HANA et vous commencez à construire l'historique. Donc, juste un peu des informations du tableau des tailles. Nous pouvons surveiller jusqu'à 45 instances HANA, et vous voudrez les utiliser, en quelque sorte, sur une échelle mobile pour déterminer le nombre de cœurs, la mémoire et l'espace disque dont vous aurez besoin. Et cela suppose que vous ayez un historique complet de quatre semaines.
Donc, juste pour récapituler rapidement, nous examinons la santé du serveur, la santé des instances, l'utilisation du processeur / de la mémoire. Quels sont les consommateurs de mémoire, quels sont les moteurs d'activité, quels sont les services? Les instructions SQL sont vitales - quels sont les états d'exécution? Montrez-moi les plans d'exécution, quand les choses se sont-elles exécutées, fournissent-elles des tendances? Cela vous donnera en temps réel et un historique de ce qui s'était passé. Et comme je l'ai mentionné, parce que notre histoire est distincte de HANA, nous allons capturer des choses qui avaient expiré et avaient été vidées de l'histoire de HANA. Pour que vous puissiez voir la véritable consommation de ressources sur votre système en raison de l'historique séparé.
Ainsi, comme je l'avais mentionné, le site Web d'IDERA, sous Produits, vous pouvez facilement le trouver. Si vous voulez l'essayer, vous êtes certainement le bienvenu. Voyez comment il vous fournit des informations et il y a des informations supplémentaires sur ce site Web. Donc, toutes les parties intéressées sont plus qu'heureuses de s'y atteler. Maintenant, dans les produits de portefeuille offerts par IDERA, il y a aussi un moniteur de transactions SAP ECC, et cela s'appelle Precise for SAP. Et ce qu'il fait - que vous utilisiez un portail ou simplement ECC directement - il capturera réellement la transaction de l'utilisateur final d'un clic sur le disque, tout le long de l'instruction SQL et vous montrera ce qui se passe.
Maintenant, je vous montre juste un écran de résumé. Il y a quelques points à retenir que je veux que vous ayez de cet écran de résumé. C'est le temps de réponse de l'axe Y, le temps de l'axe X plus le jour, et dans cette vue de transaction, nous vous montrerons l'heure du client, l'heure de la file d'attente, l'heure du code ABAP, l'heure de la base de données. Nous pouvons capturer les identifiants des utilisateurs finaux, les codes T et vous pouvez réellement filtrer et afficher les serveurs via une transaction particulière traversée. Et donc, de nombreux magasins gèrent l'avant du paysage sous VMware, vous pouvez donc réellement mesurer ce qui se passe sur chacun des serveurs et entrer dans une analyse très détaillée. Ainsi, cette vue de transaction est destinée à la transaction de l'utilisateur final dans l'ensemble du paysage SAP. Et vous pouvez le trouver sur notre site Web sous Produits APM Tools et ce serait la solution SAP que nous avons. L'installation est un peu plus compliquée, donc ce n'est pas seulement le télécharger et l'essayer, comme nous l'avons fait pour HANA. C'est quelque chose où nous travaillerions ensemble pour faire, concevoir et mettre en œuvre la transaction globale pour vous.
Ainsi, juste un troisième récapitulatif rapide, analyse de la charge de travail pour SAP HANA, il est complet, sans agent, en temps réel, offre un historique. Nous offrons la possibilité de le télécharger et de l'essayer pour votre site.
Donc, avec ça, je vais passer le temps à Eric, Dez et le Dr Bloor.
Eric Kavanagh: Ouais, peut-être Robin, des questions de ta part, et ensuite Dez après Robin?
Dr Robin Bloor: D'accord. Je veux dire, la première chose que je voudrais dire, c'est que j'aime vraiment la vue des transactions, car c'est exactement ce que je voudrais dans cette situation. J'ai fait beaucoup de travail - eh bien, il y a longtemps en ce moment - faisant de la surveillance des performances, et c'était le genre de chose; nous n'avions pas les graphismes à cette époque, mais c'était le genre de chose que je voulais particulièrement pouvoir faire. Pour que vous puissiez, d'une manière ou d'une autre, vous injecter là où le problème se produit.
La première question que j'ai est, vous savez, la plupart des gens mettent en œuvre le S / 4 d'une manière ou d'une autre, vous savez. Lorsque vous vous impliquez dans une implémentation donnée de S / 4, avez-vous découvert qu'elle a bien été implémentée ou vous retrouvez-vous, vous savez, à découvrir des choses qui pourraient donner envie au client de se reconfigurer? Je veux dire, comment ça se passe?
Bill Ellis: Eh bien, chaque magasin est un peu différent. Et il y a différents modèles d'utilisation, il y a différents rapports. Pour les sites qui ont des rapports ad hoc, je veux dire que c'est en fait, un peu comme un caractère générique sur le système. Et donc, l'une des choses cruciales est de commencer la mesure et de découvrir quelle est la base de référence, ce qui est normal pour un site particulier, où se trouve ce site particulier, en fonction de leurs modèles d'utilisation, qui met le système à rude épreuve. Et puis faites des ajustements à partir de là. Généralement, l'optimisation de la surveillance n'est pas ponctuelle, c'est vraiment une pratique continue où vous surveillez, ajustez, perfectionnez, améliorant le système pour que la communauté des utilisateurs finaux puisse servir l'entreprise plus efficacement.
Dr. Robin Bloor: D'accord, donc quand vous implémentez - je veux dire, je sais que c'est une question difficile à répondre car cela va varier en fonction de la taille de l'implémentation - mais combien de ressources la capacité de surveillance IDERA, combien consomme-t-elle ? Cela fait-il une différence ou est-ce que cela n'interfère pas? Comment ça marche?
Bill Ellis: Oui, je dirais que les frais généraux sont d'environ 1 à 3%. De nombreux magasins sont très disposés à sacrifier cela, car vous pourrez potentiellement le racheter en termes d'optimisation. Cela dépend des modèles d'utilisation. Si vous faites un paysage complet, cela dépend des technologies individuelles qui sont surveillées. Donc, en quelque sorte, le kilométrage varie, mais comme nous en avons parlé, il vaut certainement mieux dépenser un peu pour savoir ce qui se passe, que de simplement courir à l'aveugle. En particulier, vous savez, nous sommes ici en janvier et vous vous lancez dans le traitement de fin d'année et vous agrégez 12 mois de données. Vous savez, c'est faire de la performance, envoyer des rapports aux organismes de réglementation, aux banques, aux actionnaires, est absolument vital dans une performance commerciale critique.
Dr Robin Bloor: D' accord. Et juste un rapide, de votre point de vue - parce que je suppose que vous êtes impliqué dans toute une série de sites SAP - quelle est l'ampleur du mouvement parmi la base de clients SAP vers S / 4? Je veux dire, est-ce quelque chose qui est, vous savez, qu'il y a une sorte d'avalanche de clients enthousiastes, ou est-ce juste un filet régulier? Comment voyez-vous cela?
Bill Ellis: Je pense qu'il y a quelques années, je dirais que c'était un orteil. Maintenant, je dirais que les gens sont à genoux. Je pense que, vous savez, étant donné la chronologie, les gens vont être vraiment immergés dans HANA au cours des deux prochaines années. Et donc le suivi, la transformation, vous savez, je pense que la majorité des clients sont, en quelque sorte, sur la courbe d'apprentissage ensemble. Et donc je pense que nous ne sommes pas tout à fait à l'avalanche comme vous l'aviez dit, mais je pense que nous sommes à l'aube de la transformation majeure vers HANA.
Dr Robin Bloor: D'accord, donc en ce qui concerne les sites que vous avez vus qui ont opté pour cela, adaptent-ils également HANA pour d'autres applications ou sont-ils, d'une manière ou d'une autre, complètement consommés pour faire cela ça marche? Quelle est l'image ici?
Bill Ellis: Oui, souvent, les gens intégreront SAP à d'autres systèmes, selon les modules, etc., donc il y en a un peu. Je ne vois pas vraiment de gens déployer d'autres applications sur HANA pour l'instant. C'est certainement possible de le faire. Et c'est donc plus autour du paysage autour de l'infrastructure SAP.
Dr Robin Bloor: Je suppose que je ferais mieux de vous remettre à Dez. J'ai accaparé votre temps. Dez?
Dez Blanchfield: Merci. Non, c'est tout bon. Deux très rapides, juste pour essayer de définir le thème. SAP HANA est sorti depuis quelques années maintenant et les gens ont eu l'occasion de le considérer. Si vous deviez nous donner une estimation approximative du pourcentage de gens qui le dirigent - parce qu'il y a beaucoup de gens qui dirigent ce genre de choses - que pensez-vous du pourcentage du marché que vous connaissez actuellement qui a disparu des implémentations SAP traditionnelles à SAP sur HANA? Regardons-nous 50/50, 30/70? Quel pourcentage du marché voyez-vous des gens qui ont fait la transition et qui ont fait le pas maintenant par rapport aux gens qui se contentent de retenir et attendent que les choses s'améliorent ou s'améliorent ou changent ou quoi que ce soit?
Bill Ellis: Oui, je mettrais en fait, de mon point de vue, je mettrais le pourcentage autour de 20%. SAP a tendance à être des entreprises traditionnelles. Les gens ont tendance à être très conservateurs et leur peuple va donc traîner les pieds. Je pense que cela dépend aussi, vous savez, avez-vous utilisé SAP depuis longtemps, ou êtes-vous, une sorte de PME qui a peut-être déployé SAP plus récemment? Et donc, il y a un certain nombre de facteurs, mais dans l'ensemble, je ne pense pas que le pourcentage soit de 50/50. Je dirais que 50% sont au moins barboteurs et que HANA fonctionne quelque part dans leur centre de données.
Dez Blanchfield: La conclusion intéressante que vous nous avez donnée plus tôt est que c'est un fait accompli dans un sens et que l'horloge tourne physiquement et littéralement au moment de la transition. Dans le processus, pensez-vous que les gens ont pensé à cela? Quel est le sentiment général que les gens comprennent qu'il s'agit d'un changement transitoire de plate-forme, ce n'est pas seulement une option, il devient la valeur par défaut?
Et du point de vue de SAP, je suis sûr qu'ils poussent dans ce sens car il y a un avantage concurrentiel significatif dans les performances, mais c'est aussi, je suppose, qu'ils reprennent le contrôle de la plate-forme au lieu de passer à un tiers- base de données du parti, ils le ramènent maintenant à leur propre plate-forme. Pensez-vous que les entreprises ont réellement compris ce message? Pensez-vous que les gens comprennent cela et qu'ils s'y adaptent maintenant? Ou est-ce encore, en quelque sorte, une chose peu claire, pensez-vous, en dehors du marché?
Bill Ellis: Je ne pense pas que le SAP hésite à communiquer et les gens qui sont allés à SAPPHIRE ont vu HANA partout. Donc, je pense que les gens sont bien conscients, mais la nature humaine étant ce qu'elle est, vous savez, certaines personnes se traînent un peu les pieds.
Dez Blanchfield: Parce que je pense que la raison pour laquelle je posais cette question, et vous devrez me pardonner, mais c'est que je suis d'accord. Je pense qu'ils n'ont pas hésité à le communiquer. Je pense que le signal est sorti de plusieurs façons. Et je suis d'accord avec vous - je ne sais pas encore tout le monde a sauté. Vous savez, les entreprises traditionnelles, les très grandes entreprises qui gèrent cela, sont encore à bien des égards, ne se traînant pas tout à fait les pieds, mais essayant simplement de faire face à la complexité du changement. Parce que je pense que la seule chose que votre outil, et certainement votre démonstration d'aujourd'hui a mise en évidence, et pour moi, un point clé que j'aimerais que tout le monde écoute et écoute aujourd'hui pour s'asseoir et faire attention à la réflexion, c'est que vous avez un outil maintenant qui a simplifié ce processus dans mon esprit. Je pense qu'il y a un tas de DSI très nerveux et leurs équipes sous eux qui pensent: «Comment faire la transition des SGBDR traditionnels, des systèmes de gestion de bases de données relationnelles, que nous connaissons depuis des décennies, à un tout nouveau paradigme de calcul et la gestion du stockage dans un espace encore relativement courageux? »dans mon esprit. Mais c'est une inconnue à bien des égards, et il y a très peu de gens qui ont fait ce changement dans d'autres domaines, ce n'est pas comme s'ils avaient un autre secteur d'activité qui était déjà passé au calcul en mémoire. C'est donc un mouvement tout ou rien dans leur esprit.
Donc, l'une des choses que j'ai retirées de cela plus que tout - je vais vous frapper avec une question dans une minute - est que la peur maintenant, je pense, est apaisée de nombreuses façons et qu'avant aujourd'hui, si j'étais un DSI écoutant, je penserais en quelque sorte: «Eh bien, comment vais-je faire cette transition? Comment vais-je garantir la même capacité que nous avons dans la plate-forme de gestion de base de données relationnelle et des années d'expérience des administrateurs de base de données, à une nouvelle plate-forme dans laquelle nous n'avons pas actuellement les compétences? »Donc, ma question à ce sujet est, pensez-vous que les gens ont compris que les outils sont là avec ce que vous proposez et qu'ils peuvent, en quelque sorte, prendre une profonde inspiration et soupirer de soulagement que la transition ne soit pas aussi effrayante qu'elle aurait pu l'être avant à cet outil étant disponible? Pensez-vous que les gens ont compris cela ou est-ce toujours une sorte de problème avec la transition vers le calcul en mémoire et le stockage en mémoire par rapport aux combinaisons old-school de NVMe, flash et disque?
Bill Ellis: Oui, il y a donc sans aucun doute beaucoup de technologies et d'outils qui peuvent afficher graphiquement cela, ce qui se passe et le rendre très facile à localiser les principaux consommateurs de ressources. Je veux dire, cela aide à simplifier les choses et cela aide le personnel technologique à vraiment bien gérer. Hé, ils vont pouvoir savoir ce qui se passe et être capables de comprendre toute la complexité. Donc, absolument, les outils sur le marché sont vraiment utiles et nous proposons donc une analyse de la charge de travail pour SAP HANA.
Dez Blanchfield: Oui, je pense que la grande chose à propos de ce que vous nous avez montré aujourd'hui est que, dans la surveillance de la partie matérielle, la partie du système d'exploitation, même la surveillance d'une partie de la charge de travail qui se déplace, comme vous l'avez dit, je veux dire, les outils sont là depuis un certain temps. Le plus pour moi, en particulier dans les goûts de HANA, c'est que nous n'avons pas nécessairement eu la possibilité d'obtenir une loupe et de jeter un œil dessus et de voir jusqu'à quel point votre outil fait ce qui se passe avec les requêtes et comment elles sont être structuré et où cette charge est.
Avec les déploiements que vous avez vus jusqu'à présent, étant donné que vous êtes littéralement le plus autoritaire dans cet espace de votre plate-forme dans le monde, certaines des victoires rapides que vous avez vues - avez-vous des connaissances anecdotiques avec lesquelles vous pouvez partager nous autour de certains des moments eureka, les moments aha, où les gens ont déployé le jeu d'outils IDERA, ils ont trouvé des choses dont ils n'étaient tout simplement pas conscients dans leurs plates-formes et leurs performances. Avez-vous de bons exemples anecdotiques où les gens viennent de le déployer, ne sachant pas vraiment ce qu'ils ont eu et tout d'un coup, "Wow, nous ne savions pas en fait que c'était là-dedans?"
Bill Ellis: Ouais, donc une grande limitation des outils natifs est que si une requête galopante est annulée, elle vide les informations et donc vous n'avez fondamentalement pas l'historique. En stockant l'historique hors ligne, comme une requête galopante, vous aurez un historique, vous saurez ce qui s'est passé, vous pourrez voir le plan d'exécution et ainsi de suite. Et donc, cela vous permet, en quelque sorte, d'aider la communauté des utilisateurs finaux à mieux fonctionner, à mieux écrire des rapports, etc. Et donc, l'histoire est quelque chose de vraiment agréable à avoir. Et l'une des choses que je voulais montrer est que vous pouvez regarder en temps réel jusqu'à quatre semaines, puis vous pouvez facilement zoomer sur n'importe quelle période d'intérêt, puis exposer l'activité de conduite sous-jacente. Le simple fait d'avoir cette visibilité est très utile pour savoir quel goulot d'étranglement s'est produit.
Dez Blanchfield: Vous avez mentionné qu'il est multi-utilisateur, une fois qu'il est déployé, et j'ai été très impressionné par le fait qu'il est sans agent et sans contact à bien des égards. Est-il normal qu'un seul déploiement de votre outil soit alors disponible pour tout le monde depuis le centre d'opérations réseau du NOC qui surveille l'infrastructure de base sous-tendant le cluster jusqu'à l'équipe d'application et de développement? Est-ce la norme et vous déployez une fois et ils partageraient cela, ou pensez-vous que les gens pourraient avoir des instances de modèle examinant différentes parties de la pile? A quoi cela ressemble-t-il?
Bill Ellis: Donc, l'équipe de base sera généralement très intéressée par les fondements technologiques de ce qui se passe dans SAP. Évidemment, il y a plusieurs équipes qui prendront en charge des paysages entiers. La pièce HANA se concentre uniquement sur cela. Je vais simplement par défaut à l'équipe de base SAP en tant que principaux consommateurs des informations.
Dez Blanchfield: D'accord . Cela me frappe, cependant, que si j'ai une équipe de développement ou pas seulement au niveau du code, mais si j'ai une équipe de scientifiques des données ou d'analystes qui effectuent un travail analytique sur les ensembles de données là-dedans, d'autant plus qu'il y a une impulsion significative pour que la science des données soit appliquée à tout ce qui se passe au sein des organisations maintenant, dans mon esprit - et corrigez-moi si je me trompe - il me semble que cela va également les intéresser beaucoup, car parmi les choses sérieuses que vous pouvez faire dans un environnement d'entrepôt de données, déclenchez un scientifique des données dessus et permettez-lui de commencer à faire des requêtes ad hoc. Avez-vous eu des exemples de ce genre de choses qui se produisent où les magasins vous ont sonné et ont dit: «Nous avons jeté une équipe de science des données sur la chose, ça fait vraiment mal, que pouvons-nous faire pour eux par rapport à ce que nous faisons juste surveillance et gestion opérationnelles traditionnelles? »Est-ce même une chose?
Bill Ellis: Eh bien, oui, je tournerais cela un peu et couperais ma réponse serait que, en regardant les performances, en étant conscient des performances dans le développement de la production d'assurance qualité, vous savez, plus tôt vous stockez, moins de problèmes, moins surprises que vous avez. Donc, absolument.
Dez Blanchfield: Suite à cela, beaucoup d'outils avec lesquels j'ai eu de l'expérience - et je suis sûr que Robin sera d'accord - beaucoup d'outils ici, si vous avez un grand SGBDR, vous avez vraiment besoin DBA qualifiés, profondément informés et expérimentés. Certaines des exigences d'infrastructure et de plate-forme qui accompagnent SAP HANA, car il est actuellement pris en charge sur des distributions particulières alignées à partir de matériel particulier et ainsi de suite, au meilleur de ma connaissance. Vous savez, il y a des gens avec des décennies d'expérience qui ne sont pas les mêmes. Ce que je vois, cependant, c'est que ce n'est pas nécessairement l'exigence avec cet outil. Il me semble que vous pouvez déployer votre outil et le donner à des visages assez nouveaux et leur donner immédiatement le pouvoir de trouver des choses qui ne fonctionnent pas bien. Est-il vrai qu'il existe une courbe d'apprentissage assez courte pour se mettre au courant de cela et tirer parti de son déploiement? Vous savez, mon sentiment général est que vous n'avez pas besoin d'avoir 20 ans d'expérience dans la conduite d'un outil pour voir la valeur immédiatement. Seriez-vous d'accord pour dire que c'est le cas?
Bill Ellis: Oh absolument, et à votre propos, je pense qu'une grande partie du succès d'un déploiement dépend vraiment de la planification et de l'architecture de l'environnement SAP HANA. Et puis il y a sans aucun doute beaucoup de complexité, beaucoup de technologies sur lesquelles il est construit, mais cela se résume à surveiller les modèles d'utilisation de ce qui se passe. Donc, bien qu'il soit plus complexe, il est en quelque sorte emballé et quelque peu simplifié. C'est un très pauvre.
Dez Blanchfield: Oui, donc avant de revenir à Eric, parce que je sais qu'il a quelques questions, en particulier de certaines qui ont été posées par le biais de questions et réponses qui semblaient intéressantes, et je suis impatient d'entendre la réponse. Voyage traditionnel pour quelqu'un à - vous avez mentionné plus tôt que vous pouvez l'obtenir, vous pouvez le télécharger et l'essayer. Pouvez-vous récapituler rapidement pour les gens qui écoutent aujourd'hui ou ceux qui pourraient les rejouer plus tard? Quelles sont les deux ou trois étapes rapides pour mettre la main sur une copie, la déployer et l'essayer dans leur environnement avant de l'acheter? A quoi cela ressemble-t-il? Quelles sont les étapes pour cela?
Bill Ellis: Ouais. Alors, IDERA.com et accédez simplement aux produits et vous verrez l'analyse de la charge de travail pour SAP HANA. Il y a une page de téléchargement. Je pense qu'ils vous demanderont des informations de contact et le produit est simplement emballé avec une clé de licence afin que vous puissiez l'installer avec Setup.exe et simplement lancer, je pense, très rapidement.
Dez Blanchfield: Donc, ils peuvent aller sur votre site Web, ils peuvent le télécharger. Je me souviens l'avoir regardé il y a quelque temps et j'ai revérifié hier soir également, vous pouvez demander une démo, de mémoire, où quelqu'un de votre équipe vous guidera en quelque sorte? Mais vous pouvez le télécharger gratuitement et le déployer localement dans votre propre environnement, à votre rythme, n'est-ce pas?
Bill Ellis: Oui.
Dez Blanchfield: Excellent. Eh bien, je pense que, plus que tout, c'est probablement la chose que je conseillerais personnellement aux gens de faire, c'est de récupérer une copie du site Web, de récupérer une partie de la documentation là-bas parce que je sais qu'il y a beaucoup de bon contenu là-dessus pour le faire, et essayez-le. Mettez-le dans votre environnement et voyez ce que vous trouvez. Je soupçonne qu'une fois que vous aurez jeté un coup d'œil sous vos hottes avec vos environnements SAP HANA avec l'outil IDERA, vous allez trouver des choses que vous ignoriez réellement.
Écoutez, merci beaucoup pour cela et merci pour le temps juste pour les questions et réponses avec Robin et moi. Eric, je vais vous revenir parce que je sais que certaines questions et réponses viennent également de nos participants.
Eric Kavanagh: Oui, juste un très rapide ici. Ainsi, l'un des participants fait un très bon commentaire ici juste en parlant de la façon dont les choses changent. Dire par le passé, la mémoire était en train de s'étouffer, ralentissant par une pagination fréquente, actuellement le CPU s'étouffe avec trop de données en mémoire. Vous savez, il y a des problèmes de réseau. Ça va toujours être une cible mouvante, non? Quelle est, selon vous, la trajectoire de nos jours en ce qui concerne les goulots d'étranglement et où vous devrez concentrer votre attention?
Bill Ellis: Ouais. Jusqu'à ce que vous mesuriez, c'est difficile à savoir. L'une des choses au sujet des instructions SQL est qu'elles vont être les moteurs de la consommation des ressources. Et donc dans le cas où vous deviez avoir, comme une grande consommation de mémoire ou une consommation de CPU, vous serez en mesure de déterminer quelle activité a causé cette consommation de ressources. Maintenant, vous ne voudriez pas nécessairement le tuer, mais vous voulez aussi en être conscient et, en quelque sorte, ce qui se passe, à quelle fréquence cela se produit, etc. Nous sommes, en quelque sorte, encore nouveaux en termes de réponse à l'ensemble ou au livre de cuisine des réponses à différentes circonstances. Et donc, c'est une excellente question et le temps nous le dira. Nous aurons plus d'informations au fil du temps.
Eric Kavanagh: C'est ça. Eh bien, vous êtes dans un espace très intéressant. Je pense que vous allez voir beaucoup d'activité au cours des prochains mois et des prochaines années, car je sais que SAP, comme vous l'avez suggéré dans notre appel de contenu, a fourni une longue rampe d'accès pour permettre aux gens de faire la transition. à HANA. Mais néanmoins, cette rampe a une fin et à un moment donné les gens vont devoir prendre des décisions sérieuses, donc le plus tôt sera le mieux, non?
Bill Ellis: Absolument.
Eric Kavanagh: Très bien, nous avons passé une autre heure ici sur Hot Technologies. Vous pouvez trouver des informations en ligne, insideanalysis.com, ainsi que techopedia.com. Concentrez-vous sur ce site pour de nombreuses informations intéressantes, y compris une liste de toutes nos archives de ces webémissions passées. Mais les gens, un grand merci à vous tous là-bas, à nos amis de l'IDERA, à Robin et bien sûr, Dez. Et nous vous rattraperons la semaine prochaine, les amis. Merci encore pour votre temps et votre attention. Prends soin de toi. Bye Bye.
