Af Techopedia Staff, 25. januar 2017
Takeaway: Værten Eric Kavanagh diskuterer computerhukommelse og SAP HANA med gæsterne Dr. Robin Bloor, Dez Blanchfield og IDERAs Bill Ellis.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer. Hej og velkommen igen. Det er klokken fire østlig tid på en onsdag og de sidste par år, hvilket betyder, at det igen er tid for Hot Technologies. Ja, ja, jeg hedder Eric Kavanagh, jeg vil være din vært for dagens samtale.
Og folkens, vi skal tale om nogle seje ting i dag. Vi vil dykke ned i hukommelsenes verden, den nøjagtige titel er "Into the Future: A On-Ramp for In-Memory Computing." Det er alt det vrede i disse dage, og med god grund, mest fordi in- hukommelsen er så meget hurtigere end at stole på spindeskiver. Udfordringen er dog, at du skal omskrive en masse software. Fordi nutidens software, det meste af det, er skrevet med en disk i tankerne, og det ændrer programmets arkitektur virkelig. Hvis du designer applikationen til at vente på en spindisk disk, gør du bare ting anderledes end hvis du har al den kraft i hukommelsesteknologien.
Der er virkelig et sted om dit, slå mig på Twitter, @eric_kavanagh. Jeg prøver altid at følge tilbage og også gentweet når som helst nogen nævner mig.
Som jeg sagde, taler vi om i hukommelsen i dag og specifikt om SAP HANA. Din ven tilbragte det sidste år virkelig at kende SAP-samfundet virkelig godt, og det er et fascinerende miljø, må jeg sige. Hatte af til de mennesker, der kører denne operation og er i frontlinierne, fordi SAP er en utrolig god operation. Hvad de virkelig er meget gode til er at drive forretning. De er selvfølgelig også gode til teknologi, og de har virkelig lagt en tung investering i HANA. Faktisk kan jeg huske - det var sandsynligvis for omkring seks eller syv år siden - at vi udførte noget arbejde for det amerikanske luftvåben faktisk, og vi fik nogen fra SAP til at komme ind og give os et tidligt kig på verden af HANA og hvad der var planlagt. Og mildt sagt, folkene på SAP Labs havde lagt meget tid og kræfter på at forstå, hvordan man bygger ud denne arkitektur, som igen er helt anderledes end traditionelle miljøer, fordi man har alt i hukommelsen. Så de taler om at gøre både transaktionelle og analytiske på samme data i hukommelsen, i modsætning til den traditionelle måde, der er at trække det ud, lægge det i en terning, for eksempel analysere det der, kontra transaktion, som sker på en meget anden måde.
Dette er et interessant rum, og vi vil finde ud af det fra en anden leverandør, IDERA, lidt om, hvordan alt det her skal arbejde, og hvad rampen handler om, helt ærligt. Så vi hører fra Dr. Robin Bloor, vores helt egen chefanalytiker her i The Bloor Group; Dez Blanchfield, vores dataforsker og derefter gode ven Bill Ellis fra IDERA. Så med det vil jeg aflevere nøglerne til Dr. Robin Bloor, som vil fjerne det.
Dr. Robin Bloor: Ja, som Eric sagde, den gang, vi først blev orienteret af SAP HANA, var tilbage for mange år siden, nu. Men det var meget interessant, det bestemte tidspunkt var meget interessant. Vi ville løbe ind i et eller to firmaer, der på en eller anden måde tilbød in-memory-teknologi. Det var helt klart, at hukommelsen skulle komme. Og det var virkelig ikke, før SAP rejste sig og pludselig lancerede HANA. Jeg mener, det var chok, da jeg så SAP gøre det. Det var ligesom det var et chok, fordi jeg forventede, at det skulle komme andetsteds. Jeg forventede, at det ville være, du ved, Microsoft eller Oracle eller IBM eller nogen som sådan. Ideen om, at SAP gjorde det, var virkelig meget overraskende for mig. Jeg formoder, at det ikke burde have været, fordi SAP er en af de strategiske leverandører og stort set, ved du, alt det store, der sker i branchen, kommer fra en af dem.
Uanset hvad, hele punktet om hukommelse, mener jeg, vi indså, at vi plejede at tale om det, at så snart du faktisk går ind i hukommelsen - dette handler ikke om at lægge data i hukommelsen, dette handler om at forpligte sig til forestil dig, at hukommelseslaget er systemposten - så snart du migrerer systemposten til hukommelsen, begynder disk at blive et overdragelsesmedium af en slags, og det bliver en anden ting. Og jeg syntes, det var meget spændende, da det begyndte at ske. Så det er virkelig forbi at dreje disk. Spinnedisk vil snart kun findes på museer. Jeg er ikke sikker på, hvor snart det snart er, men grundlæggende er solid-state disk nu på Moore's lovkurve, det er allerede ti gange hurtigere end roterende rust, som de nu kalder det, og temmelig snart vil det være hurtigere og så betyder det, at brug af sager til disk bare bliver færre og færre.
Og den underlige kendsgerning, traditionel DBMS, faktisk blev der bygget en masse traditionel software til spindisk disk, antog den spindisk disk. Det havde alle mulige fysiske niveauer, der var omhyggeligt programmeret i for at udnytte spindisk disk, hvilket gjorde dataindhentning så hurtig som muligt. Og alt dette bliver vasket væk. Bare forsvinder, ved du? Og så var der åbenlyst en meget - jeg ved ikke, lukrativt, antager jeg, at det vil være til sidst - åbning for en database i hukommelsen, der forsøgte at besætte den position, som de store databaser, Oracle og Microsoft, SQL Server og IBMs DB2, det optog i hukommelsesområdet, og det var meget interessant at se, der kom marsjerende frem og gør det.
Lad os tale om hukommelseskaskaden; det er bare værd at nævne. Det er også, grunden til at nævne dette, grunden til at jeg kastede dette ind, var virkelig bare for at lade alle vide, når jeg taler om hukommelse her, er alle disse lag, jeg taler om, faktisk hukommelse. Men du er pludselig klar over, når du ser på dette, dette er en hierarkisk butik, det er ikke kun hukommelse. Og derfor gælder stort set alt, hvad vi lærte for længe for længe siden om hierarkisk butik. Og det betyder også, at enhver database i hukommelsen skal navigere sig igennem dette, nogle går bare igennem den på RAM selv, ved du. Og det er lige blevet større og større og større, og det er nu målt i megabyte. Men du har L1-cache, som er hundrede gange hurtigere end hukommelse, L2-cache 30 gange hurtigere end hukommelse og L3-cache ca. 10 gange hurtigere end hukommelse. Så du ved, der er en masse teknologi - ja, en hel del teknologi - har vedtaget strategien om at bruge disse cacher som, slags lagerplads på vej til at få ting udført, især databaseteknologi. Så du ved, det er en indflydelse.
Så har vi fået fremkomsten af 3D XPoint og IBM's PCM. Og det er næsten RAM-hastigheder, det er dybest set, hvad begge disse leverandører praler af. Brugssagerne er sandsynligvis forskellige. Den tidlige eksperimentering med dette er endnu ikke afsluttet. Vi ved ikke, hvordan det vil påvirke brugen af RAM og teknologien i hukommelsesdatabasen for den sags skyld. Du har derefter RAM versus SSD. I øjeblikket er RAM omkring 300 gange hurtigere, men naturligvis mindskes den multiple. Og SSD versus disk, der er cirka 10 gange hurtigere, hvis jeg forstår det. Så det er den slags situation, du har haft. Det er hierarkisk butik. At se på det på en anden måde, i hukommelsen er selvfølgelig helt anderledes. Så det øverste diagram viser to applikationer, begge har måske adgang til en database, men bestemt adgang til data om roterende rust. Og den måde, du faktisk får ting til at flyde gennem netværket, afhængigt af hvilke afhængigheder der er, er du har ETL. Så det betyder, at du ved, at data går over på roterende rust og derefter går af med at rotere rust for at gå hvor som helst, og for at komme overalt går de tilbage til spinning rust, hvilket er tre bevægelser. Og husk, at hukommelsen kan være hundrede tusind gange hurtigere end spindisk disk, og du er klar over, at det at tage data og lægge dem i hukommelsen gør det hele virkelig meget anderledes.
Så du har måske troet, hvad der ville ske, ville ske på hvad der er på skærmen lige her, måske har du troet, at ETL på en eller anden måde faktisk ville gå fra data til data i hukommelsen. Men faktisk gør det måske ikke det; faktisk har du måske situationen til højre her, hvor to applikationer faktisk kan affyre den samme hukommelse. Bestemt en i hukommelsesdatabasen kunne give dig denne mulighed, så længe du har låsningen og alt andet orkestreret omkring det. Så dette ændrer ikke bare hastigheden på tingene, dette ændrer, hvordan du faktisk konfigurerer applikationer og hele datastrømme.
Så det er en enorm slags påvirkning. Så hukommelsen er forstyrrende, ikke? Og det skulle vi få fra det, jeg sagde. Behandling i hukommelsen er i øjeblikket en accelerator, men det bliver normen. Det vil blive brugt, anvendt i henhold til applikationsværdien, og det er derfor meget, meget interessant, at SAP rent faktisk kommer ud med en version af deres ERP-software, der er i hukommelsen. Og latenstidsforbedringer op til tre størrelsesordrer er fuldstændigt mulige, og faktisk endnu mere end det er muligt, afhængigt af hvordan du gør det. Så du får enorme forbedringer i hastigheden ved at gå ind i hukommelsen. Og resultatet, SAP HANAs S / 4 - som de har udgivet, tror jeg, ja, folk siger, at det stadig frigives, men det blev bestemt frigivet sidste år - det er en spiludveksler i betragtning af SAPs kundegrundlag. Jeg mener, der er 10.000 virksomheder derude, der bruger SAP's ERP, og stort set alle er store virksomheder, ved du. Altså, ideen om, at de alle har et incitament til at gå ind i hukommelsen og bruge deres grundlæggende, fordi ERP næsten altid er grundlæggende applikationer, som virksomhederne kører, det er bare en enorm spiludveksler, og det vil være meget interessant. Men alt dette lyder selvfølgelig meget godt, men det skal konfigureres intelligent og det skal overvåges godt. Det er ikke så enkelt, som det lyder.
Når det er sagt, tror jeg, jeg vil give bolden videre til, hvem er denne fyr? Åh, australsk fyr, Dez Blanchfield.
Dez Blanchfield: Meget sjovt. Altid en hård handling at følge, Dr. Robin Bloor. Tak for at have mig i dag. Så stort emne, men spændende. Så jeg har valgt et billede, som jeg ofte fremkalder i tankerne, når jeg tænker på det moderne datasø og virksomhedens datalager, og mine små perler med data. Så her har jeg denne smukke sø omgivet af bjerge og bølger, der kommer ud, og bølgerne styrter ned over disse klipper. Dette er slags, hvordan jeg mentalt visualiserer, hvordan det ser ud i en stor datasø i disse dage. Bølgerne er batchjob, og realtidsanalyse kastes på data, der er klipperne. Og når jeg tænker på det som en fysisk sø, bringer den slags en wakeup call til mig, at du ved, omfanget af datalagerne, som vi bygger nu, grunden til, at vi kom med denne møntning og udtrykket en datasø er, at de er meget store, og de er meget dybe, og lejlighedsvis kan du have storme i dem. Og når vi gør det, er du altid nødt til at løse, hvad der skaber stormen.
Så i temaet for denne ting ser det ud til, at dette sireneopkald til in-memory computing faktisk er meget stærk og med god grund. Det medfører så mange betydelige kommercielle og tekniske gevinster. Det er en diskussion i et par timer på en anden dag. Men det generelle skift til computerhukommelse, for det første vil jeg bare dække, hvordan vi kom her, og hvad der gør dette muligt, fordi det, slags, sætter grundlaget for, hvor nogle af udfordringerne kan ligge først, og hvad vi har brug for at være opmærksomme på af og tænker på, i vores verden med at bevæge os væk fra traditionel gammel spindisk disk, der indeholder data og blive søget på og fra disken og ind i hukommelsen og ud af hukommelsen og ind i CPU'er, til nu fjerner vi næsten et af disse hele lag, at være den roterende disk. Fordi husk, at vi i de meget tidlige dage af computing, arkitektonisk, ikke flyttede os i lang tid fra mainframe eller mellemstore verden af det, vi oprindeligt tænkte på som kernehukommelse og trommelager, ved du.
Som Dr. Robin Bloor sagde, ændrede den tilgang, vi tog til at flytte data omkring computerarkitektur, ikke rigtig dramatisk i nogen tid, faktisk i et par årtier. Hvis du tænker over det faktum, at du ved, moderne computing, teknisk set, har eksisteret, hvis du vil benåde ordspillet i nogle 60-ulige år, ved du det, seks årtier og mere, og det er i den forstand, at du kan køb en boks fra hylden, som det var. Skiftet til ny arkitektur skete virkelig i mit sind, da vi skiftede ud fra tankegangen omkring mainframes og mellemhøjde og kernehukommelse og tromleopbevaringsarkitekturer, til de modige eller supercomputere, især som Seymour Cray, hvor ting som bagerste planplan blev en ting. I stedet for kun at have en rute til at flytte data hen over bagplanen eller bundkortet, som det kaldes i disse dage. Og indbygget hukommelse, ved du, i disse dage tænker folk ikke rigtig på, hvad det faktisk betyder, når de siger DIMM og SIMM. Men SIMM er en enkelt inline-hukommelse, og DIMM er dobbelt inline-hukommelse, og vi er blevet mere komplekse end det siden, og der er snesevis af forskellige hukommelsestyper til forskellige ting: nogle til video, nogle til bare generelle applikationer, nogle indbygget i CPU'er.
Så der var dette store skift til en ny måde, hvorpå data blev gemt og fået adgang til. Vi er ved at gennemgå det samme skift i en anden hel generation, men ikke så meget i selve hardwaren, men ved vedtagelsen af hardware i forretningslogikken og i datalogiklaget, og det er et andet stort paradigmeskift i mit sind .
Men bare kort om, hvordan vi kom hertil. Jeg mener, hardwareteknologi blev forbedret og forbedret dramatisk. Vi gik fra at have CPU'er, og ideen om en kerne var et temmelig moderne koncept. Vi tager det for givet nu, at vores telefoner har to eller fire kerner, og vores computere har to eller fire, eller endda otte, kerner på skrivebordet og otte og 12 og mere på, du ved, 16 og 32 endda på serverplatformen . Men det er faktisk en temmelig moderne ting, at kerner blev en kapacitet inden i CPU'er, og at vi gik fra 32-bit til 64-bit. Der skete et par store ting der: Vi fik højere urhastigheder på flere kerner, så vi kunne gøre ting parallelt, og hver af disse kerner kunne køre flere tråde. Pludselig kunne vi køre mange ting på de samme data på samme tid. 64-bit-adresseafstand gav os op til to terabyte RAM, hvilket er et fænomenalt koncept, men det er en ting nu. Disse flervejs bagflyplanarkitekturer, du kender, bundkort, engang kunne du kun gøre ting i en retning: baglæns og fremad. Og som med dagene med Cray-computeren og nogle af datidens supercomputer-design og nu i stationære computere og almindelige off-the-shelf, slags desktop-grade rack-mount-pc'er, for virkelig, det meste af det moderne PC'er har nu gennemgået denne æra med mainframe, midrange, micro desktops og vi har vendt dem tilbage til servere.
Og en masse af denne supercomputer-evne, det supercomputer-design, blev skubbet ind i fælles hyldekomponenter. I ved i dag, ideen om at tage meget billige rackmonterede pc'er og sætte dem i stativer af hundreder, hvis ikke tusinder, og køre open source-software på dem som Linux og implementere lignende af SAP HANA på det, du ved, vi tager det ofte for givet. Men det er en meget ny spændende ting, og den kommer med dens kompleksiteter.
Software blev også bedre, især hukommelsesstyring og datapartitionering. Jeg vil ikke gå ind på en masse detaljer om det, men hvis du ser på det store skift i de sidste 15 år, eller endnu mindre, hvordan hukommelse styres, især data i RAM, og hvordan data bliver partitioneret i RAM, så som Dr. Robin Bloor indikerede tidligere eller henvist til, du ved, kan ting læse og skrive på samme tid uden at påvirke hinanden, snarere end at have ventetider. En masse meget kraftfulde funktioner som komprimering og kryptering on-chip. Kryptering bliver en mere vigtig ting, og vi behøver ikke nødvendigvis at gøre det i software, i RAM, i CPU-plads, nu, der faktisk sker på chipen indfødt. Det fremskynder tingene dramatisk. Og distribueret datalagring og -behandling, igen, ting, som vi engang antog var de ting af supercomputere og parallel behandling, vi tager det nu for givet i det rum, der kan lide SAP HANA og Hadoop og Spark, og så videre.
Så alt det her er denne high-performance computing, HPC-kapaciteter kom til virksomheden, og nu nyder virksomheden de fordele, der følger med det i ydelsesgevinster og teknologirum og tekniske fordele og kommercielle gevinster, fordi du ved, den reducerede tidsværdi falder dramatisk.
Men jeg bruger dette billede af en historie, jeg læste for nogen tid siden af en herre, der byggede en pc-sag ud af Lego, fordi det altid kommer til at tænke på, når jeg tænker på nogle af disse ting. Og det er det, det virker som en god idé på det tidspunkt, hvor du begynder at bygge det, og så kommer du halvvejs igennem det, og du er klar over, at det faktisk er virkelig vanskeligt at sætte alle Lego-bitene sammen og gøre en solid ting, solid nok at lægge et bundkort osv., der bygger en sag til en personlig computer. Og til sidst er du klar over, at alle de små bits ikke klæber sammen rigtigt, og du er nødt til at være lidt forsigtig med, hvilke små bits du klæber sammen for at gøre det solidt. Og det er en meget sød idé, men det er et wakeup call, når du kommer halvvejs igennem, og du er klar over, "Hmm, måske skulle jeg bare have købt en pc-sag på $ 300, men jeg er færdig med det nu og lærer noget af det."
For mig er det en fantastisk analogi til hvordan det er at bygge disse meget komplekse platforme, fordi det er godt og godt at bygge det og ende med et miljø, hvor du har routere og switches og servere og stativer. Og du har CPU'er og RAM og operativsystem samlet i hinanden. Og du lægger noget som HANA oven på det til den distribuerede in-memory-behandling og datalagring og datastyring. Du bygger SAP-stakken oven på det, du får databasefunktionerne, og derefter indlæser du dine data og din forretningslogik, og du begynder at anvende nogle læse- og skrive- og forespørgsler osv. På den. Du er nødt til at følge med i I / O, og du er nødt til at planlægge ting og styre arbejdsmængder og multitenancy osv. Denne stak bliver meget kompleks meget hurtigt. Det er en kompleks stak i sig selv, hvis det kun er på en maskine. Multiplicer det med 16 eller 32 maskiner, det bliver meget, meget ikke-trivielt. Når du multiplicerer op til hundreder og til sidst tusinder af maskiner for at gå fra 100 terabyte til petabyte skala, er det et skræmmende koncept, og det er disse realiteter, vi har at gøre med nu.
Så ender du så med et par ting, der også har bidraget til at ændre denne verden, og det er, at diskpladsen blev latterligt billig. Du ved, engang havde du brugt 380 til 400 tusind dollars på en gigabyte harddisk, da det var en massiv tromme på størrelse med - noget, der havde brug for en gaffeltruck for at hente den. I disse dage er det nede på, slags en eller to cent pr. Gigabyte med diskplads til råvare. Og RAM gjorde den samme ting. Disse to J-kurver i begge disse grafer er forresten et årti, så vi ser med andre ord på to blokke på 10 år, 20 års prisreduktion. Men jeg bragte dem i to J-kurver, fordi den til højre til sidst bare blev en prikket linje, og du kunne ikke se detaljen i, så jeg skalerede den igen. En gigabyte RAM for 20 år siden var noget i størrelsesordenen seks og en halv million dollars. I disse dage, hvis du betaler mere end tre eller fire dollars for en gigabyte RAM for råvarehardware, bliver du frarøvet.
Disse betydelige tumbling af prisfald i de sidste to årtier har betydet, at vi nu kan bevæge os ud over diskplads og lige ind i RAM, ikke kun på megabyteniveauet, men nu terabyte-niveauet og behandle RAM som dets disk. Udfordringen med det var dog, at RAM var naturligt flydende - det betyder noget, der varer i en kort periode - så vi har måttet finde frem til måder at give modstandskraft i det rum.
Og så, mit punkt her er, at in-memory computing ikke er for svage hjerter. At jonglere disse meget store skalaer i hukommelsen og behandlingen omkring dem er en interessant udfordring; som jeg antydet tidligere, er det ikke for svage hjerter. Så en ting, vi har lært af denne erfaring med storskala og høj tæthed inden for hukommelse, er, at den kompleksitet, vi bygger, skaber risiko på et antal områder.
Men lad os bare se på det fra et overvågnings- og responsperspektiv. Når vi tænker på dataene, begynder de på diskplads, de sidder i databaser på diske, vi skubber dem op i hukommelsen. Når den først er i hukommelsen og distribueres, og der er kopier af den, kan vi bruge masser af kopier af den, og hvis der foretages ændringer, kan det afspejles på hukommelsesniveau i stedet for at skulle gå til og fra og på tværs af bagplanen ved to forskellige niveauer, det går ind og ud af hukommelsen. Vi er endt med denne hyperscale-hardwareplatform, der giver os mulighed for at gøre dette nu. Når vi taler om hyperskalering, er det sværere ved latterligt tætte niveauer og hukommelse med meget høj densitet, tællinger med meget høj densitet af CPU'er og kerner og tråde. Vi har nu fået meget yderst komplekse netværkspatologier til at understøtte dette, fordi dataene skal bevæge sig over netværket på et tidspunkt, hvis de vil gå mellem noder og klynger.
Så vi ender med at redundans af enhedsfejl bliver et problem, og vi er nødt til at overvåge enheder og stykker af det. Vi er nødt til at have en robust redundans for datafeil indbygget i denne platform og overvåge den. Vi skal have den distribuerede databasespænding indbygget, så vi er nødt til at overvåge databaseplatformen og stakke inde i den. Vi er nødt til at overvåge den distribuerede behandlingsplanlægning, hvad der sker inden for nogle af processerne helt ned til polling og forespørgsel og den sti, som forespørgslen tager, og den måde, forespørgslen struktureres og udføres. Hvordan ser det ud, har nogen lavet en SELECT * på “bla”, eller har de faktisk lavet en meget smart og velstruktureret forespørgsel, der får dem til den nominelle, minimale mængde data, der kommer over arkitekturen i bagplanen? Vi har flere arbejdsmængder, flere brugere og flere grupper, der kører den samme eller flere arbejdsbelastninger og batchjob og realtidsplanlægning. Og vi har denne blanding af batch og realtidsbehandling. Nogle ting kører bare regelmæssigt - hver time, dagligt, ugentligt eller månedligt - andre ting er på efterspørgsel. Der sidder måske nogen med en tablet, der ønsker at udarbejde en realtidsrapport.
Og igen kommer vi til det hele punkt, at kompleksiteten, der opstår i disse ikke bare er en udfordring nu, det er ret skræmmende. Og vi har denne virkelighedskontrol af, at et enkelt ydelsesproblem, kun et præstationsspørgsmål i sig selv, kan påvirke hele økosystemet. Og så ender vi med denne meget sjove udfordring med at finde ud af, ja, hvor er konsekvenserne? Og vi har denne udfordring, er vi reaktive eller proaktive? Ser vi tingene i realtid og ser noget blive "bang" og reagere på det? Eller har vi set en form for tendens og indset, at vi proaktivt skal komme om bord med det? Fordi nøglen er, at alle vil have noget hurtigt og billigt og let. Men vi ender med disse scenarier, det, jeg gerne henviser til, og min favoritlinje af Donald Rumsfeld conundrum - som efter min mening gælder i alle disse scenarier med høj kompleksitet - og det er det, vi har kendt kendte, fordi det er noget vi designet og bygget, og det kører som planlagt. Vi har kendt ukendte, idet vi ikke ved, hvem der kører hvad, hvornår og hvor, hvis det er på efterspørgsel. Og vi har ukendte ukendte, og det er de ting, vi skal overvåge og kontrollere for. Fordi virkeligheden er, ved vi alle, at du ikke kan styre noget, du ikke kan måle.
Så for at have de rigtige værktøjer og den rigtige kapacitet til at overvåge vores CPU-planlægning, kig efter ventetider, find ud af, hvorfor ting skal vente i tidsplankøer i rørledninger. Hvad sker der i hukommelsen, hvilken type udnyttelse der udføres, hvilken slags ydelse får vi ud af hukommelsen? Opdeles ting korrekt, distribueres det, har vi nok knuder med kopier af det til at klare de arbejdsmængder, der kastes på det? Hvad sker der med procesudførelse væk fra styresystemets processer? Jobberne selv kører, de enkelte apps og dæmonerne der understøtter dem? Hvad sker der inden i disse processer, især strukturering af forespørgsler, og hvordan udføres og udarbejdes disse forespørgsler? Og sundheden ved disse processer helt ud i stakken? Du ved igen, tilbage til ventetider, er det planlægning korrekt, er det nødvendigt at vente, hvor er det venter, er det venter på hukommelse læser, I / Os, CPU, I / O på tværs af netværket til slutbrugeren ?
Og så tilbage til det punkt, jeg lige har nævnt lige hurtigt, før jeg slår sammen, og det er det, hvordan nærmer vi os problemløsning og svartider til disse? Ser vi i realtid og reagerer på ting, som er det mindst ideelle scenario, men selv da er det bedre, at vi gør det end ikke at vide, og få hjælp til at ringe til help desk og sige, at noget gik galt, og vi er nødt til at spore det op ? Eller gør vi det proaktivt, og ser vi på hvad der kommer på linjen? Så med andre ord, ser vi, at vi mangler hukommelse og har brug for at tilføje flere noder? Gør vi trendanalyse, laver vi kapacitetsplanlægning? Og alt i alt overvåger vi historiske udførelsestider og tænker på kapacitetsplanlægning, eller ser vi det i realtid og proaktivt omplanlægger og udfører belastningsbalancering? Og er vi klar over de arbejdsmængder, der kører i første omgang? Ved vi, hvem der laver hvad i vores klynge, og hvorfor?
Computere i hukommelsen er meget magtfulde, men med den magt er det næsten en af disse ting, f.eks. En indlæst pistol, og du spiller med live ammunition. Du kan til sidst skyde dig selv i foden, hvis du ikke er forsigtig. Så den magt i hukommelse beregner bare betyder, at vi kan køre meget mere og hurtigt på tværs af meget distribuerede og diskrete datasæt. Men så får det derefter en større efterspørgsel fra slutbrugere. De vænner sig til den magt, og de vil have den. De forventer ikke længere, at der tager uger, at der løber job, og rapporter dukker op i almindeligt gammelt papir. Og så, under alt det, har vi den daglige vedligeholdelse omringet programrettelse, opdateringer og opgraderinger. Og hvis du tænker over 24/7 behandling med in-memory compute, styring af disse data, styring af arbejdsmængder på tværs af det, er det alt sammen i hukommelsen, teknisk set i en flygtig platform, hvis vi skal begynde at anvende programrettelser og opdateringer og opgraderinger der, der kommer med en hel række andre styrings- og overvågningsudfordringer også. Vi er nødt til at vide, hvad vi kan tage offline, hvornår vi kan opgradere det, og når vi bringer det tilbage online. Og det bringer mig til mit sidste punkt, og det er, at når vi får mere og mere kompleksitet i disse systemer, er det ikke noget, et menneske kan gøre bare ved at sutte tommelfingeren og trække øret mere. Der er ingen, slags slags magefølelse nærmer sig længere. Vi har virkelig brug for de passende værktøjer til at styre og levere dette høje ydeevne inden for beregning og datastyring.
Og med det i tankerne overdrager jeg til vores ven fra IDERA og hører, hvordan de har taget denne udfordring op.
Bill Ellis: Mange tak. Jeg deler min skærm ud og her går vi. Så det er virkelig ydmygende at bare overveje al teknologi og alle de mennesker, der kom foran os, for at stille disse ting, der er tilgængelig i 2017, til rådighed. Vi vil tale om arbejdsbelastningsanalyse til SAP HANA - dybest set en databaseovervågningsløsning: omfattende, agentløs, giver realtid og den bygger ud en historie, og så kan du se, hvad der er sket i fortiden. SAP S / 4 HANA tilbyder potentialet for bedre, hurtigere og billigere. Jeg siger ikke, at det er billigt, jeg siger bare, at det er billigere. Typisk, hvad der skete, traditionelt var, at du ville have en hovedproduktionsinstans - sandsynligvis køre på Oracle i en større butik, potentielt SQL Server - og så ville du bruge den ETL-proces, og du ville have flere, slags versioner af sandheden . Og det er meget dyrt, fordi du betalte for hardware, operativsystem, Oracle-licens for hvert af disse individuelle miljøer. Og så skal du oven i købet have folk til at forene en version af sandheden med den næste version af sandheden. Og så, denne multiple-version ETL-behandling var bare langsom og meget, meget besværlig.
Og så kan HANA, dybest set en HANA-instans, potentielt erstatte alle disse andre tilfælde. Så det er billigere, fordi det er en hardwareplatform, et operativsystem i stedet for multipla. Og så S / 4 HANA, virkelig, det ændrer alt, og du ser dybest set på udviklingen af SAP fra R / 2 til R / 3, de forskellige forbedringspakker. Nu er arvssystemet tilgængeligt indtil 2025, så du har otte år, indtil du virkelig bliver tvunget til at migrere. Selvom vi ser mennesker, kender du, der dypper deres tæer ind i dette, fordi de ved, at det kommer, og til sidst, du ved, vil ECC køre på HANA, og så skulle du virkelig være forberedt på det og forstå teknologien.
Så en database, ingen ETL-processer, ingen kopier, der skal afstemmes. Så endnu en gang hurtigere, bedre og billigere. HANA er i hukommelsen. SAP leverer softwaren, du leverer hardware. Der er ingen samlede tabeller. En af de ting, som de slags antyder, når du tænker på dette, er at du ikke ønsker at komme ind på dette, vi skal bare købe den allerbedste server, der er tilgængelig. De foreslår, at du slags, rigtigt størrer dit SAP-landskab forud for tiden, og de siger dybest set, at du ikke migrerer 20-årige data. Jeg synes, arkivering er noget, der er underudnyttet i it, slags overalt, ikke kun i SAP-butikker. Og så er den næste ting, at SAP faktisk har brugt meget tid på at omskrive deres native kode for ikke at bruge SELECT *. VÆLG * returnerer alle kolonner fra tabellen, og det er især dyre i en kolonnedatabase. Og så er det ikke en god ide for SAP HANA. Så for butikker, der har en masse tilpasning, mange rapporter, er dette noget, du vil ønske at kigge efter, og du vil ønske at specificere kolonnenavne, når du skrider frem til at migrere alt til HANA.
Vi kan lide at sige, at HANA ikke er et universalmiddel. Som alle databaser, alle teknologier, skal det overvåges, og som nævnt tidligere har du brug for numre for at styre overskydende, måling ved måling. Og en af de ting, jeg taler om i IDERA-området, er, at enhver forretningstransaktion interagerer med registreringssystemet, og i dette tilfælde bliver det HANA. Og så bliver HANA fundamentet for udførelsen af dine SAP-transaktioner, slutbrugeroplevelsen. Og så er det vigtigt, at det fortsætter med at køre i tophastighed. Det bliver et enkelt mislykkelsespunkt, og når vi snakker med folk, er dette noget, der kan dukke op, hvor du har en slutbruger, og måske bruger disse realtidsdata, og de har en ad hoc-forespørgsel, der potentielt ikke er helt ret. Måske slutter de sig ikke til borde, og de har oprettet en ydre sammenføjning, et partiprodukt, og de bruger dybest set en masse ressourcer. Nu vil HANA genkende det til sidst og dræbe den session. Og så er der den afgørende del af vores arkitektur, der vil give dig mulighed for faktisk at fange det i historien, så du kan se, hvad der var sket i fortiden og genkende disse situationer.
Så lad os se på arbejdsmængdsanalysen til SAP HANA. Dette er version 1, så vi inviterer dig meget til at være med på rejsen, og dette er et produkt fra IDERA. Det er omfattende, men alligevel enkelt. Realtid med trending. Værtssundhed, for eksempel sundhed. Vi sporer ventetilstandene, SQL-forespørgsler, hukommelsesforbrugere og tjenester. Så dette er, hvordan GUI ser ud, og du kan se lige fra flagermus, at det er internetaktiveret. Jeg åbnede faktisk denne løsning, der kører live på mit system. Der er nogle afgørende ting, du vil se på. Vi har slags opdelt i forskellige arbejdsområder. Den mest afgørende er, hvad der sker på værtsniveau fra en CPU-anvendelse og hukommelsesudnyttelse. Du ønsker bestemt ikke at komme til et byttende eller spændende synspunkt. Og så arbejder du dybest set dig ned på, hvad der sker i tendens, fra responstid, brugere, SQL-udsagn, det vil sige, hvad der driver aktiviteten på systemet.
En af tingene med IDERA er, at du ved, der ikke sker noget i en database, før der er aktivitet. Og denne aktivitet er SQL-udsagn, der kommer fra applikationen. Så måling af SQL-udsagn er absolut vigtig for at være i stand til at opdage grundårsagen. Så lad os gå videre og bore i. Så på værtsniveau kan vi faktisk se på hukommelse, spore over tid, bruge CPU-udnyttelse. Gå tilbage, kan du se på COBSQL-udsagnene. En af de ting, du vil se på vores arkitekturside, er nu, at disse oplysninger gemmes uden for HANA, så hvis der skulle ske noget med HANA, indfanger vi grundlæggende oplysninger op til, Gud forby, en situation med utilgængelighed . Vi kan også fange alt, hvad der sker på systemet, så du har klar synlighed. Og en af de ting, vi skal gøre, er, at vi vil præsentere SQL-udsagnene i vægtet rækkefølge. Så det vil tage hensyn til antallet af henrettelser, og det er det samlede ressourceforbrug.
Og så kan du komme ind på individuelle målinger her - hvornår udførte den SQL-sætning? Og så styres ressourceforbruget i vid udstrækning af eksekveringsplanen, og derfor er vi i stand til at fange det løbende. HANA er i hukommelsen. Det er meget parallelt. Det har primære indekser på hver tabel, som nogle butikker vælger at oprette et sekundært indeks til at løse visse ydelsesproblemer. Og det kan meget værdifuldt at vide, hvad der skete med eksekveringsplanen for visse SQL-udsagn. Vi vil også se på tjenesterne, hukommelsesforbruget igen, kortlagt over tid. Arkitekturen: ja, dette er en selvstændig løsning, som du kan downloade fra vores hjemmeside, og arkitekturen er, at den er webaktiveret.
Du kan få flere brugere til at oprette forbindelse til en bestemt instans. Du kan overvåge lokale forekomster af SAP HANA. Og vi holder en rullende fire ugers historie i vores lager, og det er selvstyret. At implementere dette er det temmelig enkelt. Du har brug for en Windows Server. Du skal downloade det. De fleste Windows-servere har en indbygget .NET-ramme, og den leveres sammen med en licens. Og så gik du til installationsguiden, der er drevet af Setup.exe, og den åbner faktisk en skærm, licensaftale, og du vil blot arbejde på denne kontur ved at klikke på "Næste." Og så, hvor vil du, at HANA skal blive installeret? Dernæst er databaseegenskaber, og dette bliver din forbindelse til SAP HANA, så dette er agentløs overvågning af HANA-forekomsten. Og så giver vi dybest set en forhåndsvisning, dette er den port, som vi kommunikerer som standard. Klik på "Install", og det starter grundlæggende HANA, og du begynder at opbygge historikken. Så bare lidt af størrelsesdiagrammets oplysninger. Vi kan overvåge op til 45 HANA-forekomster, og du ønsker at bruge denne type på en glideskala til at bestemme antallet af kerner, hukommelse, diskplads, du har brug for. Og dette antager, at du har en komplet fire ugers rullende historie, der går ind.
Så lige som en hurtig sammenfattning ser vi på serversundhed, forekomstsundhed, CPU / hukommelsesudnyttelse. Hvad er hukommelsesforbrugerne, hvad er aktivitetsdriverne, hvad er tjenesterne? SQL-udsagn er vigtige - hvad er eksekveringstilstandene? Vis mig udførelsesplanerne, hvornår blev tingene kørt, giver trending? Dette vil give dig realtid og en historie om, hvad der var sket. Og som jeg nævnte, fordi vores historie er adskilt fra HANA, vi vil fange ting, der var udløbet og blev skyllet fra HANAs historie. Så du kan se det rigtige ressourceforbrug på dit system på grund af den separate historie.
Så som jeg havde nævnt, IDERAs websted under Produkter, kan du nemt finde dette. Hvis du vil prøve dette, er du bestemt velkommen til. Se, hvordan det giver oplysninger til dig, og der er yderligere oplysninger på det websted. Så alle interesserede parter er mere end glade for at gå ind på det. I de porteføljeprodukter, der tilbydes af IDERA, findes der også en SAP ECC-transaktionsmonitor, og dette kaldes Precise for SAP. Og hvad det gør er - uanset om du bruger portal eller bare oprette ECC - det vil faktisk fange slutbrugertransaktionen fra klik til disk, helt ned til SQL-sætningen og vise dig, hvad der sker.
Nu viser jeg dig kun en oversigtsskærm. Der er et par takeaways, som jeg vil have dig fra dette oversigtsskærmbillede. Det er Y-aksens responstid, X-aksens tid plus dagen, og i denne transaktionsvisning viser vi dig klienttid, køtid, ABAP-kodetid, databasetid. Vi kan fange slutbruger-id'er, T-koder, og du kan faktisk filtrere og vise servere via en bestemt transaktion, der er krydset. Og så mange butikker kører frontend af landskabet under VMware, så du faktisk kan måle, hvad der sker på hver af serverne og komme i en meget detaljeret analyse. Så denne transaktionsvisning er til slutbrugertransaktionen gennem hele SAP-landskabet. Og du kan finde det på vores websted under Produkter APM-værktøjer, og dette ville være den SAP-løsning, som vi har. Installationen til dette er lidt mere kompliceret, så det er ikke bare at downloade og prøve det, som vi har til HANA. Dette er noget, hvor vi vil arbejde sammen om at gøre, designe og implementere den samlede transaktion for dig.
Så bare en tredje hurtig sammenfattende, arbejdsbelastningsanalyse til SAP HANA, den er omfattende, agentløs, realtid, tilbyder en historie. Vi tilbyder muligheden for at downloade og prøve det til dit websted.
Så med det vil jeg vende tiden tilbage til Eric, Dez og Dr. Bloor.
Eric Kavanagh: Ja, måske Robin, spørgsmål fra dig, og derefter Dez efter Robin?
Dr. Robin Bloor: Okay. Jeg mener, den første ting, jeg gerne vil sige, er, at jeg virkelig kan lide transaktionsvisningen, fordi det er nøjagtigt, hvad jeg vil have i den situation. Jeg udførte en masse arbejde - godt, det er længe siden lige nu - at udføre præstationsovervågning, og det var den slags ting; vi havde ikke grafikken i disse dage, men det var den slags ting, jeg især ønskede at kunne gøre. Så du kan på en eller anden måde injicere dig selv, uanset hvor problemet sker.
Det første spørgsmål, jeg har, er, ved du, de fleste mennesker implementerer S / 4 på en eller anden måde ude af kassen, ved du. Når du engagerer dig i en given implementering af S / 4, opdagede du, at det er implementeret godt, eller ender du, ved du, og opdagede ting, der muligvis får kunden til at ønske at konfigurere igen? Jeg mener, hvordan går alt sammen?
Bill Ellis: Nå, hver butik er lidt anderledes. Og der er forskellige brugsmønstre, der er forskellige rapporter. For websteder, der har ad hoc-rapportering, mener jeg, at det faktisk er en slags lignende et jokertegn på systemet. Og så er en af de afgørende ting at begynde måling og finde ud af, hvad basislinjen er, hvad der er normalt for et bestemt sted, hvor det pågældende websted, baseret på deres brugsmønstre, understreger systemet. Og derefter foretage justeringer derfra. Typisk er overvågningsoptimering ikke en engang, det er virkelig en løbende praksis, hvor du overvåger, tuning, finslipning, gør systemet bedre for slutbrugerfællesskabet til at kunne betjene virksomheden mere effektivt.
Dr. Robin Bloor: Okay, så når du implementerer - jeg mener, jeg ved, at dette er et svært spørgsmål at besvare, fordi det vil variere afhængigt af implementeringsstørrelse - men hvor meget ressource bruger IDERA-overvågningsevnen, hvor meget forbruger den ? Gør det nogen forskel for noget, eller er det bare en slags forstyrrelse? Hvordan fungerer det?
Bill Ellis: Ja, jeg vil sige, at omkostningen er cirka 1-3 procent. Mange butikker er meget villige til at ofre det, fordi du potentielt vil kunne købe det tilbage med hensyn til optimering. Det afhænger af brugsmønstre. Hvis du laver et fuldt landskab, afhænger det af de individuelle teknologier, der overvåges. Så slags kilometer varierer, men som vi talte om, er det bestemt bedre at bruge lidt på at vide, hvad der foregår, end bare at blinde. Især ville det være, ved du, her er vi i januar, og du kommer til behandling i weekenden, og du samler data på 12 måneder. Du ved, det gør resultater, at få rapporter til regulerende organisationer, bankerne, til aktionærerne, er absolut vigtig i en kritisk forretningspræstation.
Dr. Robin Bloor: Okay. Og bare en hurtig, fra dit perspektiv - fordi jeg antager, at du er ude der er involveret i en hel række SAP-websteder - hvor stor er bevægelsen blandt SAP-kundebasen mod S / 4? Jeg mener, er det noget, der er, ved du, at der er en slags snøskred af entusiastiske kunder, der går efter det, eller er det bare et konstant trick? Hvordan ser du det?
Bill Ellis: Jeg tror for et par år siden, jeg ville sige, det var en tå. Nu vil jeg sige, at folk er, slags, op til deres knæ. Jeg tror, at du ved, i betragtning af den tidslinje, folk vil blive virkelig nedsænket i HANA i løbet af de næste par år. Og så overvågningen, transformationen, ved du, jeg tror, at flertallet af kunder er slags på læringskurven sammen. Og så tror jeg, at vi ikke er helt i skred, som De havde sagt, men jeg tror, vi er på spidsen af den store transformation over til HANA.
Dr. Robin Bloor: Okay, så hvad angår de websteder, du har set, der har været for dette, tilpasser de også HANA til andre applikationer, eller er de på en eller anden måde slags forbrugt helt ved at fremstille dette ting arbejde? Hvad er billedet der?
Bill Ellis: Ja, ofte vil folk integrere SAP med andre systemer, afhængigt af hvilke moduler og så videre, så der er lidt. Jeg kan ikke rigtig se folk, der implementerer andre applikationer på HANA endnu. Det er bestemt muligt at gøre. Og så er det mere omkring landskabet omkring SAP-infrastrukturen.
Dr. Robin Bloor: Jeg formoder, at jeg hellere vil give dig videre til Dez. Jeg har taget din tid. Dez?
Dez Blanchfield: Tak. Nej, det er alt godt. To meget hurtige, bare for at prøve at indstille temaet. SAP HANA har været ude i et par år nu, og folk har haft en chance for at overveje det. Hvis du skulle give os et groft skøn over den procentdel af folk, der kører det - fordi der er mange mennesker, der kører disse ting - hvad tror du, at den procentdel af markedet, du er opmærksom på, i øjeblikket er gået fra bare traditionelle SAP-implementeringer til SAP på HANA? Ser vi på 50/50, 30/70? Hvilken procentdel af markedet ser du for mennesker, der har skiftet over og skiftet nu mod folk, der bare holder tilbage og venter på, at tingene skal forbedres eller blive bedre eller ændre sig, eller hvad der måtte være tilfældet?
Bill Ellis: Ja, jeg ville faktisk sætte procenten fra mit perspektiv omkring 20 procent. SAP har en tendens til at være traditionelle virksomheder. Folk har en tendens til at være meget konservative og så deres folk vil trække deres fødder. Jeg tror, det også afhænger af, ved du, har du kørt SAP i lang tid, eller er du en slags SMB, der måske havde for nylig implementeret SAP? Og så er der slags en række faktorer, men samlet set tror jeg ikke, at procentdelen er 50/50. Jeg vil sige, at 50 procent er mindst faldende og har HANA, der kører et sted i deres datacenter.
Dez Blanchfield: Det interessante takeaway, som du gav os tidligere, var, at dette er en fait accompli i en forstand, og at uret fysisk og bogstaveligt tikker på tidspunktet for overgangen. Tror du, at folk har overvejet det i processen? Hvad er den generelle fornemmelse af folkeforståelse, at dette er et overgangsskifte i platformen, det er ikke kun en mulighed, det bliver standard?
Og fra SAP's synspunkt er jeg sikker på, at de skubber på den måde, fordi der er en betydelig konkurrencefordel i ydeevnen, men det er også, antager jeg, at de kæmper kontrol bag platformen i stedet for at den går til en tredje- festdatabase, bringer de det nu tilbage til deres egen platform. Tror du virksomheder faktisk har fået den meddelelse? Tror du, at folk forstår det, og nu er der skridt til det? Eller er det stadig, slags, en uklar ting, tror du, ud på markedet?
Bill Ellis: Jeg synes ikke, SAP er genert over at kommunikere, og folk, der har været på SAPPHIRE, har set HANA overalt. Så jeg tror, folk er klar over, men den menneskelige natur, hvad det er, ved du, nogle mennesker er, slags, trækker deres fødder lidt.
Dez Blanchfield: Fordi jeg tror, at grunden til, at jeg stillede det spørgsmål, og du bliver nødt til at tilgive mig, men det er, at jeg er enig. Jeg tror, de ikke har været genert over at kommunikere det. Jeg tror, at signalet er gået ud på mange måder. Og jeg er enig med dig - jeg ved ikke, at alle er sprang endnu. Du ved, traditionel virksomhed, meget store virksomheder, der driver dette, er stadig på mange måder, ikke helt trækker fødderne, men bare prøver at kæmpe med skiftets kompleksitet. Fordi jeg tror, at den ene ting, som dit værktøj, og bestemt din demonstration i dag har fremhævet, og for mig, en vigtig takeaway, jeg gerne vil have, at alle lytter og var indstillet i dag til at sidde op og være opmærksomme på reflekterende, er, at du har en værktøj nu, der er forenklet den proces i mit sind. Jeg tror, der er en masse meget nervøse CIO'er og deres teams under dem, der tænker: ”Hvordan gør jeg overgangen fra traditionelle RDBMS, relationelle databasestyringssystemer, som vi har kendt i årtier, til et helt nyt paradigme af beregning og lagringshåndtering i et rum, der stadig er relativt modigt? ”i mit sind. Men det er en ukendt på mange måder, og der er meget få mennesker, der har skiftet skiftet på andre områder, at det ikke er som om de har et andet afsnit af forretning, der allerede har foretaget et skridt til beregning i hukommelsen. Så det er en alt-eller-intet bevægelse i deres sind.
Så en af de ting, jeg har taget væk fra dette mere end noget andet - jeg kommer til at slå dig med et spørgsmål om et øjeblik - er, at frygt nu, synes jeg, er lagt på mange måder, og at det før i dag, hvis jeg lytter til CIO, ville jeg, slags, tænke: ”Nå, hvordan skal jeg gøre denne overgang? Hvordan skal jeg garantere den samme kapacitet, som vi har i den relationelle databasestyringsplatform og mange års erfaring med DBA'er, til en ny platform, som vi ikke i øjeblikket har færdighederne i? ”Så mit spørgsmål med det er, tror du, folk har forstået, at værktøjerne er der nu med det, du tilbyder, og at de slags kan tage en dyb indånding og sukke af lettelse over, at overgangen ikke er så skræmmende, som den kunne have været før at dette værktøj er tilgængeligt? Tror du, folk har forstået det, eller er det stadig, slags, en ting, de bare kæmper med overgangen til in-memory compute og in-memory lagring versus old-school kombinationer af NVMe, flash og disk?
Bill Ellis: Ja, så der er utvivlsomt en masse teknologi og værktøjer, der grafisk kan vise dette, hvad der sker og gøre det meget let at finde de bedste ressourceforbrugere. Jeg mener, det hjælper med at forenkle ting, og det hjælper teknologipersonalet med at få et godt greb. Hej, de vil være i stand til at vide, hvad der foregår, og være i stand til at forstå alt kompleksiteten. Så absolut er værktøjerne på markedet absolut nyttige, så vi tilbyder analyse af arbejdsbyrde til SAP HANA.
Dez Blanchfield: Ja, jeg synes, at det gode ved det, du har vist os i dag, er, at når du overvåger hardwarestykket, operativsystemstykket, endda overvåger noget af den arbejdsmængde, der bevæger sig gennem, som du sagde, jeg mener, værktøjerne har været der i nogen tid. Den smule for mig, især inden for den slags HANA, er, at vi ikke nødvendigvis har haft evnen til at få et forstørrelsesglas og kigge ind i det og se lige ned til, hvad dit værktøj gør med, hvad der sker med forespørgslerne, og hvordan de er at være struktureret, og hvor den belastning er.
Med de implementeringer, du har set hidtil, i betragtning af at du er bogstaveligt talt den mest autoritative i dette rum på din platform i verden, nogle af de hurtige sejre, som du har set - har du fået nogen anekdotisk viden, du kan dele med os omkring nogle af eureka-øjeblikke, aha-øjeblikke, hvor folk har implementeret IDERA-værktøjssættet, de har fundet ting, som de bare ikke var klar over, var i deres platforme og forestillinger, de har haft. Har du fået nogle gode anekdotiske eksempler på, hvor folk netop har implementeret det, ved ikke rigtig at vide, hvad de har haft, og pludselig er væk, ”Wow, vi vidste faktisk ikke, at det var derinde?”
Bill Ellis: Ja, så en stor begrænsning af de oprindelige værktøjer er, at hvis en løbende forespørgsel annulleres, skyller den informationen, og så du dybest set ikke har historien. Af os, der lagrer historikken offline, ligesom en løbende forespørgsel, har du en historie, du ved, hvad der var sket, vil du kunne se udførelsesplan osv. Og det giver dig mulighed for at form for, hjælpe slutbrugerfællesskabet dybest set med at fungere bedre, skrive rapporter bedre osv. Og så historien er noget, der virkelig er rart at have. Og en af de ting, som jeg havde tænkt at vise, er, at du kan se på realtid op til fire uger, og så kan du nemt zoome ind på et hvilket som helst tidsinteresse af interesse, og så kan du afsløre den underliggende køreaktivitet. Bare det at have den synlighed er noget, der er meget nyttigt at vide, hvilken flaskehals der er opstået.
Dez Blanchfield: Du nævnte, at det er flerbrugere, når det først var installeret, og jeg var ganske imponeret over det faktum, at det er agentfrit og effektivt nulkontakt på mange måder. Er det normalt, at en enkelt implementering af dit værktøj derefter er tilgængeligt for alle fra netværksoperationscentret i NOC og ser kerneinfrastruktur, der ligger til grund for klyngen helt op til applikations- og udviklingsholdet? Er det normen, og du implementerer én gang, og de vil dele det, eller forventer du, at folk måske har modelinstanser, der kigger på forskellige dele af stakken? Hvordan ser det ud?
Bill Ellis: Så basalteamet vil typisk have en meget stærk interesse i den teknologi, der ligger til grund for, hvad der sker i SAP. Der er selvfølgelig flere hold, der understøtter hele landskaber. HANA-stykke fokuserer bare på det. Jeg vil bare gå til SAP-basisteamet som de primære forbrugere af informationen.
Dez Blanchfield: Right. Det slår mig dog, at hvis jeg har et udviklingshold eller ikke engang bare på kodeniveau, men hvis jeg har et team med datavidenskabsmænd eller analytikere, der laver analytisk arbejde på datasættene derinde, især i betragtning af at der er et betydeligt pres på datavidenskab, der bliver anvendt på alt inden for organisationer nu, i mit sind - og korriger mig, hvis jeg tager fejl, ser det ud til, at dette også vil være af stor interesse for dem, fordi man på mange måder af de alvorlige ting, du kan gøre i et datalagermiljø, er at løsne en datavidenskabsmand på det og lade det bare begynde at lave ad hoc forespørgsler. Har du haft nogen eksempler på, at den slags sker, hvor butikker har ringet dig og sagt: ”Vi har kastet et data science-team på tinget, det er virkelig ondt, hvad kan vi gøre for dem kontra hvad vi laver bare traditionel operationel overvågning og styring? ”Er det endda en ting?
Bill Ellis: Nå, ja, jeg ville slags slå dette en smule og skære mit svar ville være, at når jeg ser på ydelse, er præstationsbevidst ved at udvikle QA-produktion, ved du, jo før du gemmer, jo mindre problemer, mindre overraskelser, du har. Så absolut.
Dez Blanchfield: Herefter følger en masse af de værktøjer, som jeg har haft erfaring med - og jeg er sikker på, at Robin er enig - en masse af værktøjerne her, hvis du har et stort RDBMS, har du brug for virkelig høj- dygtige, dybt kyndige, erfarne DBA'er. Nogle af infrastruktur- og platformkravene, der følger med SAP HANA, fordi det i øjeblikket understøttes på bestemte distributioner, der er tilpasset fra bestemt hardware og så videre, så vidt jeg ved. Du ved, der er mennesker med årtiers erfaring, som ikke er ens. Det, jeg imidlertid ser, er, at det ikke nødvendigvis er kravet til dette værktøj. Det ser ud til, at du kan indsætte dit værktøj og give det til nogle ret nye ansigter og give dem strømmen med det samme til at finde ting, der ikke fungerer godt. Er det tilfældet, at der er en temmelig kort indlæringskurve for at komme op med hastigheden med dette og få noget ud af at implementere det? Du ved, min generelle forstand er, at du ikke behøver at have 20 års erfaring med at køre et værktøj for at se værdien med det samme. Er du enig i, at det er tilfældet?
Bill Ellis: Åh absolut, og til dit punkt tror jeg, at en stor del af succesen med en installation virkelig afhænger af planlægningen og arkitekten af SAP HANA-miljøet. Og så er der utvivlsomt en masse kompleksitet, en masse teknologi, det er bygget på, men så kommer det bare ned til at overvåge brugsmønstrene for, hvad der sker. Så selvom det er mere komplekst, er det på en måde pakket og noget forenklet. Det er en meget dårlig.
Dez Blanchfield: Ja, så før jeg afleverer Eric, fordi jeg ved, at han har et par spørgsmål, især fra nogle der er kommet gennem spørgsmål og spørgsmål, der så interessant ud, og jeg er interesseret i at høre svaret på. Traditionel rejse for nogen til - du nævnte tidligere, at du kan få den, du kan downloade den og prøve den. Kan du bare sammenfatte det hurtigt til folkelig lytning enten i dag eller folk, der muligvis afspiller det senere? Hvad er de hurtige to eller tre trin for at få hånden på en kopi og distribuere den og prøve den i deres miljøer, før de køber den? Hvordan ser det ud? Hvad er trinnene til det?
Bill Ellis: Ja. Så, IDERA.com og bare gå til Produkter, så ser du Workload Analyse til SAP HANA. Der er en downloadside. Jeg tror, de beder dig om nogle kontaktoplysninger, og produktet er bare pakket med en licensnøgle, så du kan installere det med Setup.exe og bare få rullet, tror jeg, meget hurtigt.
Dez Blanchfield: Så de kan gå til dit websted, de kan downloade det. Jeg kan huske, at jeg kiggede på det for et stykke tid siden, og jeg har også tjekket i går aftes. Du kan anmode om en demo fra hukommelsen, hvor nogen på dit team vil, slags, føre dig igennem det? Men du kan faktisk downloade den gratis og distribuere den lokalt i dit eget miljø, på din egen tid, kan du ikke?
Bill Ellis: Ja.
Dez Blanchfield: Fremragende. Nå, jeg tror, mere end noget andet, det er sandsynligvis den ting, som jeg personligt vil råde folk til at gøre, er at få fat i en kopi fra webstedet, få fat i noget af dokumentationen der, fordi jeg ved, at der er meget godt indhold der at gøre det med, og prøv bare det. Læg det i dit miljø, og se, hvad du finder. Jeg formoder, at når du først har kigget under hætten med dine SAP HANA-miljøer med IDERA-værktøjet, vil du finde ting, som du faktisk ikke var klar over, der var derinde.
Se, tak så meget for det, og tak for tiden bare for spørgsmål og svar med Robin og I. Eric, jeg vil vende tilbage til dig, fordi jeg ved, at nogle spørgsmål og svar er kommet igennem fra vores deltagere.
Eric Kavanagh: Ja, bare en rigtig hurtig her. Så en af de deltagende kommenterer en rigtig god kommentar her bare ved at tale om, hvordan tingene ændrer sig. Når man siger i fortiden, blev kvælningen kvalt, hvilket bremsedes ned ved hyppige personsøgninger, i øjeblikket kvæles CPU med for meget hukommelsesdata. Du ved, der er netværksproblemer. Det vil altid være et bevægende mål, ikke? Hvad ser du som en bane i disse dage med hensyn til, hvor flaskehalse skal hen, og hvor du vil være nødt til at fokusere din opmærksomhed?
Bill Ellis: Ja. Indtil du måler, er det svært at vide det. En af tingene ved SQL-udsagnene er, at de vil være driverne til ressourceforbrug. Og så i de omstændigheder, som du skulle have, som et stort hukommelsesforbrug eller CPU-forbrug, vil du være i stand til at finde ud af, hvilken aktivitet der har forårsaget dette ressourceforbrug. Nu ønsker du ikke nødvendigvis at dræbe det, men du vil også være opmærksom på det og slags hvad der sker, hvor ofte sker det osv. Vi er, slags, stadig nye med hensyn til at adressere hele sættet eller kogebogen med svar på forskellige omstændigheder. Og så er det et godt spørgsmål, og tiden vil vise sig. Vi får flere oplysninger, når tiden går.
Eric Kavanagh: Det er det. Nå, I er i et meget interessant rum. Jeg tror, du vil se en masse aktivitet i de kommende måneder og de næste par år, fordi jeg ved, at SAP, som du antydede i vores indholdsopkald, har givet en dejlig lang on-ramp for folk at gøre overgangen til HANA. Men ikke desto mindre har denne rampe en ende, og på et bestemt tidspunkt bliver folk nødt til at tage nogle seriøse beslutninger, så jo før jo bedre, ikke?
Bill Ellis: Absolut.
Eric Kavanagh: Okay folkens, vi har brændt endnu en times tid her på Hot Technologies. Du kan finde information online, insideanalysis.com, også techopedia.com. Fokuser på dette websted for masser af spændende oplysninger, inklusive en liste over alle vores arkiver over disse tidligere webcasts. Men folk, en stor tak til alle jer derude, til vores venner på IDERA, til Robin og selvfølgelig, Dez. Og vi henter dig næste uge, folkens. Tak igen for din tid og opmærksomhed. Pas på. Hej hej.
