Door Techopedia Staff, 25 januari 2017
Takeaway: gastheer Eric Kavanagh bespreekt in-memory computing en SAP HANA met gasten Dr. Robin Bloor, Dez Blanchfield en IDERA's Bill Ellis.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Oké, dames en heren. Hallo en welkom weer. Het is vier uur Eastern Time op een woensdag en de laatste paar jaar betekent dat het weer tijd is voor Hot Technologies. Ja, inderdaad, mijn naam is Eric Kavanagh, ik zal uw gastheer zijn voor het gesprek van vandaag.
En mensen, we gaan het vandaag hebben over coole dingen. We duiken in de wereld van in-memory, de exacte titel is "Into the Future: An On-Ramp for In-Memory Computing." Tegenwoordig is het een grote woede, en met goede reden, vooral omdat in- geheugen is zoveel sneller dan vertrouwen op draaiende schijven. De uitdaging is echter dat je veel software moet herschrijven. Omdat de software van vandaag voor het grootste deel is geschreven met schijf in gedachten en dat verandert echt de architectuur van de applicatie. Als u de toepassing ontwerpt om te wachten op een draaiende schijf, doet u dingen gewoon anders dan als u over al die kracht van in-memory-technologie beschikt.
Er is echt een plekje in de jouwe, sla me op Twitter, @eric_kavanagh. Ik probeer altijd terug te volgen en ook te retweeten wanneer iemand me noemt.
Zoals ik al zei, we hebben het vandaag over geheugen, en specifiek over SAP HANA. De jouwe hebben het afgelopen jaar echt kennisgemaakt met de SAP-gemeenschap en het is een fascinerende omgeving, moet ik zeggen. Petje af voor de mensen die die operatie uitvoeren en in de frontlinie staan, omdat SAP een ongelooflijk goede operatie is. Waar ze echt heel goed in zijn, is zakendoen. Ze zijn natuurlijk ook geweldig in technologie en ze hebben echt een zware investering in HANA gedaan. Ik kan me zelfs herinneren - het was waarschijnlijk ongeveer zes of zeven jaar geleden - dat we eigenlijk wat werk voor de Amerikaanse luchtmacht aan het doen waren, en we kregen iemand van SAP om binnen te komen en ons een vroege blik te geven op de wereld van HANA en wat was gepland. En op zijn zachtst gezegd, de mensen bij SAP Labs hadden veel tijd en moeite gestoken in het begrijpen van hoe deze architectuur te bouwen, die weer compleet anders is dan traditionele omgevingen, omdat je alles in je geheugen hebt. Dus ze hebben het over het doen van zowel transactionele als analytische op dezelfde gegevens in het geheugen, in tegenstelling tot de traditionele manier, die het eruit haalt, het in een kubus plaatst, bijvoorbeeld, het daar analyseert, versus transactie, die gebeurt op een heel andere manier.
Dit is een interessante ruimte en we gaan erachter komen van een andere verkoper, IDERA, een beetje over hoe al dat spul gaat werken, en waar de oprit over gaat, eerlijk gezegd. Dus we horen het van Dr. Robin Bloor, onze eigen hoofdanalist hier bij The Bloor Group; Dez Blanchfield, onze datawetenschapper en vervolgens goede vriend Bill Ellis van IDERA. Dus daarmee ga ik de sleutels overhandigen aan Dr. Robin Bloor, die hem wegneemt.
Dr. Robin Bloor: Ja, zoals Eric zei, de tijd dat we voor het eerst op de hoogte werden gebracht door SAP HANA was al vele jaren geleden terug. Maar het was erg interessant, die specifieke tijd was erg interessant. We zouden een of twee bedrijven tegenkomen die op de een of andere manier in-memory-technologie aanboden. Het was vrij duidelijk dat in-memory zou komen. En het was pas toen SAP opstond en plotseling HANA lanceerde. Ik bedoel, het was een schok toen ik SAP dat zag doen. Het was een schok, omdat ik verwachtte dat het ergens anders vandaan zou komen. Ik verwachtte dat het, weet je, Microsoft of Oracle of IBM of zo iemand zou zijn. Het idee dat SAP het deed was echt heel verrassend voor mij. Ik veronderstel dat het niet had moeten zijn omdat SAP een van de strategische leveranciers is en vrijwel alles wat er in de industrie gebeurt, komt daaruit.
Hoe dan ook, het hele punt over in-memory, ik bedoel, we realiseerden ons, we praatten er altijd over, dat zodra je daadwerkelijk in-memory gaat - dit niet gaat over het opslaan van gegevens, dit gaat over idee dat de geheugenlaag het systeemrecord is - zodra u het systeemrecord naar het geheugen migreert, wordt de schijf een handoff-medium van de ene soort en wordt het iets anders. En ik vond dat heel opwindend toen dat begon te gebeuren. Dus echt, het is voorbij voor de draaiende schijf. Spinning disk zal binnenkort alleen in musea bestaan. Ik weet niet zeker hoe snel dat snel is, maar in feite bevindt solid-state schijf zich nu in de wetcurve van Moore, het is al tien keer sneller dan spinnen van roest, zoals ze het nu noemen, en vrij snel zal het nog sneller zijn en dan betekent dat dat use cases voor schijf steeds minder worden.
En het merkwaardige feit, traditionele DBMS, dat in feite veel traditionele software werd gebouwd voor het draaien van de schijf, veronderstelde dat het draait. Het had allerlei mogelijkheden op fysiek niveau die nauwgezet waren geprogrammeerd om de draaiende schijf te benutten en het ophalen van gegevens zo snel mogelijk te maken. En dat alles wordt weggewassen. Gewoon verdwijnen, weet je? En toen was er duidelijk een zeer - ik weet het niet, lucratief, ik veronderstel dat het uiteindelijk zal zijn - opening voor een in-memory database die probeerde de positie in te nemen die de grote databases, Oracle en Microsoft, SQL Server en IBM's DB2, het bezet in de geheugenruimte en het was zeer interessant om te zien hoe die vooruit marcheren en dat doen.
Laten we het hebben over de geheugencascade; het is gewoon het vermelden waard. Het is ook, de reden om dit te noemen, de reden dat ik dit er echt in gooide, was gewoon om iedereen te laten weten dat, als ik het hier over geheugen heb, al deze lagen waar ik het over heb in feite geheugen zijn. Maar je realiseert je plotseling dat dit een hiërarchische winkel is, het is niet alleen een herinnering. En daarom is vrijwel alles wat we lang, heel lang geleden over hiërarchische winkel hebben geleerd, ook van toepassing. En het betekent ook dat elke in-memory database hier doorheen moet navigeren, sommige lopen er gewoon doorheen op RAM zelf, weet je. En het is alleen maar groter en groter en groter geworden en het wordt nu gemeten in megabytes. Maar je hebt L1-cache die honderd keer sneller is dan geheugen, L2-cache 30 keer sneller dan geheugen en L3-cache ongeveer 10 keer sneller dan geheugen. Dus, weet je, er is veel technologie - nou ja, een behoorlijke hoeveelheid technologie - heeft de strategie aangenomen om die caches te gebruiken als soort opslagruimte op weg naar dingen die worden uitgevoerd, met name databasetechnologie. Dus, weet je, dat is één invloed.
Dan hebben we de opkomst van 3D XPoint en IBM's PCM. En het is bijna RAM-snelheden, is eigenlijk wat beide leveranciers opscheppen. De use cases zijn waarschijnlijk anders. De vroege experimenten hiermee moeten nog worden afgerond. We weten niet hoe het het gebruik van RAM en de technologie van een in-memory database zal beïnvloeden. Je hebt dan RAM versus SSD. Momenteel is RAM ongeveer 300 keer sneller, maar dat aantal neemt natuurlijk af. En SSD versus schijf die ongeveer 10 keer sneller is, als ik het begrijp. Dus dat is het soort situatie dat je hebt. Het is een hiërarchische winkel. Op een andere manier kijken, in het geheugen, is natuurlijk compleet anders. Het bovenste diagram toont dus twee toepassingen, beide misschien toegang tot een database, maar zeker toegang tot gegevens over spinning roest. En de manier waarop u dingen door het netwerk laat stromen, afhankelijk van wat afhankelijkheden zijn, is dat u ETL hebt. Dit betekent dus dat er gegevens naar spinroest gaan en vervolgens van roest afkomen om overal naartoe te gaan en om ergens te komen, gaat het terug naar spinroest, wat drie bewegingen is. En houd er rekening mee dat het geheugen honderdduizend keer sneller kan zijn dan de draaiende schijf, en u beseft zeker dat het nemen van gegevens en het in het geheugen op te nemen dat hele ding echt heel anders maakt.
Dus je hebt misschien gedacht dat wat er zou gebeuren zou zijn op wat hier op het scherm staat, je zou kunnen hebben gedacht dat de ETL op de een of andere manier in feite gewoon van gegevens naar gegevens in het geheugen zou gaan. Maar in feite doet het dat misschien niet; in feite zou je hier de situatie aan de rechterkant kunnen hebben waarin twee applicaties hetzelfde geheugen kunnen activeren. Zeker, een in-memory database zou je die mogelijkheid kunnen geven, zolang je de vergrendeling hebt en al het andere eromheen. Dit verandert dus niet alleen de snelheid van de dingen, dit verandert ook hoe u applicaties en volledige gegevensstromen configureert.
Het is dus een enorm soort impact. Dus het geheugen is storend, toch? En dat moeten we halen uit wat ik zei. In-memory-verwerking is momenteel een versneller, maar het wordt de norm. Het zal worden gebruikt, wordt toegepast volgens de toepassingswaarde, en dat is daarom heel, heel interessant, dat SAP daadwerkelijk een versie van hun ERP-software uitbrengt die in het geheugen is. En latentieverbeteringen tot drie orden van grootte volledig mogelijk, en eigenlijk zelfs meer dan dat mogelijk is, afhankelijk van hoe u het doet. Dus je krijgt enorme verbeteringen in snelheid door in het geheugen te gaan. En het resultaat, SAP HANA's S / 4 - die ze hebben uitgebracht, denk ik, nou, mensen zeggen dat het nog steeds wordt vrijgegeven, maar het werd zeker vorig jaar vrijgegeven - het is een game-wisselaar gezien het SAP-klantenbestand. Ik bedoel, er zijn 10.000 bedrijven die SAP ERP gebruiken en het zijn vrijwel allemaal grote bedrijven, weet je. Dus het idee dat ze allemaal een stimulans hebben om in het geheugen te gaan en hun fundamentele te gebruiken, omdat ERP bijna altijd fundamentele applicaties zijn die door de bedrijven worden uitgevoerd, het is gewoon een enorme spelwisselaar en het zal erg interessant zijn. Maar dat klinkt natuurlijk allemaal heel goed, maar het moet intelligent worden geconfigureerd en goed worden gemonitord. Het is niet zo eenvoudig als het klinkt.
Dat gezegd hebbende, denk ik dat ik de bal zal doorgeven aan wie deze vent is? Oh, Australiër, Dez Blanchfield.
Dez Blanchfield: Erg grappig. Altijd een moeilijke daad om te volgen, Dr. Robin Bloor. Bedankt dat je me vandaag hebt. Dus, groot onderwerp, maar opwindend. Dus heb ik een afbeelding gekozen die ik vaak in gedachten heb als ik denk aan het moderne datameer en enterprise data warehouses, en mijn kleine juweeltjes aan data. Dus hier heb ik dit prachtige meer omringd door bergen en golven die uitkomen, en de golven beuken over deze rotsen. Dit is een soort van hoe ik mentaal visualiseer hoe het er tegenwoordig uitziet in een groot datameer. De golven zijn batchopdrachten en realtime analyse wordt naar gegevens gegooid, zijnde de rotsen. En als ik het als een fysiek meer beschouw, brengt het me een soort wake-up call met zich mee dat, weet je, de schaal van de datawarehouses die we nu bouwen, de reden dat we met deze munten kwamen en de looptijd van een gegevensmeer is dat ze erg groot zijn en erg diep, en soms kun je er stormen in hebben. En als we dat doen, moet je altijd oplossen wat de storm veroorzaakt.
Dus in het thema van dit ding lijkt het mij dat deze sirene-oproep van in-memory computing inderdaad zeer sterk is en om een goede reden. Het levert zoveel belangrijke commerciële en technische voordelen op. Dat is een discussie voor een paar uur op een andere dag. Maar de algemene verschuiving naar in-memory computing, ten eerste wil ik alleen maar vertellen hoe we hier zijn gekomen en wat dit mogelijk maakt, omdat het een soort van basis legt waar sommige van de uitdagingen het eerst kunnen liggen en wat we nodig hebben om te weten van en denken aan, in onze wereld van afstappen van traditionele oude draaiende schijf die gegevens vasthoudt en wordt gewisseld op en van schijf en naar geheugen en uit geheugen en naar CPU's, tot nu toe verwijderen we bijna een van die hele lagen, zijnde de draaiende schijf. Want onthoud, in de allereerste dagen van de architectuur hebben we ons architectonisch lang niet verplaatst van de mainframe of de midrange-wereld van wat we oorspronkelijk als kerngeheugen en drumopslag beschouwden, weet je.
Zoals Dr. Robin Bloor zei, de benadering die we hebben gevolgd om gegevens over computerarchitectuur te verplaatsen, is gedurende een aantal decennia zelfs niet echt dramatisch veranderd. Als je denkt aan het feit dat, weet je, modern computergebruik technisch gezien al bestaat, als je de woordspeling al 60 jaar of langer gratie geeft, weet je, zes decennia en meer, en het is in de zin dat je koop als het ware een doos uit de kast. De verschuiving naar nieuwe architectuur kwam echt in mijn gedachten tot stand toen we verschoven van het denken rond mainframes en midrange, en kerngeheugen- en drumopslagarchitecturen, naar de dapperen of de supercomputing, in het bijzonder de wil van Seymour Cray, waar dingen zoals dwarsbalk backplanes werd een ding. In plaats van slechts één route om gegevens over het backplane of het moederbord te verplaatsen, zoals het tegenwoordig wordt genoemd. En inline-geheugen, weet je, tegenwoordig denken mensen niet echt na over wat het eigenlijk betekent als ze DIMM en SIMM zeggen. Maar SIMM is enkel inline-geheugen en DIMM is dubbel inline-geheugen en sindsdien zijn we complexer en sindsdien zijn er tientallen verschillende geheugentypes voor verschillende dingen: sommige voor video, sommige voor algemene toepassingen, sommige ingebouwd in CPU's.
Er was dus een grote verschuiving naar een nieuwe manier waarop gegevens werden opgeslagen en geopend. We staan op het punt om dezelfde verschuiving door te maken in een andere hele generatie, maar niet zozeer in de hardware zelf, maar in de acceptatie van de hardware in de bedrijfslogica en in de datalogica-laag, en het is een andere grote paradigmaverschuiving in mijn gedachten .
Maar kort over hoe we hier zijn gekomen. Ik bedoel, de hardwaretechnologie is verbeterd en aanzienlijk verbeterd. We gingen van het hebben van CPU's en het idee van een kern was een redelijk modern concept. We gaan er nu vanuit dat onze telefoons twee of vier cores hebben en onze computers twee of vier of zelfs acht cores op het bureaublad en acht en 12 en meer op de 16 en 32, zelfs op het serverplatform . Maar het is eigenlijk een vrij modern ding dat cores een mogelijkheid binnen CPU's werden en dat we van 32-bit naar 64-bit gingen. Er zijn daar een paar grote dingen gebeurd: we hebben hogere kloksnelheden op meerdere cores, zodat we dingen parallel konden doen en elk van die cores meerdere threads kon draaien. Opeens konden we veel dingen tegelijkertijd op dezelfde gegevens uitvoeren. Vierenzestig-bit adresafstand gaf ons tot twee terabytes RAM, wat een fenomenaal concept is, maar het is nu een ding. Deze multipath-backplane-architecturen, weet je, moederborden, je kon ooit dingen slechts in één richting doen: achteruit en vooruit. En zoals met de dagen met de Cray computing en enkele van de supercomputerontwerpen van die tijd, en nu in desktopcomputers en gangbare off-the-shelf, soort desktop-pc's voor desktopmontage, omdat het merendeel van de moderne Pc's hebben nu dit tijdperk van mainframe, midrange, micro-desktops doorgemaakt en we hebben er weer servers van gemaakt.
En veel van die supercomputermogelijkheden, dat ontwerp van supercomputerkwaliteit, werden in gemeenschappelijke kant-en-klare componenten geduwd. Tegenwoordig, het idee om zeer goedkope rack-mount pc's te nemen en ze in honderden, zo niet duizenden in racks te plaatsen en open-source software zoals Linux te gebruiken en daarop SAP HANA te implementeren, jij weet, we nemen dat vaak als vanzelfsprekend aan. Maar dat is een heel nieuw opwindend iets en het komt met zijn complexiteit.
Software werd ook beter, met name geheugenbeheer en gegevenspartitie. Ik zal daar niet veel in detail op ingaan, maar als je kijkt naar de grote verschuiving in de afgelopen 15 jaar of minder, hoe geheugen wordt beheerd, met name gegevens in RAM en hoe gegevens worden gepartitioneerd in RAM, zodat, zoals Dr. Robin Bloor eerder aangaf of erop wees, weet je, dingen tegelijkertijd kunnen lezen en schrijven zonder elkaar te beïnvloeden, in plaats van wachttijden te hebben. Veel zeer krachtige functies zoals compressie en codering op de chip. Versleuteling wordt steeds belangrijker en dat hoeven we niet noodzakelijkerwijs te doen in software, in RAM, in CPU-ruimte, nu gebeurt dat eigenlijk op de chip. Dat versnelt de dingen dramatisch. En gedistribueerde gegevensopslag en -verwerking, opnieuw, dingen waarvan we ooit dachten dat ze het waren van supercomputers en parallelle verwerking, we nemen dat nu als vanzelfsprekend aan in de ruimte van SAP HANA en Hadoop en Spark, enzovoort.
Dus het hele punt hiervan is deze high-performance computing, HPC-mogelijkheden kwamen naar de onderneming en nu geniet de onderneming van de voordelen die dat met zich meebrengt in prestatiewinst en technologieruimte en technische voordelen en commerciële voordelen, omdat, weet u, de kortere tijd tot waarde is dramatisch gedaald.
Maar ik gebruik dit beeld van een verhaal dat ik enige tijd geleden las over een heer die een pc-behuizing uit Lego bouwde, omdat het altijd in me opkomt als ik aan sommige van deze dingen denk. En dat is dat, het lijkt een geweldig idee op het moment dat je begint met het bouwen, en dan kom je er halverwege en besef je dat het eigenlijk heel lastig is om alle Lego-bits in elkaar te zetten en een solide ding te maken, solide genoeg om een moederbord enzovoort in te voeren, dat een zaak voor een pc bouwt. En uiteindelijk realiseer je je dat alle kleine stukjes niet goed aan elkaar plakken en dat je een beetje voorzichtig moet zijn met welke kleine stukjes je aan elkaar plakt om het stevig te maken. En het is een heel schattig idee, maar het is een wake-up call als je halverwege bent en je je realiseert: "Hmm, misschien had ik gewoon een PC-hoes van $ 300 moeten kopen, maar ik zal het nu afmaken en er iets van leren."
Voor mij is dat een goede analogie voor hoe het is om deze zeer complexe platforms te bouwen, omdat het allemaal goed en goed is om het te bouwen en te eindigen met een omgeving waar je routers en switches en servers en racks hebt. En u hebt CPU's en RAM en besturingssysteem geclusterd. En u zet er zoiets als HANA bovenop voor de gedistribueerde verwerking in het geheugen en gegevensopslag en gegevensbeheer. Je bouwt daar bovenop de SAP-stack, je krijgt de databasemogelijkheden en vervolgens laad je je gegevens en je bedrijfslogica in en begin je wat reads en writees en queries toe te passen, enzovoort. Je moet I / O op de hoogte houden en dingen plannen en workloads en multitenancy beheren, enzovoort. Deze stapel wordt zeer complex, zeer snel. Dat is op zichzelf een complexe stapel als het maar op één machine is. Vermenigvuldig dat met 16 of 32 machines, het wordt heel, heel niet-triviaal. Wanneer je honderden en uiteindelijk duizenden machines vermenigvuldigt, om van 100 terabytes naar petabyteschaal te gaan, is dit een beangstigend concept, en dit zijn de realiteiten waar we nu mee te maken hebben.
Dus je eindigt met een aantal dingen die ook hebben geholpen deze wereld te veranderen, en dat is dat schijfruimte belachelijk goedkoop werd. Weet je, ooit gaf je 380 tot 400 duizend dollar uit aan een gigabyte harde schijf, terwijl het een enorme trommel was ter grootte van een - iets dat een vorkheftruck nodig had om het op te pakken. Tegenwoordig is het een soort van één of twee cent per gigabyte commodity-schijfruimte. En RAM deed hetzelfde. Deze twee J-curven in beide grafieken zijn trouwens elk tien jaar, dus met andere woorden, we kijken naar twee blokken van 10 jaar, 20 jaar prijsverlaging. Maar ik brak ze in twee J-bochten omdat uiteindelijk de rechter een stippellijn werd en je het detail ervan niet kon zien, dus heb ik het opnieuw geschaald. Een gigabyte RAM 20 jaar geleden was iets in de orde van zes en een half miljoen dollar. Tegenwoordig wordt je bestolen als je meer dan drie of vier dollar betaalt voor een gigabyte RAM-geheugen voor standaardhardware.
Deze aanzienlijke daling van de prijzen in de afgelopen twee decennia heeft ertoe geleid dat we nu verder kunnen gaan dan schijfruimte en direct in RAM, niet alleen op het niveau van de megabyte, maar nu op het niveau van de terabyte en RAM kunnen behandelen als zijn schijf. De uitdaging daarbij was echter dat RAM van nature kortstondig was - dat betekent iets dat een korte periode aanhoudt - dus moesten we manieren bedenken om veerkracht in die ruimte te bieden.
En dus is mijn punt hier dat in-memory computing niet voor angsthazen is. Jongleren met deze zeer grootschalige gegevens in het geheugen en de verwerking eromheen is een interessante uitdaging; zoals ik eerder aangaf, het is niet voor angsthazen. Dus, een ding dat we hebben geleerd van deze ervaring met grootschalige en high-density in-memory computing is dat de complexiteit die we bouwen risico's op een aantal gebieden met zich meebrengt.
Maar laten we het gewoon bekijken vanuit een oogpunt van monitoring en respons. Wanneer we aan de gegevens denken, begint het in schijfruimte, het zit in databases op schijven, we pushen het in het geheugen. Als het eenmaal in het geheugen is opgeslagen en is gedistribueerd en er kopieën van zijn, kunnen we er veel kopieën van gebruiken, en als er wijzigingen worden aangebracht, kan het op geheugenniveau worden weerspiegeld in plaats van dat het aan en uit en over de backplane moet gaan twee verschillende niveaus, het gaat in en uit geheugen. We zijn terechtgekomen op dit hyperscale hardwareplatform waarmee we dit nu kunnen doen. Als we het hebben over hyperscaling, is het moeilijker op belachelijk dichte niveaus, en geheugen met zeer hoge dichtheid, zeer hoge dichtheid tellingen van CPU's en cores en threads. We hebben nu zeer complexe netwerkpathologieën om dit te ondersteunen, omdat de gegevens op een bepaald moment over het netwerk moeten bewegen als het tussen knooppunten en de clusters gaat.
Dus uiteindelijk worden apparaatfoutredundantie een probleem en moeten we apparaten en onderdelen ervan controleren. We moeten veerkrachtige datafoutredundantie in dat platform hebben ingebouwd en deze bewaken. We moeten de gedistribueerde database-veerkracht hebben ingebouwd, dus we moeten het databaseplatform bewaken en daarin stapelen. We moeten de distributieplanning in de gaten houden, wat er gebeurt in sommige processen tot en met polling en query en het pad dat de query aflegt en de manier waarop de query wordt gestructureerd en uitgevoerd. Hoe ziet het eruit, heeft iemand een SELECT * op "blah" gedaan of hebben ze eigenlijk een zeer slimme en goed gestructureerde query gedaan die hen de nominale, minimale hoeveelheid gegevens oplevert die over de architectuur in de backplane komt? We hebben multitenancy-workloads, meerdere gebruikers en meerdere groepen met dezelfde of meerdere workloads en batchtaken en realtime planning. En we hebben deze combinatie van batchverwerking en realtime verwerking. Sommige dingen worden gewoon regelmatig uitgevoerd - elk uur, dagelijks, wekelijks of maandelijks - andere dingen zijn op aanvraag. Misschien zit daar iemand met een tablet die een realtime rapport wil maken.
En nogmaals, we komen op dat hele punt, dat de complexiteit die hier ontstaat niet alleen een uitdaging is, het is ook heel beangstigend. En we laten deze realiteit controleren dat een enkel prestatieprobleem, op zichzelf al een prestatieprobleem, het hele ecosysteem kan beïnvloeden. En dus eindigen we met deze zeer leuke uitdaging om erachter te komen, nou, waar zijn de gevolgen? En we hebben de uitdaging, zijn we reactief of proactief? Bekijken we het ding in realtime en zien we dat iets "knalt" en erop reageren? Of hebben we een vorm van trend gezien en ons gerealiseerd dat we hier proactief aan mee moeten doen? Omdat de sleutel is dat iedereen iets snel, goedkoop en gemakkelijk wil. Maar we eindigen met deze scenario's, waar ik graag naar verwijs en mijn favoriete lijn van het Donald Rumsfeld-raadsel - dat naar mijn mening van toepassing is in al deze scenario's van hoge complexiteit - en dat is dat, we hebben bekende gegevens gekend, want dat is iets we hebben het ontworpen en gebouwd en het loopt zoals gepland. We hebben onbekende onbekenden in die zin dat we niet weten wie wat, waar en wanneer runt, als het op aanvraag is. En we hebben onbekende onbekenden en dat zijn de dingen die we moeten controleren en controleren. Omdat de realiteit is, we weten allemaal, kun je niet iets beheren dat je niet kunt meten.
Dus, om de juiste tools en de juiste mogelijkheid te hebben om onze CPU-planning te monitoren, zoek wachttijden en ontdek waarom dingen moeten wachten in planningswachtrijen in pijplijnen. Wat gebeurt er in het geheugen, wat voor gebruik wordt er uitgevoerd, wat voor soort prestaties halen we uit het geheugen? Worden spullen correct gepartitioneerd, worden ze gedistribueerd, hebben we genoeg knooppunten met kopieën ervan om het hoofd te bieden aan de werklasten die er naartoe worden gegooid? Wat gebeurt er met procesuitvoering buiten de processen van het besturingssysteem? De banen zelf die worden uitgevoerd, de afzonderlijke apps en de daemons die hen ondersteunen? Wat gebeurt er in die processen, met name de structurering van query's en hoe worden die query's uitgevoerd en gecompileerd? En de gezondheid van die processen helemaal in stapel? Weet je, nogmaals, terug naar wachttijden, is het correct plannen, moet het wachten, waar wacht het, wacht het op geheugenlezingen, I / O's, de CPU, I / O over het netwerk naar de eindgebruiker ?
En dan terug naar dat punt dat ik net snel heb genoemd voordat ik afrond en dat is dat, hoe benaderen we probleemoplossing en responstijden daarop? Kijken we in realtime en reageren we op dingen, wat het minst ideale scenario is, maar zelfs dan is het beter dat we dat doen dan niet weten en de helpdesk bellen en zeggen dat er iets mis is gegaan en we moeten het opsporen ? Of doen we het proactief en kijken we naar wat er straks komt? Met andere woorden, zien we dat we onvoldoende geheugen hebben en meer knooppunten moeten toevoegen? Doen we trendanalyses, doen we capaciteitsplanning? En in dat alles, monitoren we historische uitvoeringstijden en denken we na over capaciteitsplanning of bekijken we het in real time en proactief herschikken en load balancing? En zijn we ons bewust van de workloads die in de eerste plaats worden uitgevoerd? Weten we wie wat doet in ons cluster en waarom?
In-memory-berekeningen zijn erg krachtig, maar met die kracht is het bijna een van die dingen, zoals een geladen geweer en je speelt met live munitie. Je kunt jezelf uiteindelijk in de voet schieten als je niet voorzichtig bent. Die kracht van in-memory computing betekent dus gewoon dat we veel meer en snel kunnen draaien over zeer gedistribueerde en discrete datasets. Maar dan is er dan een hogere vraag die wordt aangedreven door eindgebruikers. Ze wennen aan die kracht en ze willen het. Ze verwachten niet langer dat het weken kan duren voordat taken worden uitgevoerd en rapporten in gewoon oud papier verschijnen. En dan, onder dat alles, hebben we het dagelijkse onderhoud rondom patching, updates en upgrades. En als u denkt aan 24/7 verwerking met in-memory computing, die gegevens beheren, de workloads overal beheren, het zit allemaal in het geheugen, technisch gezien in een kortstondig platform, als we patches en updates en upgrades gaan toepassen in daar gaat dat ook gepaard met een hele reeks andere beheer- en monitoringuitdagingen. We moeten weten wat we offline kunnen nemen, wanneer we het kunnen upgraden en wanneer we het weer online brengen. En dat brengt me bij mijn laatste punt en dat is dat als we steeds complexer worden in deze systemen, het niet iets is dat een mens kan doen door alleen maar aan zijn duim te zuigen en aan zijn oor te trekken. Er zijn geen, soort van, buikgevoel benaderingen meer. We hebben echt de juiste tools nodig om dit hoge prestatieniveau in computer- en gegevensbeheer te beheren en te leveren.
En met dat in gedachten ga ik het overhandigen aan onze vriend van IDERA en horen hoe zij deze uitdaging hebben aangepakt.
Bill Ellis: Heel erg bedankt. Ik deel mijn scherm en hier zijn we. Dus het is echt nederig om alleen al de technologie en alle mensen die voor ons kwamen te overwegen om dit spul dat beschikbaar is in 2017, beschikbaar te maken. We gaan het hebben over werklastanalyse voor SAP HANA - in feite een oplossing voor databasebewaking: uitgebreid, agentloos, biedt realtime en bouwt een geschiedenis op, zodat u kunt zien wat er in het verleden is gebeurd. SAP S / 4 HANA biedt het potentieel van beter, sneller en goedkoper. Ik zeg niet dat het goedkoop is, ik zeg alleen dat het goedkoper is. Traditioneel was wat er gebeurde dat je een hoofdproductie-exemplaar zou hebben - waarschijnlijk op Oracle in een grotere winkel, mogelijk SQL Server - en dan zou je dat ETL-proces gebruiken en zou je meerdere, soort versies van de waarheid hebben . En dit is erg duur omdat u voor hardware, besturingssysteem en Oracle-licentie voor elk van deze individuele omgevingen betaalde. En bovendien zou je mensen nodig hebben om de ene versie van de waarheid te verzoenen met de volgende versie van de waarheid. En dus was deze ETL-verwerking met meerdere versies gewoon traag en heel, heel omslachtig.
En dus kan HANA, eigenlijk één HANA-instantie, mogelijk al die andere instanties vervangen. Het is dus goedkoper omdat het één hardwareplatform is, één besturingssysteem, in plaats van veelvouden. En dus verandert de S / 4 HANA echt alles en kijk je eigenlijk naar de evolutie van SAP van R / 2 naar R / 3, de verschillende uitbreidingspakketten. Nu is het oude systeem beschikbaar tot 2025, dus je hebt acht jaar tot je echt gedwongen bent om te migreren. Hoewel we mensen zien, weet je, hun tenen erin dabbelen omdat ze weten dat het eraan komt en uiteindelijk, weet je, ECC draait op HANA en dus moet je daar echt op voorbereid zijn en de technologie begrijpen.
Dus één database, geen ETL-processen, geen kopieën die moeten worden afgestemd. Dus nogmaals, sneller, beter en goedkoper. HANA is in geheugen. SAP levert de software, u levert de hardware. Er zijn geen verzameltabellen. Een van de dingen die ze eigenlijk suggereren als je hier aan denkt, is dat je hier niet op in wilt gaan, we gaan gewoon de grootste server kopen die beschikbaar is. Ze suggereren dat u uw SAP-landschap op voorhand de juiste grootte heeft en ze zeggen eigenlijk dat u niet voor 20 jaar aan gegevens migreert. Ik denk dat archiveren iets is dat te weinig wordt gebruikt in IT, niet alleen in SAP-winkels. Het volgende is dat SAP veel tijd heeft besteed aan het herschrijven van hun eigen code om SELECT * niet te gebruiken. SELECT * retourneert alle kolommen uit de tabel en het is bijzonder duur in een zuilvormige database. En dus is het geen goed idee voor SAP HANA. Dus voor winkels die veel maatwerk hebben, veel rapporten, dit is iets waar je naar wilt zoeken en je wilt kolomnamen specificeren naarmate je verdergaat met het migreren van alles naar HANA.
We zeggen graag dat HANA geen wondermiddel is. Zoals alle databases, alle technologieën, moet het worden bewaakt, en zoals eerder vermeld, hebt u cijfers nodig om overtollige metingen te beheren, meting per meting. En een van de dingen waar ik het over heb in het IDERA-gebied is dat elke zakelijke transactie een interactie aangaat met het geregistreerde systeem, en in dit geval wordt het HANA. En zo wordt HANA de basis voor de uitvoering van uw SAP-transacties, de eindgebruikerservaring. En dus is het van vitaal belang dat het op topsnelheid blijft werken. Het wordt een enkel punt van mislukking, en in gesprek met mensen, dit is iets dat kan opduiken waar je een eindgebruiker hebt en misschien die real-time gegevens gebruikt en ze hebben een ad-hocquery die mogelijk niet helemaal Rechtsaf. Misschien doen ze niet mee aan tafels en hebben ze een uiterlijke join gemaakt, een partijproduct, en verbruiken ze in feite veel bronnen. Nu zal HANA dat uiteindelijk herkennen en die sessie doden. En dus is er het cruciale deel van onze architectuur waarmee je dat in de geschiedenis kunt vastleggen, zodat je kunt zien wat er in het verleden is gebeurd en die situaties kunt herkennen.
Laten we dus eens kijken naar de werklastanalyse voor SAP HANA. Dit is versie 1, dus we nodigen u van harte uit om met ons mee te gaan op reis, en dit is een product van IDERA. Het is uitgebreid, maar toch eenvoudig. Realtime met trending. Gastheer gezondheid, bijvoorbeeld gezondheid. We volgen de wachttoestanden, de SQL-vragen, geheugenconsumenten en services. Dus dit is hoe de GUI eruit ziet en je kunt meteen zien dat het web-enabled is. Ik heb deze oplossing live op mijn systeem geopend. Er zijn een aantal cruciale dingen die je wilt bekijken. We zijn min of meer onderverdeeld in verschillende werkruimten. Het meest cruciale is wat er op hostniveau gebeurt vanuit een CPU- en geheugengebruik. Je wilt absoluut niet in een swapping of thrashing standpunt komen. En dan werk je in feite naar beneden wat er gebeurt in de trend, van responstijd, gebruikers, SQL-instructies, dat wil zeggen wat de activiteit op het systeem drijft.
Een van de dingen met IDERA is dat, weet je, er niets gebeurt in een database totdat er activiteit is. En die activiteit zijn SQL-instructies die uit de toepassing komen. Het meten van de SQL-instructies is dus absoluut noodzakelijk om de hoofdoorzaak te kunnen detecteren. Dus laten we verder gaan. We kunnen dus op hostniveau echt naar geheugen kijken, de tijd bijhouden en het CPU-gebruik van de host. Doe een stapje terug, u kunt de COBSQL-instructies bekijken. Nu, een van de dingen die je in onze architectuur zult zien, is dat deze informatie buiten HANA wordt opgeslagen, dus als er iets met HANA zou gebeuren, leggen we in feite informatie vast tot, God verhoede, een onbeschikbaarheidssituatie . We kunnen ook alles vastleggen wat er op het systeem gebeurt, zodat u duidelijk zicht hebt. En een van de dingen die we gaan doen, is dat we de SQL-instructies in gewogen volgorde presenteren. Dus dat zal rekening houden met het aantal uitvoeringen, en dus is dit het geaggregeerde bronverbruik.
En dus kunt u hier individuele statistieken gebruiken - wanneer is die SQL-instructie uitgevoerd? En dan wordt het verbruik van hulpbronnen grotendeels bepaald door het uitvoeringsplan, en dus kunnen we dat continu vastleggen. HANA is in geheugen. Het is zeer parallel. Het heeft wel primaire indexen op elke tafel, die sommige winkels kiezen om een secundaire index te bouwen om bepaalde prestatieproblemen aan te pakken. En dus, soort van weten wat er is gebeurd met het uitvoeringsplan voor bepaalde SQL-instructies kan zeer waardevol zijn. We zullen ook kijken naar de services, geheugengebruik nogmaals, in kaart gebracht in de tijd. De architectuur: dus dit is een zelfstandige oplossing die u kunt downloaden van onze website en de architectuur is dat deze web-enabled is.
U kunt meerdere gebruikers verbinding laten maken met een bepaald exemplaar. U kunt lokale exemplaren van SAP HANA volgen. En we houden een doorlopende geschiedenis van vier weken bij in onze repository en die wordt zelf beheerd. Om dit te implementeren, is het vrij eenvoudig. U hebt een Windows Server nodig. Je moet het downloaden. De meeste Windows-servers hebben een ingebouwd .NET-framework en worden geleverd met een licentie. En dus zou je naar de installatiewizard gaan die wordt aangestuurd door Setup.exe en het zou eigenlijk een scherm, licentieovereenkomst openen, en je zou gewoon dit overzicht opmaken door op "Volgende" te klikken. En dus, waar zou je HANA willen hebben? geïnstalleerd zijn? Het volgende is database-eigenschappen, en dit wordt uw verbinding met de SAP HANA, dus dit is agentless monitoring van de HANA-instantie. En dan geven we in principe een voorbeeld, dit is de poort waarop we standaard communiceren. Klik op "Installeren" en het start in feite HANA op en je begint met het opbouwen van de geschiedenis. Dus slechts een klein beetje informatie over de maattabel. We kunnen maximaal 45 HANA-exemplaren bewaken en je wilt dit soort op een glijdende schaal gebruiken om het aantal cores, geheugen en schijfruimte te bepalen dat je nodig hebt. En dit veronderstelt dat er een complete geschiedenis van vier weken aan de gang is.
Dus, als een korte samenvatting, kijken we naar serverstatus, bijvoorbeeld status, CPU / geheugengebruik. Wat zijn de geheugenconsumenten, wat zijn de stuurprogramma's voor activiteiten, wat zijn de services? SQL-instructies zijn van vitaal belang - wat zijn de uitvoeringsstatussen? Laat me de uitvoeringsplannen zien, wanneer hebben dingen uitgevoerd, trending geboden? Dit geeft je realtime en een geschiedenis van wat er was gebeurd. En zoals ik al zei, omdat onze geschiedenis gescheiden is van HANA, gaan we dingen vastleggen die een time-out hebben gehad en zijn weggespoeld uit de geschiedenis van HANA. Zodat u het ware bronverbruik op uw systeem kunt zien vanwege de afzonderlijke geschiedenis.
Dus, zoals ik al zei, de website van IDERA, onder Producten, kun je dit gemakkelijk vinden. Als je dit wilt proberen, ben je hier zeker van harte welkom. Kijk hoe het informatie voor u biedt en er is aanvullende informatie op die website. Dus alle geïnteresseerde partijen zijn daar graag op ingegaan. Nu, in de portfolio-producten die IDERA aanbiedt, is er ook een SAP ECC-transactiemonitor, en deze wordt Precise for SAP genoemd. En wat het doet is - of u nu portal gebruikt of alleen maar ECC - het zal de eindgebruikerstransactie van klik tot schijf, tot aan de SQL-instructie, vastleggen en u laten zien wat er gebeurt.
Nu laat ik u slechts één overzichtsscherm zien. Ik wil dat je een paar afhaalmaaltijden hebt in dit overzichtsscherm. Het is de responstijd van de Y-as, de tijd van de X-as plus de dag, en in deze transactieweergave tonen we u klanttijd, wachtrijtijd, ABAP-codetijd, databasetijd. We kunnen eindgebruikers-ID's en T-codes vastleggen en u kunt daadwerkelijk servers filteren en weergeven via een bepaalde transactie. En dus hebben veel winkels de voorkant van het landschap onder VMware, zodat u daadwerkelijk kunt meten wat er op elk van de servers gebeurt en u een zeer gedetailleerde analyse kunt maken. Deze transactieweergave is dus bedoeld voor de eindgebruikerstransactie door het hele SAP-landschap. En dat kunt u op onze website vinden onder Producten APM Tools en dit zou de SAP-oplossing zijn die we hebben. De installatie hiervoor is een beetje ingewikkelder, dus het is niet alleen downloaden en proberen, zoals we hebben voor HANA. Dit is iets waar we samen aan werken om de algehele transactie voor u te doen, ontwerpen en implementeren.
Dus, slechts een derde snelle samenvatting, werklastanalyse voor SAP HANA, het is uitgebreid, agentloos, realtime, biedt een geschiedenis. Wij bieden de mogelijkheid om het te downloaden en te proberen voor uw site.
Dus daarmee ga ik de tijd teruggeven aan Eric, Dez en Dr. Bloor.
Eric Kavanagh: Ja, misschien Robin, vragen van jou, en dan Dez na Robin?
Dr. Robin Bloor: Oké. Ik bedoel, het eerste wat ik zou willen zeggen, is dat ik de transactieweergave erg leuk vind, omdat het precies is wat ik in die situatie zou willen. Ik heb veel werk gedaan - nou, het is nu lang geleden - bezig met het monitoren van prestaties, en dat was zo; we hadden in die tijd nog geen grafische afbeeldingen, maar dat was iets dat ik vooral wilde kunnen doen. Zodat u uzelf op de een of andere manier kunt inspuiten waar het probleem zich ook voordoet.
De eerste vraag die ik heb is, weet je, de meeste mensen implementeren S / 4 op de een of andere manier out of the box, weet je. Wanneer je betrokken raakt bij een bepaalde implementatie van S / 4, heb je ontdekt dat het goed is geïmplementeerd of kom je dingen te weten waardoor de klant misschien opnieuw wil configureren? Ik bedoel, hoe gaat dat allemaal?
Bill Ellis: Nou, elke winkel is een beetje anders. En er zijn verschillende gebruikspatronen, er zijn verschillende rapporten. Voor sites die ad-hocrapportage hebben, bedoel ik dat dit eigenlijk een soort jokerteken op het systeem is. En dus is een van de cruciale dingen om te beginnen met meten en erachter te komen wat de basislijn is, wat normaal is voor een bepaalde site, waar die specifieke site, op basis van hun gebruikspatronen, het systeem benadrukt. En pas vervolgens aanpassingen aan. Doorgaans is de monitoringoptimalisatie geen eenmalige, het is echt een doorlopende praktijk waarbij u monitort, afstemt, hoont, waardoor het systeem beter wordt voor de eindgebruikersgemeenschap om het bedrijf effectiever te kunnen bedienen.
Dr. Robin Bloor: Oké, dus als je implementeert - ik bedoel, ik weet dat dit een moeilijke vraag is om te beantwoorden omdat het zal variëren afhankelijk van de grootte van de implementatie - maar hoeveel middelen heeft de IDERA-monitoringcapaciteit, hoeveel verbruikt het? ? Maakt het iets uit of bemoeit het zich gewoon niet? Hoe werkt dat?
Bill Ellis: Ja, ik zou zeggen dat de overhead ongeveer 1-3 procent is. Veel winkels zijn bereid om dat op te offeren, omdat je dat potentieel in termen van optimalisatie terug kunt kopen. Het hangt af van gebruikspatronen. Als u een volledig landschap doet, is dit afhankelijk van de individuele technologieën die worden gemonitord. Dus, soort, kilometerstand varieert, maar zoals we het hebben gehad, is het absoluut beter om een beetje uit te geven om te weten wat er aan de hand is, dan gewoon blind te worden. In het bijzonder zou het zijn, weet je, hier zijn we in januari en begin je met het verwerken van het jaareinde en verzamel je voor 12 maanden aan gegevens. Weet u, dat is presteren, rapporten ontvangen van regelgevende organisaties, de banken en aandeelhouders, is absoluut van vitaal belang voor kritieke bedrijfsprestaties.
Dr. Robin Bloor: Juist. En even snel, vanuit uw perspectief - omdat u vermoedt dat u betrokken bent bij een hele reeks SAP-sites - hoe groot is de beweging onder de SAP-klantenbasis naar S / 4? Ik bedoel, is dat iets dat is, weet je, dat er een soort lawine van enthousiaste klanten voor gaat, of is het gewoon een gestaag straaltje? Hoe zie je dat?
Bill Ellis: Ik denk dat ik een paar jaar geleden zou zeggen dat het een teen was. Nu zou ik zeggen dat mensen een beetje tot hun knie zijn. Ik denk dat, weet je, gezien de tijdlijn dat mensen de komende jaren echt ondergedompeld zullen worden in HANA. En dus de monitoring, de transformatie, weet je, ik denk dat de meerderheid van de klanten soort van samen op de leercurve zitten. En dus denk ik dat we niet helemaal in de lawine zijn zoals je had gezegd, maar ik denk dat we op het punt staan van de grote transformatie naar HANA.
Dr. Robin Bloor: Oké, dus in termen van de sites die je hebt gezien die hiervoor zijn gegaan, passen ze HANA ook aan voor andere toepassingen of zijn ze op de een of andere manier volledig verbruikt om dit te maken dingen werken? Wat is de foto daar?
Bill Ellis: Ja, vaak zullen mensen SAP integreren met andere systemen, afhankelijk van welke modules enzovoort, dus er is een klein beetje. Ik zie mensen nog niet echt andere applicaties op HANA implementeren. Dat is zeker mogelijk om te doen. En dus gaat het meer om het landschap rondom de SAP-infrastructuur.
Dr. Robin Bloor: Ik veronderstel dat ik u beter kan doorgeven aan Dez. Ik heb je tijd verdiept. Dez?
Dez Blanchfield: Bedankt. Nee, dat is allemaal goed. Twee zeer snelle, gewoon om het thema te proberen vast te stellen. SAP HANA is nu een paar jaar uit en mensen hebben de kans gehad om het te overwegen. Als je ons een ruwe schatting zou geven van het percentage mensen dat het runt - omdat er veel mensen zijn die dit soort dingen runnen - wat denk je dat het percentage van de markt waarvan je weet dat het momenteel is verdwenen van alleen traditionele SAP-implementaties tot SAP op HANA? Kijken we naar 50/50, 30/70? Wat voor soort percentage van de markt ziet u van mensen die nu zijn overgestapt en de overstap hebben gemaakt versus mensen die gewoon terughoudend zijn en wachten op dingen om te verbeteren of te verbeteren of te veranderen of wat het geval ook is?
Bill Ellis: Ja, eigenlijk zou ik vanuit mijn perspectief het percentage rond de 20 procent hebben gesteld. SAP is meestal een traditionele onderneming. Mensen neigen zeer conservatief te zijn en dus zullen hun mensen hun voeten slepen. Ik denk dat het ook afhangt van, weet je, heb je SAP al lang, of ben je een soort MKB die misschien recenter SAP had geïmplementeerd? En dus zijn er een aantal factoren, maar over het algemeen denk ik niet dat het percentage 50/50 is. Ik zou zeggen dat 50 procent op zijn minst dabbling is en dat HANA ergens in hun datacenter draait.
Dez Blanchfield: De interessante afhaalmaaltijden die je ons eerder gaf, was dat dit in zekere zin een voldongen feit is en dat de klok fysiek en letterlijk tikt op de tijd voor overgang. Denk je dat mensen daarbij rekening hebben gehouden? Wat is het algemene besef van het begrip van het volk dat dit een overgangsverandering in platform is, het is niet alleen een optie, het wordt de standaard?
En vanuit het oogpunt van SAP ben ik er zeker van dat ze die kant op gaan, omdat er een aanzienlijk concurrentievoordeel is in de prestaties, maar het is ook, denk ik, dat ze de controle achter het platform worstelen in plaats van dat het naar een derde gaat party-database, ze brengen het nu terug naar hun eigen platform. Denk je dat bedrijven die boodschap daadwerkelijk hebben gekregen? Denk je dat mensen dat begrijpen en er nu op inspelen? Of is het nog steeds een beetje onduidelijk, denk je, op de markt?
Bill Ellis: Ik denk niet dat het SAP verlegen is om te communiceren en mensen die naar SAPPHIRE zijn gegaan, hebben HANA overal gezien. Dus ik denk dat mensen zich er terdege van bewust zijn, maar de menselijke natuur is wat het is, weet je, sommige mensen zijn een beetje aan het slepen met hun voeten.
Dez Blanchfield: Omdat ik denk dat de reden dat ik die vraag stelde, en je me moet vergeven, maar het is dat ik het ermee eens ben. Ik denk dat ze niet verlegen zijn geweest om het te communiceren. Ik denk dat het signaal op veel manieren is verdwenen. En ik ben het met je eens - ik weet niet dat iedereen al is gesprongen. Weet je, traditionele ondernemingen, zeer grote ondernemingen die dit runnen, zijn nog steeds op veel manieren, niet helemaal aan het slepen, maar proberen gewoon te worstelen met de complexiteit van de verschuiving. Omdat ik denk dat het enige dat je tool, en zeker je demonstratie vandaag heeft benadrukt, en voor mij, een belangrijke afhaalmaaltijd wil ik dat iedereen die vandaag luistert en afgestemd is om rechtop te zitten en aandachtig naar te kijken is, je hebt een tool nu, dat heeft dat proces in mijn gedachten vereenvoudigd. Ik denk dat er een stel zeer nerveuze CIO's en hun teams onder hen zijn die denken: "Hoe maak ik de overgang van traditionele RDBMS, relationele databasebeheersystemen, die we al tientallen jaren kennen, naar een geheel nieuw paradigma van computing en opslagbeheer in een ruimte die nog steeds relatief dapper is? ”in mijn gedachten. Maar het is op veel manieren onbekend, en er zijn maar weinig mensen die die verschuiving op andere gebieden hebben gemaakt, dat het niet is alsof ze een ander onderdeel van het bedrijf hebben dat al een overstap naar in-memory computing heeft gemaakt. Het is dus een alles-of-niets beweging in hun gedachten.
Dus een van de dingen die ik hier meer dan wat dan ook van heb weggenomen - ik ga je zo meteen een vraag stellen - is dat angst nu, denk ik, op veel manieren is weggenomen en dat vóór vandaag, als ik een CIO was die luisterde, zou ik min of meer denken: 'Nou, hoe ga ik deze overgang maken? Hoe ga ik dezelfde capaciteiten garanderen die we hebben in het relationele databasebeheerplatform en jarenlange ervaring van DBA's, naar een nieuw platform waar we momenteel niet de vaardigheden in hebben? ”Dus mijn vraag daarmee is, denk je dat mensen begrepen hebben dat de tools er nu zijn met wat je aanbiedt, en dat ze soort van diep kunnen ademen en zucht van opluchting dat de overgang niet zo eng is als eerder dat deze tool beschikbaar is? Denk je dat mensen dat hebben begrepen of is het nog steeds een soort dat ze gewoon worstelen met de overgang naar in-memory computer- en in-geheugenopslag versus old-school combinaties van NVMe, flash en disk?
Bill Ellis: Ja, dus er is ongetwijfeld veel technologie en tools die dit grafisch kunnen weergeven, wat er gebeurt en het heel gemakkelijk maken om de beste consumenten van bronnen te identificeren. Ik bedoel, het helpt dingen te vereenvoudigen en het helpt het technologiepersoneel echt een goede greep te krijgen. Hé, ze zullen weten wat er aan de hand is en alle complexiteit kunnen begrijpen. Dus absoluut, de tools op de markt zijn absoluut nuttig en daarom bieden we werklastanalyse voor SAP HANA.
Dez Blanchfield: Ja, ik denk dat het mooie van wat je ons vandaag hebt laten zien, is dat, bij het bewaken van het stuk hardware, het stuk besturingssysteem, zelfs het monitoren van een deel van de werklast die doorloopt, zoals je zei, ik bedoel, de tools ben er al een tijdje. Het beetje voor mij, met name bij HANA, is dat we niet noodzakelijkerwijs de mogelijkheid hebben gehad om een vergrootglas te krijgen en erin te kijken en precies te zien wat uw tool doet met wat er gebeurt met de vragen en hoe ze gestructureerd zijn en waar die belasting is.
Met de implementaties die je tot nu toe hebt gezien, gezien het feit dat je letterlijk de meest gezaghebbende bent in deze ruimte op je platform ter wereld, enkele van de quick wins die je hebt gezien - heb je anekdotische kennis waarmee je kunt delen ons rond enkele van de eureka-momenten, de aha-momenten, waar mensen de IDERA-toolset hebben geïmplementeerd, hebben ze dingen ontdekt waarvan ze zich niet bewust waren dat ze op hun platforms en uitvoeringen stonden. Heb je geweldige anekdotische voorbeelden van waar mensen het net hebben geïmplementeerd, niet echt wetende wat ze hebben gehad en ineens verdwenen: "Wow, we wisten eigenlijk niet dat daarbinnen zat?"
Bill Ellis: Ja, dus een grote beperking van de native tools is dat als een weggelopen query wordt geannuleerd, deze de informatie wegspoelt en dus eigenlijk niet over de geschiedenis beschikt. Door de geschiedenis offline op te slaan, zoals een weggelopen query, hebt u een geschiedenis, weet u wat er is gebeurd, kunt u het uitvoeringsplan zien, enzovoort. En dus, waarmee u de eindgebruikersgemeenschap in principe beter kunt laten werken, rapporten beter kunt schrijven, enzovoort. En dus is de geschiedenis iets heel leuks om te hebben. En een van de dingen die ik had willen laten zien, is dat je tot vier weken in realtime kunt kijken en vervolgens eenvoudig kunt inzoomen op elk gewenst tijdsbestek en vervolgens de onderliggende rijactiviteit kunt blootleggen. Alleen die zichtbaarheid is iets dat erg handig is om te weten welk knelpunt is ontstaan.
Dez Blanchfield: Je zei dat het multi-user is, zodra het is geïmplementeerd, en ik was behoorlijk onder de indruk van het feit dat het op veel manieren agentloos en effectief zero-touch is. Is het normaal dat een enkele implementatie van uw tool vervolgens beschikbaar is voor iedereen van het netwerkverwerkingscentrum in het NOC en kijkt naar de kerninfrastructuur die het cluster tot aan het applicatie- en ontwikkelteam ondersteunt? Is het de norm en implementeer je het één keer en zij zouden dat delen, of verwacht je dat mensen modelinstanties kunnen hebben die naar verschillende delen van de stapel kijken? Hoe ziet dat eruit?
Bill Ellis: Dus het basisteam zal doorgaans een zeer sterke interesse hebben in de technologische onderbouwing van wat er in SAP gebeurt. Natuurlijk zijn er meerdere teams die hele landschappen ondersteunen. Het HANA-stuk is daar gewoon op gericht. Ik ga gewoon standaard naar het SAP-basisteam als de primaire consumenten van de informatie.
Dez Blanchfield: Rechts. Het valt me echter op dat als ik een ontwikkelteam heb of zelfs niet alleen op codeniveau, maar als ik een team van datawetenschappers of analisten heb die analytisch werk doen aan de datasets daar, vooral gezien het feit dat er een belangrijke duw in de richting van datawetenschap die nu wordt toegepast op alles binnen organisaties - en corrigeer me als ik het mis heb - lijkt me dat dit ook voor hen van groot belang zal zijn, omdat je in veel opzichten van de serieuze dingen die je kunt doen in een datawarehouse-omgeving, laat een datawetenschapper er op los en laat het gewoon beginnen met het doen van ad hoc vragen. Heb je voorbeelden van dat soort dingen gehad waarbij winkels je hebben gebeld en hebben gezegd: "We hebben een data science-team naar het ding gegooid, het doet echt pijn, wat kunnen we voor hen doen versus wat we doen in slechts traditionele operationele monitoring en beheer? ”Is dat zelfs iets?
Bill Ellis: Nou, ja, ik zou dit een beetje willen omdraaien en mijn antwoord afsnijden zou zijn dat, kijkend naar prestaties, prestatiebewust zijn bij het ontwikkelen van QA-productie, weet je, hoe eerder je opslaat, hoe minder problemen, minder verrassingen die je hebt. Dus absoluut.
Dez Blanchfield: In het verlengde daarvan, veel van de tools waarmee ik ervaring heb gehad - en ik ben er zeker van dat Robin het daarmee eens zal zijn - veel van de tools hier, als je een groot RDBMS hebt, heb je echt hoge- bekwame, diep geïnformeerde, ervaren DBA's. Een deel van de infrastructuur- en platformvereisten die bij SAP HANA gelden, omdat het momenteel naar mijn beste weten wordt ondersteund op bepaalde distributies die van bepaalde hardware zijn afgestemd, enzovoort. Weet je, er zijn mensen met tientallen jaren ervaring die niet hetzelfde zijn. Wat ik echter zie, is dat dat niet noodzakelijk de vereiste is met deze tool. Het lijkt mij dat je je tool kunt inzetten en aan een aantal vrij nieuwe gezichten kunt geven en ze meteen de kracht kunt geven om dingen te vinden die niet goed presteren. Is het zo dat er een vrij korte leercurve is om hiermee aan de slag te gaan en enige waarde uit de inzet te halen? Weet je, mijn algemene gevoel is dat je geen 20 jaar ervaring hoeft te hebben met het besturen van een hulpmiddel om de waarde onmiddellijk te zien. Ben je het ermee eens dat dit het geval is?
Bill Ellis: Oh absoluut, en tot op dit punt denk ik dat veel van het succes van een implementatie echt afhangt van de planning en architecturering van de SAP HANA-omgeving. En dan is er ongetwijfeld veel complexiteit, veel technologie waarop het is gebouwd, maar dan komt het er gewoon op aan de gebruikspatronen te volgen van wat er gebeurt. Dus hoewel het complexer is, is het op een bepaalde manier verpakt en enigszins vereenvoudigd. Dat is erg arm.
Dez Blanchfield: Ja, dus voordat ik terugga naar Eric, omdat ik weet dat hij een paar vragen heeft, vooral van sommige die door Q&A zijn gekomen en die interessant leken, en ik wil graag het antwoord horen. Traditionele reis voor iemand - je zei eerder dat je het kunt krijgen, je kunt het downloaden en proberen. Kun je daar snel op terugkomen voor folk luisteren vandaag of folk die het later misschien opnieuw speelt? Wat zijn de snelle twee of drie stappen om een exemplaar te bemachtigen en te implementeren en het in hun omgeving uit te proberen voordat ze het kopen? Hoe ziet dat eruit? Wat zijn de stappen daarvoor?
Bill Ellis: Ja. Dus, IDERA.com en ga gewoon naar Producten en u ziet Workload Analysis for SAP HANA. Er is een downloadpagina. Ik denk dat ze je om wat contactinformatie zullen vragen en het product is gewoon verpakt met een licentiesleutel, zodat je het kunt installeren met Setup.exe en ik denk dat het snel aan de gang gaat.
Dez Blanchfield: Dus ze kunnen naar je website gaan, ze kunnen het downloaden. Ik herinner me dat ik er een tijdje geleden naar heb gekeken en ik heb het gisteravond ook dubbel gecontroleerd, je kunt een demo uit het geheugen aanvragen, waar iemand in je team je er een beetje doorheen zal leiden? Maar u kunt het eigenlijk gratis downloaden en lokaal in uw eigen omgeving en in uw eigen tijd implementeren, toch?
Bill Ellis: Ja.
Dez Blanchfield: Uitstekend. Nou denk ik, meer dan wat dan ook, dat is waarschijnlijk het ding dat ik folk persoonlijk zou adviseren om te doen, een kopie van de website halen, een deel van de documentatie daar halen, omdat ik weet dat er veel goede inhoud is om dat mee te doen, en probeer het gewoon. Plaats het in uw omgeving en kijk wat u vindt. Ik vermoed dat als je eenmaal onder de motorkap kijkt met je SAP HANA-omgevingen met de IDERA-tool, je dingen zult vinden waarvan je je eigenlijk niet bewust was dat ze erin zaten.
Kijk, heel erg bedankt daarvoor en bedankt voor de tijd alleen voor de Q&A met Robin en I. Eric, ik ga terug naar jou omdat ik weet dat sommige Q & A's ook doorkomen van onze aanwezigen.
Eric Kavanagh: Ja, gewoon een hele snelle hier. Dus een van de aanwezigen maakt hier echt een goede opmerking over alleen maar hoe dingen veranderen. In het verleden zei het dat het geheugen verstikte, vertraagde door frequent paging, momenteel verstoort de CPU met teveel gegevens in het geheugen. Weet je, er zijn netwerkproblemen. Het zal altijd een bewegend doelwit zijn, toch? Wat zie je tegenwoordig als het traject in termen van waar de knelpunten komen en waar je je aandacht op moet richten?
Bill Ellis: Ja. Totdat je meet, is het moeilijk om te weten. Een van de dingen met de SQL-instructies is dat ze de drijvende krachten achter het gebruik van hulpbronnen zullen zijn. En dus in de omstandigheid dat u een groot geheugen- of CPU-verbruik zou moeten hebben, zult u erachter kunnen komen welke activiteit dat brongebruik heeft veroorzaakt. Nu, je zou het niet noodzakelijkerwijs willen doden, maar je wilt er ook bewust van zijn en, soort van, wat er gebeurt, hoe vaak gebeurt het, enzovoort. We zijn eigenlijk nog steeds nieuw in termen van het aanpakken van de hele set of het kookboek met reacties op verschillende omstandigheden. En dus is het een geweldige vraag en de tijd zal het leren. We zullen meer informatie krijgen naarmate de tijd verstrijkt.
Eric Kavanagh: Dat is alles. Wel, jullie staan op een heel interessante plek. Ik denk dat je de komende maanden en de komende jaren veel activiteit zult zien, omdat ik weet dat SAP, zoals je in onze inhoudsoproep suggereerde, een mooie lange weg heeft afgelegd voor mensen om de overstap te maken aan HANA. Maar toch, die helling heeft een einde en op een bepaald punt zullen mensen serieuze beslissingen moeten nemen, dus hoe eerder hoe beter, toch?
Bill Ellis: Absoluut.
Eric Kavanagh: Oké mensen, we hebben hier nog een uur gebrand op Hot Technologies. U vindt informatie online, insideanalysis.com, ook techopedia.com. Focus op die site voor veel interessante informatie, waaronder een lijst van al onze archieven van deze afgelopen webcasts. Maar mensen, heel erg bedankt aan jullie daar, aan onze vrienden bij IDERA, aan Robin en natuurlijk aan Dez. En we zullen je volgende week inhalen, mensen. Nogmaals bedankt voor je tijd en aandacht. Wees voorzichtig. Tot ziens.
