Av Techopedia Staff, 25. januar 2017
Takeaway: Vert Eric Kavanagh diskuterer databehandling i minnet og SAP HANA med gjestene Dr. Robin Bloor, Dez Blanchfield og IDERAs Bill Ellis.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, mine damer og herrer. Hei og velkommen igjen. Det er klokka fire østlige tid på en onsdag og de siste par årene, noe som betyr at det er på tide atter en gang for Hot Technologies. Ja, ja, jeg heter Eric Kavanagh, jeg vil være din vert for dagens samtale.
Og folkens, vi skal snakke om noen kule ting i dag. Vi kommer til å dykke ned i minne-verdenen. Den nøyaktige tittelen er "Into the Future: A On-Ramp for In-Memory Computing." Det er veldig raseri i disse dager, og med god grunn, mest fordi in- minnet er så mye raskere enn å stole på spinnende disker. Utfordringen er imidlertid at du må omskrive mye programvare. Fordi programvaren i dag, det meste av den, er skrevet med tanke på disken, og som virkelig endrer arkitekturen til applikasjonen. Hvis du designer applikasjonen slik at den venter på en spinnende disk, gjør du bare ting annerledes enn hvis du har all den kraften i minneteknologien.
Det er et sted om ditt virkelig, slo meg på Twitter, @eric_kavanagh. Jeg prøver alltid å følge tilbake og også å retweet når som helst noen nevner meg.
Som jeg sa, vi snakker om minne i dag, og spesifikt om SAP HANA. Dine brukte virkelig det siste året på å bli kjent med SAP-samfunnet veldig bra, og det er et fascinerende miljø, må jeg si. Hatter av til folkene som kjører den operasjonen og er i frontlinjene, for SAP er en utrolig bra operasjon. Det de virkelig er veldig gode på er å drive forretning. De er også gode på teknologi, og de har virkelig lagt en tung investering i HANA. Jeg kan faktisk huske - det var sannsynligvis for rundt seks eller syv år siden - at vi gjorde noe arbeid for det amerikanske flyvåpenet, og at vi fikk noen fra SAP til å komme inn og gi oss et tidlig blikk på verden av HANA og hva som var planlagt. Og mildt sagt, folkene på SAP Labs hadde lagt ned mye tid og krefter på å forstå hvordan man bygger ut denne arkitekturen som igjen er helt annerledes enn tradisjonelle miljøer, fordi du har alt i minnet. Så de snakker om å gjøre både transaksjonelle og analytiske på samme data i minnet, i motsetning til den tradisjonelle måten, som er å trekke den ut, legge den inn i en terning, for eksempel analysere den der, kontra transaksjonell, som skjer på en veldig annen måte.
Dette er en interessant plass, og vi kommer til å finne ut av en annen leverandør, IDERA, litt om hvordan alle de tingene skal fungere, og hva rampen handler om, ærlig talt. Så vi får høre fra Dr. Robin Bloor, vår helt egen sjefanalytiker her i The Bloor Group; Dez Blanchfield, vår dataforsker og deretter gode venn Bill Ellis fra IDERA. Så med det skal jeg dele ut nøklene til Dr. Robin Bloor, som vil ta det bort.
Dr. Robin Bloor: Ja, som Eric sa, tiden som vi først ble orientert av SAP HANA var tilbake for mange år siden, nå. Men det var veldig interessant, den bestemte tiden var veldig interessant. Vi ville støte på et eller to selskaper som på en eller annen måte tilbyr teknologi i minnet. Det var helt tydelig at minnet kom til å komme. Og det var egentlig ikke før SAP reiste seg og plutselig lanserte HANA. Jeg mener, det var sjokk da jeg så SAP gjøre det. Det var som et sjokk fordi jeg forventet at det skulle komme fra andre steder. Jeg regnet med at det ville være, du vet, Microsoft eller Oracle eller IBM eller noen som det. Ideen om at SAP gjorde det var virkelig veldig overraskende for meg. Jeg antar at det ikke burde ha vært fordi SAP er en av de strategiske leverandørene og ganske mye, vet du, alt det store som skjer i bransjen kommer fra en av disse.
Uansett, hele poenget med minnet, mener jeg, vi innså at vi pleide å snakke om det, at så snart du faktisk går i minnet - dette handler ikke om å sette data i minnet, dette handler om å forplikte seg til Tenk på at minnelaget er systemoppføringen - så snart du migrerer systemoppføringen til minnet, begynner disken å bli et overleveringsmedium av en slags og det blir en annen ting. Og det syntes jeg var veldig spennende da det begynte å skje. Så, egentlig er det slutt for spinningsdisk. Spinningsdisk vil snart være eksisterende bare i museer. Jeg er ikke sikker på hvor snart det snart er, men i utgangspunktet er solid-state-disken nå på Moore's lovkurve, den er allerede ti ganger raskere enn å spinne rust, som de nå kaller den, og ganske snart vil den være raskere fremdeles og da betyr det at bruk av saker for disk bare blir færre og færre.
Og det merkelige faktum, tradisjonell DBMS, faktisk, ble det bygget mye tradisjonell programvare for spinningsdisk, antok den å spinne disk. Den hadde alle mulige fysiske nivåer som var nøye programmert i, for å utnytte spinningsdisken, slik at datainnhenting så raskt som mulig. Og alt dette blir vasket bort. Bare forsvinner, vet du? Og så var det tydeligvis en veldig - jeg vet ikke, lukrativ, antar jeg, det vil være til slutt - åpning for en database i minnet som prøvde å innta den posisjonen som de store databasene, Oracle og Microsoft, SQL Server og IBMs DB2, de okkuperte i minnet og det var veldig interessant å se som kom marsjerende frem og gjør det.
La oss snakke om minnekaskaden; det er bare verdt å nevne. Det er også, grunnen til å nevne dette, grunnen til at jeg kastet dette inn, var egentlig bare for å gi beskjed til alle, når jeg snakker om minne her, er alle disse lagene jeg snakker om faktisk minne. Men du skjønner plutselig når du ser på dette, dette er en hierarkisk butikk, det er ikke bare minne. Og derfor gjelder stort sett alt vi lærte for en lang, lang tid siden om hierarkisk butikk. Og det betyr også at enhver database i minnet må navigere seg gjennom dette, noen bare går gjennom den på RAM selv, vet du. Og det har bare blitt større og større og større, og det er nå målt i megabyte. Men du har L1-hurtigbuffer som er hundre ganger raskere enn minne, L2-hurtigbuffer 30 ganger raskere enn minne og L3-hurtigbuffer omtrent ti ganger raskere enn minne. Så, du vet, det er mye teknologi - vel, en god del teknologi - har tatt i bruk strategien om å bruke disse hurtigbufrene som, slags lagringsplass på vei til å få ting utført, spesielt databaseteknologi. Så, du vet, det er en innflytelse.
Så har vi fått fremveksten av 3D XPoint og IBMs PCM. Og det er nesten RAM-hastigheter, er egentlig hva begge disse leverandørene skryter. Brukssakene er sannsynligvis forskjellige. Den tidlige eksperimenteringen med dette er ennå ikke fullført. Vi vet ikke hvordan det vil påvirke bruken av RAM og teknologien i databasen i minnet for den saks skyld. Du har da fått RAM versus SSD. For øyeblikket er RAM omtrent 300 ganger raskere, men den multippelen minker selvfølgelig. Og SSD kontra disk som er omtrent 10 ganger raskere, hvis jeg forstår det. Så det er den typen situasjon du har hatt. Det er hierarkisk butikk. Å se på det en annen måte, i minnet er selvfølgelig helt annerledes. Så viser toppdiagrammet to applikasjoner, begge har kanskje tilgang til en database, men absolutt tilgang til data om roterende rust. Og måten du faktisk får ting til å flyte gjennom nettverket, avhengig av hvilke avhengigheter det er, er at du har ETL. Så dette betyr at data, du vet, går over på roterende rust, og deretter slipper ut rot for å gå hvor som helst, og for å komme hvor som helst, går de tilbake til roterende rust, som er tre bevegelser. Og husk at minnet kan være hundre tusen ganger raskere enn spinningsdisk, og du skjønner absolutt at det å ta data og legge dem i minnet gjør at hele saken virkelig blir ganske annerledes.
Så, kanskje du trodde hva som ville skje på det som er på skjermen her, kan du ha trodd at ETL på en eller annen måte faktisk bare ville gå fra data til data i minnet. Men faktisk gjør det kanskje ikke det; faktisk kan det hende du har situasjonen til høyre her hvor to applikasjoner faktisk kan skyte av det samme minnet. Gjerne en database i minnet kan gi deg den muligheten, så lenge du har låst og alt annet orkestrert rundt det. Så dette endrer ikke bare hastigheten på ting, dette endrer hvordan du faktisk konfigurerer applikasjoner og hele datastrømmer.
Så det er en enorm slags påvirkning. Så i minnet er forstyrrende, ikke sant? Og det skulle vi få fra det jeg sa. Behandlingen i minnet er for øyeblikket en akselerator, men den kommer til å bli normen. Det vil bli brukt, brukt etter applikasjonsverdi, og det er derfor veldig, veldig interessant, at SAP faktisk kommer ut med en versjon av ERP-programvaren som er i minnet. Og latensforbedringer opp til tre størrelsesordrer fullt mulig, og faktisk enda mer enn det er mulig, avhengig av hvordan du gjør det. Så du får enorme forbedringer i hastigheten ved å gå inn i minnet. Og resultatet, SAP HANAs S / 4 - som de har gitt ut, tror jeg, vel, folk sier at det fremdeles blir utgitt, men det ble absolutt utgitt i fjor - det er en spillbytter gitt SAPs kundegrunnlag. Jeg mener, det er 10.000 selskaper der som bruker SAPs ERP, og stort sett alle er store selskaper, vet du. Så ideen om at de alle har et insentiv til å gå inn i minnet og bruke det grunnleggende, fordi ERP nesten alltid er grunnleggende applikasjoner som virksomhetene kjører, det er bare en enorm spillutveksler og det vil være veldig interessant. Men selvfølgelig høres alt veldig bra ut, men det må konfigureres intelligent og det må overvåkes godt. Det er ikke så enkelt som det høres ut.
Når det er sagt, tror jeg at jeg vil gi ballen videre, hvem er denne fyren? Åh, australsk fyr, Dez Blanchfield.
Dez Blanchfield: Veldig morsomt. Alltid en tøff handling å følge, Dr. Robin Bloor. Takk for at du har meg i dag. Så, stort tema, men spennende. Så jeg har valgt et bilde som jeg ofte tryller frem når jeg tenker på det moderne datasjøet og enterprise datavarehus, og mine små perler med data. Så her har jeg fått denne vakre innsjøen omgitt av fjell og bølger som kommer ut, og bølgene krasjer over disse steinene. Dette er slags hvordan jeg mentalt visualiserer hvordan det ser ut i et stort datasjø i disse dager. Bølgene som er batchjobber, og sanntidsanalyser som kastes på data, er steinene. Og når jeg tenker på det som en fysisk innsjø, bringer det på en måte en oppvåkning til meg om at, du vet, omfanget av datavarehusene vi bygger nå, grunnen til at vi kom frem til denne mynten og begrepet en datasjø er at de er veldig store og de er veldig dypt, og av og til kan du ha stormer i dem. Og når vi gjør det, må du alltid løse det som skaper stormen.
Så i temaet for denne tingen ser det ut til at dette sirene-anropet til dataminnet er veldig sterkt og med god grunn. Det gir så mange betydelige kommersielle og tekniske gevinster. Det er en diskusjon i et par timer på en annen dag. Men det generelle skiftet til dataminnet, for det første vil jeg bare dekke hvordan vi har kommet hit og hva som gjør dette mulig fordi det, liksom, legger grunnlaget for hvor noen av utfordringene kan ligge først og hva vi trenger å være klar over av og tenker på, i vår verden med å bevege oss bort fra tradisjonell gammel spinnende disk som inneholder data og blir paging av og på disken og inn i minnet og ut av minnet og inn i CPUer, til nå fjerner vi bare ett av de hele lagene, å være den spinnende disken. For husk at i de første dagene av databehandling, arkitektonisk, beveget vi oss ikke lenge fra hovedrammen eller mellomtoneverdenen til det vi opprinnelig tenkte på som kjerneminne og trommelager, vet du.
Som Dr. Robin Bloor sa, endret tilnærmingen vi tok til å flytte data rundt dataarkitektur ikke dramatisk på noen tid, i et par tiår. Hvis du tenker på det faktum at moderne databehandling teknisk har eksistert, hvis du vil benåde ordspillet, i noen 60 år, vet du det, seks tiår og mer, og det er i den forstand at du kan kjøpe en boks fra sokkelen, som den var. Overgangen til ny arkitektur skjedde virkelig i tankene mine da vi skiftet ut fra tankegangen rundt hovedrammer og mellomtone, og kjerneminne- og trommelagringsarkitekturer, til de modige eller supercomputing, spesielt slike som Seymour Cray, der ting som tverrliggende bakplaner ble en ting. I stedet for bare å ha en rute for å flytte data over bakplanet eller hovedkortet, som det heter i disse dager. Og det indre minnet, vet du, i disse dager tenker ikke folk på hva det faktisk betyr når de sier DIMM og SIMM. Men SIMM er et enkelt inline-minne, og DIMM er dobbelt inline-minne, og vi har mer komplisert siden det, og det er mange forskjellige minnetyper for forskjellige ting: noen for video, noen for bare generelle applikasjoner, noen innebygde CPUer.
Så det var dette store skiftet til en ny måte at data ble lagret og tilgang til. Vi er i ferd med å gå gjennom det samme skiftet i en annen hel generasjon, men ikke så mye i selve maskinvaren, men ved bruk av maskinvaren i forretningslogikken og i datalogiksjiktet, og det er nok et stort paradigmeskifte i mitt sinn .
Men bare kort om hvordan vi kom hit. Jeg mener, maskinvareteknologi ble forbedret og forbedret dramatisk. Vi gikk fra å ha CPU-er, og ideen om en kjerne var et ganske moderne konsept. Vi tar det for gitt nå som telefonene våre har to eller fire kjerner og datamaskinene våre har to eller fire, eller til og med åtte, kjerner på skrivebordet og åtte og 12 og mer på, du vet, 16 og 32 til og med på serverplattformen . Men det er faktisk en ganske moderne ting at kjerner ble en kapasitet i CPU-er, og at vi gikk fra 32-bit til 64-bit. Et par store ting skjedde der: vi fikk høyere klokkehastighet på flere kjerner slik at vi kunne gjøre ting parallelt og hver av disse kjernene kunne kjøre flere tråder. Plutselig kunne vi kjøre mange ting på de samme dataene samtidig. Sekstifire-bits adresseavstand ga oss opp til to terabyte RAM, som er et fenomenalt konsept, men det er en ting nå. Disse flerveisens bakplanplanarkitekturene, du vet, hovedkort, en gang i blant, kunne du bare gjøre ting i en retning: bakover og fremover. Og som med dagene med Cray-databehandlingen og noen av datidens superdatamodeller, og nå i stasjonære datamaskiner og vanlige hylle, slags stasjonære PC-er for montering på stasjonære datamaskiner, for egentlig er det meste av det moderne PC-er har nå gått gjennom denne epoken med mainframe, midrange, micro desktops, og vi har gjort dem tilbake til servere.
Og mye av den superdatamuligheten, den superkomputer-designen, ble presset inn i vanlige komponentkomponenter. I dag vet du ideen om å ta veldig billige rackmonterte PC-er og legge dem i stativer av hundrevis, om ikke tusenvis, og kjøre open source-programvare på dem som Linux og distribuere slike som SAP HANA på det, du vet, vi tar det ofte for gitt. Men det er en veldig ny spennende ting, og den kommer med dens kompleksiteter.
Programvare ble også bedre, spesielt minnehåndtering og datapartisjonering. Jeg vil ikke gå inn på mange detaljer om det, men hvis du ser på det store skiftet de siste 15 årene, eller enda mindre, hvordan hukommelse styres, spesielt data i RAM og hvordan data blir delt inn i RAM, slik som Dr. Robin Bloor antydet tidligere eller henvist til, du vet, ting kan lese og skrive på samme tid uten å påvirke hverandre, i stedet for å ha ventetider. Mange veldig kraftige funksjoner som komprimering og kryptering på chip. Kryptering blir en viktigere ting, og vi trenger ikke nødvendigvis gjøre det i programvare, i RAM, på CPU-plass, nå som faktisk skjer på brikken. Det fremskynder ting dramatisk. Og distribuert datalagring og -behandling, igjen, ting som vi en gang antok var ting av superdatamaskiner og parallell behandling, vi tar det nå som en selvfølge i likhet med SAP HANA og Hadoop og Spark, og så videre.
Så hele poenget med dette er denne høyytelsesdataarkningen, HPC-evner kom til bedriften, og nå nyter bedriften fordelene som følger med ytelsesgevinster og teknologiområder og tekniske fordeler og kommersielle gevinster, fordi du vet, den reduserte verdien til verdi blir dramatisk droppet.
Men jeg bruker dette bildet av en historie jeg leste for en tid tilbake av en herre som bygde en PC-sak ut av Lego, fordi det alltid kommer til tankene når jeg tenker på noen av disse tingene. Og det er det, det virker som en god ide den gangen når du begynner å bygge den, og så kommer du halvveis gjennom den og du skjønner at det faktisk er veldig vanskelig å sette sammen alle Lego-bitene og lage en solid ting, solid nok å legge et hovedkort og så videre, det vil bygge en sak for en personlig datamaskin. Og etterhvert skjønner du at alle de små bitene ikke klistrer seg sammen og at du må være litt forsiktig med hvilke små biter du holder sammen for å gjøre dem solide. Og det er en veldig søt idé, men det er en vekker når du kommer halvveis igjennom og skjønner: "Hmm, kanskje jeg bare burde ha kjøpt en $ 300 PC-sak, men jeg skal fullføre den nå og lære noe av det."
For meg er det en god analogi for hvordan det er å bygge disse veldig komplekse plattformene, fordi det er bra og greit å bygge det og ende opp med et miljø der du har rutere og brytere og servere og stativer. Og du har CPUer og RAM og operativsystem gruppert sammen. Og du legger noe som HANA på toppen av det for distribuert prosessering i minnet og datalagring og datahåndtering. Du bygger SAP-stabelen på toppen av det, du får databasefunksjonene og deretter laster du inn dataene og forretningslogikken din, og du begynner å bruke noen leser og skriver og spørsmål osv. På den. Du må holde deg oppdatert på I / O, og du må planlegge ting og administrere arbeidsmengder og multitenancy og så videre. Denne stabelen blir veldig kompleks, veldig raskt. Det er en kompleks stabel i seg selv hvis den bare er på en maskin. Multipliser det med 16 eller 32 maskiner, det blir veldig, veldig lite trivielt. Når du multipliserer opp til hundrevis og etter hvert tusenvis av maskiner, for å gå fra 100 terabyte til petabyte skala, er det et skremmende konsept, og dette er realitetene vi har å gjøre med nå.
Så, så ender du opp med et par ting som også har bidratt til å forandre denne verdenen, og det er at diskplass ble latterlig billig. Du vet, en gang i tiden ville du bruke 380 til 400 tusen dollar på en gigabyte harddisk når det var en massiv tromme på størrelse med - noe som trengte en gaffeltruck for å hente den. I disse dager er det nede på, slags en eller to øre per gigabyte med diskplass. Og RAM gjorde det samme. Disse to J-kurvene i begge disse grafene er forresten et tiår hver, så med andre ord, vi ser på to blokker på 10 år, 20 år med prisreduksjon. Men jeg brøt dem i to J-kurver fordi den til slutt bare ble en stiplet linje og du ikke kunne se detaljene i, så jeg skalerte den på nytt. En GB RAM for 20 år siden var noe i størrelsesorden seks og en halv million dollar. I disse dager hvis du betaler mer enn tre eller fire dollar for en gigabyte RAM for råvaremaskinvare blir du frarøvet.
Disse betydelige tumbling av prisreduksjon de siste to tiårene har gjort at vi nå kan gå utover diskplass og rett inn i RAM, ikke bare på megabytenivået, men nå terabytenivået og behandle RAM som det er disk. Utfordringen med det var imidlertid at RAM var naturlig flyktig - det betyr noe som varer i en kort periode - så vi har måttet finne ut måter å gi spenst til det rommet.
Og så, poenget mitt her er at databehandling i minnet ikke er for svake hjerter. Det å sjonglere med disse veldig store skalaene i minnet og behandlingen rundt det er en interessant utfordring; som jeg antydet tidligere, er det ikke for svake hjerter. Så en ting vi har lært av denne erfaringen med storskala og høy tetthet i minnet er at kompleksiteten vi bygger oppretter risiko på en rekke områder.
Men la oss bare se på det fra et overvåkings- og responssynspunkt. Når vi tenker på dataene, begynner de på diskplass, de sitter i databaser på disker, vi skyver dem opp i minnet. Når det først er i minnet og distribuert og det er kopier av det, kan vi bruke mange eksemplarer av det, og hvis noen endringer blir gjort, kan det gjenspeiles over på minnenivå i stedet for å måtte gå av og på og over bakplanet på to forskjellige nivåer, går den inn og ut av minnet. Vi har endt opp med denne hyperscale maskinvareplattformen som lar oss gjøre dette nå. Når vi snakker om hyperskaling, er det vanskeligere på latterlig tette nivåer, og svært høy tetthet, mange tettheter av CPUer og kjerner og tråder. Vi har nå veldig komplekse nettverkspatologier som støtter dette fordi dataene på et tidspunkt må bevege seg over nettverket hvis det kommer til å gå mellom noder og klynger.
Så vi ender opp med at overflødiggjøring av enhetsfeil blir et problem, og vi må overvåke enheter og deler av den. Vi må ha spenstig datafeilredundanse innebygd i den plattformen og overvåke den. Vi må ha den distribuerte databasens motstandskraft innebygd, så vi må overvåke databaseplattformen og stable i den. Vi må overvåke den distribuerte prosessplanleggingen, hva som skjer i noen av prosessene helt ned til polling og spørring og banen som spørringen tar, og måten spørringen blir strukturert og utført på. Hvordan ser det ut, har noen gjort en SELECT * på “bla”, eller har de faktisk gjort et veldig smart og godt strukturert spørsmål som kommer til å gi dem den nominelle, minste datamengden som kommer over arkitekturen i bakplanen? Vi har flere arbeidsmengder, flere brukere og flere grupper som har samme eller flere arbeidsmengder og batchjobber og sanntidsplanlegging. Og vi har fått denne blandingen av batch og sanntidsbehandling. Noen ting kjøres bare regelmessig - hver time, daglig, ukentlig eller månedlig - andre ting er på forespørsel. Det kan hende at noen sitter der med et nettbrett og ønsker å rapportere i sanntid.
Og igjen kommer vi til hele poenget, at kompleksiteten som oppstår i disse ikke bare er en utfordring nå, det er ganske skremmende. Og vi har denne virkelighetssjekken at et enkelt ytelsesproblem, bare ett ytelsesproblem i seg selv, kan påvirke hele økosystemet. Og så ender vi opp med denne veldig morsomme utfordringen med å finne ut, vel, hvor er virkningene? Og vi har denne utfordringen, er vi reaktive eller proaktive? Ser vi på tingen i sanntid og ser at noe blir “smell” og svarer på det? Eller har vi sett en form for trend og innsett at vi må proaktivt komme om bord med det? Fordi nøkkelen er at alle vil ha noe raskt og billig og enkelt. Men vi ender opp med disse scenariene, hva jeg liker å henvise til og favorittlinjen min til Donald Rumsfeld conundrum - som i mitt sinn gjelder i alle disse scenariene med høy kompleksitet - og det er det, vi har kjent kjent fordi det er noe vi designet og bygget, og det kjører som planlagt. Vi har kjent ukjente ved at vi ikke vet hvem som kjører hva, når og hvor, hvis det er på forespørsel. Og vi har ukjente ukjente, og det er tingene vi trenger å overvåke og se etter. Fordi realiteten er, vet vi alle, at du ikke klarer noe du ikke kan måle.
Så for å ha de riktige verktøyene og den rette evnen til å overvåke CPU-planleggingen din, se etter ventetider, finn ut hvorfor ting må vente i planlagte køer i rørledninger. Hva skjer i minnet, hva slags utnyttelse blir utført, hva slags ytelse får vi ut av minnet? Deles ting riktig, blir det distribuert, har vi nok noder som har kopier av det til å takle arbeidsmengden som blir kastet på det? Hva skjer med prosessutførelse bort fra operativsystemprosessene? Jobbene selv kjører, de enkelte appene og demonene som støtter dem? Hva skjer i prosessene, spesielt struktureringen av spørsmål og hvordan blir disse spørsmålene utført og samlet? Og helsen til de prosessene helt ut i bunken? Du vet, igjen, tilbake til ventetider, er det planlagt riktig, er det å måtte vente, hvor er det venter, er det venter på minne leser, I / Os, CPU, I / O over nettverket til sluttbruker ?
Og tilbake til det punktet jeg nettopp har nevnt like raskt før jeg pakker opp, og det er det, hvordan nærmer vi oss problemløsningen og responstiden til disse? Ser vi på i sanntid og reagerer på ting, som er det minst ideelle scenariet, men selv da, det er bedre at vi gjør det enn ikke å vite, og la kundeservicen ringe og si at noe gikk galt, og vi må finne det opp ? Eller gjør vi det proaktivt og ser vi på hva som kommer nedover linjen? Så, med andre ord, ser vi at vi har mangel på minne og trenger å legge til flere noder? Gjør vi trendanalyse, gjør vi kapasitetsplanlegging? Og i alt dette, overvåker vi historiske utførelsestider og tenker på kapasitetsplanlegging, eller ser vi på det i sanntid og proaktivt omplanlegger og gjør belastningsbalansering? Og er vi klar over arbeidsmengden som kjører i utgangspunktet? Vet vi hvem som gjør hva i klyngen vår, og hvorfor?
Datamaskiner i minnet er veldig kraftige, men med den kraften er det nesten en av de tingene, for eksempel en lastet pistol og du leker med live ammo. Du kan til slutt skyte deg selv i foten hvis du ikke er forsiktig. Så den kraften i minnet beregner betyr bare at vi kan kjøre mye mer og raskt over veldig distribuerte og diskrete datasett. Men så har det en større etterspørsel som blir drevet fra sluttbrukere. De blir vant til den kraften, og de vil ha den. De forventer ikke lenger at det tar flere uker å jobbe og rapporter dukker opp i vanlig papir. Og så, under alt dette, har vi det daglige vedlikeholdet omkranset av oppdatering, oppdateringer og oppgraderinger. Og hvis du tenker på 24/7 behandling med in-memory computing, administrere disse dataene, administrere arbeidsmengdene over det, er alt i minnet, teknisk sett i en flyktig plattform, hvis vi skal begynne å bruke patcher og oppdateringer og oppgraderinger i der, det kommer med en rekke andre utfordringer for styring og overvåking også. Vi må vite hva vi kan ta frakoblet, når vi kan oppgradere det og når vi tar det tilbake på nettet. Og det bringer meg til mitt endelige poeng, og det vil si at når vi får mer og mer kompleksitet i disse systemene, er det ikke noe som et menneske kan gjøre bare ved å suge tommelen og trekke øret lenger. Det er ingen, slags magefølelse nærmer seg lenger. Vi trenger virkelig de nødvendige verktøyene for å administrere og levere dette høye ytelsesnivået innen databehandling og datahåndtering.
Og med det i tankene skal jeg overlate til vennen vår fra IDERA og høre hvordan de har taklet denne utfordringen.
Bill Ellis: tusen takk. Jeg deler ut skjermen min og her går vi. Så det er virkelig ydmykende å bare vurdere all teknologien, og alle menneskene som kom foran oss, for å gjøre disse tingene som er tilgjengelig i 2017, tilgjengelig. Vi skal snakke om arbeidsmengde-analyse for SAP HANA - i utgangspunktet en databaseovervåkningsløsning: omfattende, agentløs, gir sanntid og den bygger ut en historie, og slik at du kan se hva som har skjedd i fortiden. SAP S / 4 HANA tilbyr potensialet til bedre, raskere og billigere. Jeg sier ikke at det er billig, jeg sier bare at det er rimeligere. Tradisjonelt det som skjedde var at du ville ha en hovedproduksjonsinstans - sannsynligvis kjørt på Oracle i en større butikk, potensielt SQL Server - og så ville du bruke den ETL-prosessen, og du vil ha flere, slags versjoner av sannheten . Og dette er veldig dyrt fordi du betalte for maskinvare, operativsystem, Oracle-lisens for hvert av disse individuelle miljøene. Og på toppen av det må du ha folk til å forene en versjon av sannheten med den neste versjonen av sannheten. Og så, denne flerversjons ETL-behandlingen var bare treg og veldig, veldig tungvint.
Og slik kan HANA, i utgangspunktet en HANA-forekomst, potensielt erstatte alle disse andre tilfellene. Så det er rimeligere fordi det er en maskinvareplattform, ett operativsystem, i stedet for multipler. Og så S / 4 HANA, virkelig, det endrer alt, og du ser i utgangspunktet på utviklingen av SAP fra R / 2 til R / 3, de forskjellige forbedringspakkene. Nå er arvesystemet tilgjengelig frem til 2025, så du har åtte år til du virkelig blir tvunget til å migrere. Selv om vi ser mennesker, du vet, dypper tærne i dette fordi de vet at det kommer, og til slutt, du vet, vil ECC løpe på HANA, og du vil virkelig være forberedt på det og forstå teknologien.
Så en database, ingen ETL-prosesser, ingen kopier som må avstemmes. Så nok en gang, raskere, bedre og billigere. HANA er i minnet. SAP leverer programvaren, du leverer maskinvaren. Det er ingen samlede tabeller. Noe av det de antyder når du tenker på dette er at du ikke vil komme inn på dette, vi skal bare kjøpe den aller største serveren som er tilgjengelig. De foreslår at du, slags, riktig størrelse på SAP-landskapet på forhånd, og at de i utgangspunktet sier, ikke migrerer 20 år med data. Jeg tror arkivering er noe som er underutnyttet i IT, slags, over hele linjen, ikke bare i SAP-butikker. Og det neste er at SAP faktisk har brukt mye tid på å skrive om deres egen kode for å ikke bruke SELECT *. SELECT * returnerer alle kolonnene fra tabellen, og de er spesielt dyre i en kolonnedatabase. Og så, det er ikke en god idé for SAP HANA. Så for butikker som har mye tilpasning, mange rapporter, er dette noe du kommer til å ønske å se etter, og du vil ønske å spesifisere kolonnenavn når du fortsetter med å migrere alt til HANA.
Vi liker å si at HANA ikke er et universalmiddel. Som alle databaser, alle teknologier, må den overvåkes, og som nevnt tidligere, trenger du tall for å håndtere overskudd, måling etter måling. Og en av tingene jeg snakker om i IDERA-området, er at hver forretningstransaksjon samhandler med journalsystemet, og i dette tilfellet blir det HANA. Og slik blir HANA grunnlaget for utførelsen av dine SAP-transaksjoner, sluttbrukeropplevelsen. Og det er derfor viktig at den fortsetter å være i topphastighet. Det blir et enkelt poeng av feil, og når vi snakker med folk, er dette noe som kan dukke opp der du har en sluttbruker, og kanskje bruker sanntidsdataene, og de har et ad hoc-spørsmål som potensielt ikke er helt Ikke sant. Kanskje de ikke blir med på bordene, og de har laget en ytre sammenføyning, et partisanprodukt, og de bruker i grunnen mye ressurser. Nå vil HANA gjenkjenne det til slutt og drepe den økten. Så det er den avgjørende delen av vår arkitektur som gjør at du faktisk kan fange opp det i historien, slik at du kan se hva som hadde skjedd i fortiden og kjenne igjen disse situasjonene.
Så la oss ta en titt på arbeidsbelastningsanalysen for SAP HANA. Dette er versjon 1 så vi inviterer deg veldig til å bli med oss på reisen, og dette er et produkt fra IDERA. Det er omfattende, men likevel enkelt. Sanntid med trending. Vert helse, for eksempel helse. Vi sporer ventetilstandene, SQL-spørringene, minnekonsumenter og tjenester. Så, slik ser GUI ut, og du kan se rett utenfor flaggermusen at det er nettaktivert. Jeg åpnet faktisk opp denne løsningen som kjører live på systemet mitt. Det er noen avgjørende ting du vil se på. Vi har, slags, delt inn i forskjellige arbeidsområder. Det mest avgjørende er hva som skjer på vertsnivå fra en CPU-bruk og minneutnyttelse. Du vil definitivt ikke komme til et byttende eller spenstige standpunkt. Og så jobber du i utgangspunktet deg ned i hva som skjer i trending, fra responstid, brukere, SQL-setninger, det vil si hva som driver aktiviteten i systemet.
En av tingene med IDERA er at du vet at ingenting skjer i en database før det er aktivitet. Og den aktiviteten er SQL-setninger som kommer fra applikasjonen. Så å måle SQL-setningene er helt avgjørende for å kunne oppdage årsak. Så la oss gå videre og bore i. Så på vertsnivå kan vi faktisk se på minne, spore over tid, bruke CPU-bruken. Gå tilbake, kan du se på COBSQL-setningene. Noe av det du vil se på vår arkitekturside er at denne informasjonen er lagret utenfor HANA, så hvis noe skulle skje med HANA, fanger vi i utgangspunktet informasjon opp til, Gud forby, en situasjon med utilgjengelighet . Vi kan også fange opp alt som skjer på systemet slik at du har tydelig synlighet. Og en av tingene vi skal gjøre er at vi kommer til å presentere SQL-setningene i vektet rekkefølge. Så det vil ta hensyn til antall henrettelser, og dette er det samlede ressursforbruket.
Og slik at du kan komme inn på individuelle beregninger her - når kjørte den SQL-setningen? Og da er ressursforbruket i stor grad drevet av utførelsesplanen, og vi kan derfor fange opp det fortløpende. HANA er i minnet. Det er veldig parallelt. Det har primære indekser på hvert bord, som noen butikker velger å bygge en sekundærindeks for å løse visse ytelsesproblemer. Og slik kan det være veldig verdifullt å vite hva som skjedde med utførelsesplanen for visse SQL-setninger. Vi vil også se på tjenestene, minneforbruket igjen, kartlagt over tid. Arkitekturen: ja, dette er en selvstendig løsning som du kan laste ned fra hjemmesiden vår, og arkitekturen er at den er nettaktivert.
Du kan ha flere brukere til å koble seg til en bestemt instans. Du kan overvåke lokale forekomster av SAP HANA. Og vi holder en rullerende fire ukers historie i depotet vårt, og det er selvstyrt. For å distribuere dette er det ganske enkelt. Du trenger en Windows Server. Du må laste ned den. De fleste Windows-servere vil ha et innebygd NET-rammeverk, og det leveres med en lisens. Og så vil du gå til installasjonsveiviseren som er drevet av Setup.exe, og den ville faktisk åpne en skjerm, lisensavtale, og du vil ganske enkelt arbeide ned denne konturen ved å klikke "Neste." Og så, hvor vil du at HANA skal bli installert? Neste er databaseegenskaper, og dette kommer til å være din forbindelse til SAP HANA, så dette er agentløs overvåking av HANA-forekomsten. Og så gir vi i utgangspunktet forhåndsvisning, dette er porten vi kommuniserer på som standard. Klikk "Installer" og det starter i utgangspunktet opp HANA og du begynner å bygge historikken. Så bare litt av størrelsesdiagrammet. Vi kan overvåke opptil 45 HANA-forekomster, og du vil bruke denne typen på en glidende skala for å bestemme antall kjerner, minne, diskplass du trenger. Og dette forutsetter at du har en komplett fire ukers rullende historie som går inn.
Så akkurat som en rask oppsummering, ser vi på serverhelse, forekomsthelse, CPU / minnebruk. Hva er minnekonsumentene, hva er aktivitetsdriverne, hva er tjenestene? SQL-setninger er viktige - hva er utførelsesstatene? Vis meg utførelsesplanene, når ble ting utført, ga trending? Dette kommer til å gi deg sanntid og en historie om hva som hadde skjedd. Og som jeg nevnte, fordi historien vår er atskilt fra HANA, kommer vi til å fange opp ting som var tidsavbrudd og blitt spolet fra HANAs historie. Slik at du kan se det sanne ressursforbruket på systemet ditt på grunn av den separate historikken.
Så, som jeg hadde nevnt, IDERAs nettsted, under Produkter, kan du enkelt finne dette. Hvis du vil prøve dette, er du absolutt velkommen til. Se hvordan den gir informasjon for deg, og det er tilleggsinformasjon på det nettstedet. Så alle interesserte er mer enn glade for å gå inn på det. Nå, i porteføljeproduktene som tilbys av IDERA, er det også en SAP ECC-transaksjonsmonitor, og dette kalles Precise for SAP. Og hva det gjør er - enten du bruker portal eller bare rett opp ECC - det vil faktisk fange sluttbrukertransaksjonen fra klikk til disk, helt ned til SQL-setningen og vise deg hva som skjer.
Nå viser jeg deg bare ett sammendragsskjermbilde. Det er et par takeaways som jeg vil ha deg fra dette sammendragsskjermbildet. Det er Y-aksens responstid, X-aksens tid pluss dagen, og i denne transaksjonsvisningen viser vi deg klienttid, køtid, ABAP-kodetid, databasetid. Vi kan fange sluttbruker-ID-er, T-koder, og du kan faktisk filtrere og vise servere via en bestemt transaksjon. Og så kjører mange butikker frontend av landskapet under VMware, slik at du faktisk kan måle hva som skjer på hver av serverne og komme inn på en veldig detaljert analyse. Så denne transaksjonsvisningen er for sluttbrukertransaksjonen gjennom hele SAP-landskapet. Og du kan finne det på nettstedet vårt under Produkter APM Tools, og dette vil være SAP-løsningen som vi har. Installasjonen for dette er litt mer komplisert, så det er ikke bare å laste ned og prøve det, som vi har for HANA. Dette er noe hvor vi vil samarbeide om å gjøre, designe og implementere den samlede transaksjonen for deg.
Så bare en tredje hurtig sammenfattende arbeidsbelastningsanalyse for SAP HANA, den er omfattende, agentløs, sanntid, og tilbyr en historie. Vi tilbyr muligheten til å laste ned og prøve det på nettstedet ditt.
Så med det skal jeg gi tiden tilbake til Eric, Dez og Dr. Bloor.
Eric Kavanagh: Ja, kanskje Robin, noen spørsmål fra deg, og deretter Dez etter Robin?
Dr. Robin Bloor: OK. Jeg mener, det første jeg vil si er at jeg virkelig liker transaksjonsvisningen, fordi det er akkurat det jeg ville ønsket i den situasjonen. Jeg jobbet mye - vel, det er lenge siden akkurat nå - å gjøre resultatovervåking, og det var den slags; vi hadde ikke grafikken i disse dager, men det var den typen ting jeg spesielt ønsket å kunne gjøre. Slik at du på en eller annen måte kan sprøyte deg inn uansett hvor problemet skjer.
Det første spørsmålet jeg har er, vet du, de fleste implementerer S / 4 på en eller annen måte utenfor boksen, vet du. Når du engasjerer deg i en gitt implementering av S / 4, oppdaget du at den er implementert bra, eller at du ender opp med å oppdage ting som kan gjøre at kunden vil konfigurere? Jeg mener, hvordan går det hele sammen?
Bill Ellis: Vel, hver butikk er litt annerledes. Og det er forskjellige bruksmønstre, det er forskjellige rapporter. For nettsteder som har ad hoc-rapportering, mener jeg at det faktisk er et slags jokertegn på systemet. Og så er en av de avgjørende tingene å begynne å måle og finne ut hva grunnlinjen er, hva som er normalt for et bestemt sted, hvor er det aktuelle nettstedet, basert på bruksmønstrene, og understreker systemet. Og gjør deretter justeringer derfra. Typisk er overvåkningsoptimaliseringen ikke en gang, det er virkelig en kontinuerlig praksis der du overvåker, avstemmer, finslipper og gjør systemet bedre for sluttbrukersamfunnet for å kunne betjene virksomheten mer effektivt.
Dr. Robin Bloor: Ok, så når du implementerer - jeg mener, jeg vet at dette er et vanskelig spørsmål å svare på fordi det kommer til å variere avhengig av implementeringsstørrelse - men hvor mye ressurs bruker IDERA-overvåkningsevnen, hvor mye bruker den ? Gjør det noen forskjell for noe eller er det bare ikke slags forstyrrelser? Hvordan fungerer det?
Bill Ellis: Ja, jeg vil si at overhead er omtrent 1-3 prosent. Mange butikker er veldig villige til å ofre det fordi du potensielt vil kunne kjøpe det tilbake i form av optimalisering. Det avhenger av bruksmønstre. Hvis du gjør et fullt landskap, avhenger det av de individuelle teknologiene som overvåkes. Så, kilometer varierer, men som vi snakket om, er det definitivt bedre å bruke litt på å vite hva som skjer, enn bare å bli blind. Spesielt vil det være, du vet, her er vi i januar og du kommer til behandling i løpet av året, og du samler data på 12 måneder. Du vet, det er resultater, å få rapporter til regulatoriske organisasjoner, bankene, til aksjonærene, er helt avgjørende for en kritisk forretningsprestasjon.
Dr. Robin Bloor: Rett. Og bare et raskt, fra ditt perspektiv - fordi jeg antar at du er involvert i en hel serie SAP-nettsteder - hvor stor er bevegelsen blant SAPs kundebase mot S / 4? Jeg mener, er det noe du vet, at det er et slags skred av entusiastiske kunder som går etter det, eller er det bare et stødig sild? Hvordan ser du det?
Bill Ellis: Jeg tror det var en tå for et par år siden. Nå vil jeg si at folk er litt opp til kneet. Jeg tror at gitt tidslinjen folk kommer til å bli virkelig fordypet i HANA de neste par årene. Og så overvåking, transformasjon, du vet, jeg tror at flertallet av kundene er slags på læringskurven sammen. Og så tror jeg at vi ikke er helt i snøskredet slik du hadde uttalt, men jeg tror at vi er inne på den store transformasjonen over til HANA.
Dr. Robin Bloor: Ok, så når det gjelder nettstedene du har sett som har gått for dette, tilpasser de også HANA til andre applikasjoner, eller er de på en eller annen måte fullstendig konsumert ved å lage dette ting fungerer? Hva er bildet der?
Bill Ellis: Ja, ofte vil folk integrere SAP med andre systemer, avhengig av hvilke moduler og så videre, så det er litt. Jeg ser egentlig ikke folk distribuere andre applikasjoner på HANA ennå. Det er absolutt mulig å gjøre. Og det er mer rundt landskapet rundt SAP-infrastrukturen.
Dr. Robin Bloor: Jeg antar at jeg bør gi deg videre til Dez. Jeg har hogget tiden din. Dez?
Dez Blanchfield: Takk. Nei, det er bra. To veldig raske, bare for å prøve å sette temaet. SAP HANA har vært ute i et par år nå, og folk har hatt en sjanse til å vurdere det. Hvis du skulle gi oss et grovt estimat av prosentandelen som driver det - fordi det er mange mennesker som driver med disse tingene - hva tror du at prosentandelen av markedet som du er klar over er for øyeblikket som har gått fra bare tradisjonelle SAP-implementeringer til SAP på HANA? Ser vi på 50/50, 30/70? Hva, prosentvis av prosentandelen av markedet ser du på mennesker som har overgått og flyttet nå mot folk som bare holder igjen og venter på at ting skal forbedre seg eller bli bedre eller endre eller hva tilfellet måtte være?
Bill Ellis: Ja, fra mitt perspektiv ville jeg faktisk satt prosentandelen rundt 20 prosent. SAP har en tendens til å være tradisjonelle virksomheter. Folk har en tendens til å være veldig konservative og så folket deres vil dra føttene. Jeg tror det også kommer an på, har du kjørt SAP i lang tid, eller er du en slags SMB som kanskje nylig hadde distribuert SAP? Og så, det er slags faktorer, men samlet sett tror jeg ikke prosentandelen er 50/50. Jeg vil si 50 prosent er i det minste dable og at HANA kjører et sted i datasentret.
Dez Blanchfield: Den interessante takeawayen som du ga oss tidligere var at dette er en fait accompli på en måte og at klokken fysisk og bokstavelig tikker på tiden for overgang. Tror du at folk har vurdert det i prosessen med å gjøre det? Hva er den generelle følelsen av folkeforståelse at dette er et overgangsskifte i plattform, det er ikke bare et alternativ, det blir standard?
Og fra SAPs synspunkt er jeg sikker på at de skyver på den måten fordi det er en betydelig konkurransefordel i ytelsen, men det er også, antar de, de bryter kontrollen bak på plattformen i stedet for at den går til en tredje- festdatabase, bringer de den nå tilbake til sin egen plattform. Tror du selskaper faktisk har fått den beskjeden? Tror du folk forstår det og nå er i gang med det? Eller er det fremdeles, slags, en uklar ting, tror du, ute på markedet?
Bill Ellis: Jeg tror ikke SAP er sjenert over å kommunisere og folk som har gått til SAPPHIRE har sett HANA overalt. Så jeg tror folk er godt klar over, men menneskets natur er hva det er, du vet, noen mennesker er, slags, og drar føttene litt.
Dez Blanchfield: Fordi jeg tror grunnen til at jeg stilte det spørsmålet, og du må tilgi meg, men det er at jeg er enig. Jeg tror de ikke har vært sjenerte med å formidle det. Jeg tror at signalet har gått ut på mange måter. Og jeg er enig med deg - jeg vet ikke at alle har hoppet enda. Du vet, tradisjonelle foretak, veldig store bedrifter som driver med dette, er fremdeles på mange måter, ikke helt å dra føttene, men bare prøve å takle skiftets kompleksitet. Fordi jeg tror den ene tingen som verktøyet ditt, og absolutt demonstrasjonen din i dag har fremhevet, og for meg, en viktig takeaway jeg ønsker at alle lytter og er innstilt på i dag for å sitte opp og ta hensyn til reflekterende, er at du har en nå er det forenklet prosessen i tankene mine. Jeg tror det er en gjeng veldig nervøse CIO-er og teamene deres under dem som tenker: “Hvordan gjør jeg overgangen fra tradisjonelle RDBMS, relasjonsdatabaseadministrasjonssystemer, som vi har kjent i flere tiår, til et helt nytt paradigme av beregning og lagringshåndtering på et sted som fremdeles er relativt modig? ”i tankene mine. Men det er ukjent på mange måter, og det er veldig få mennesker som har gjort det skiftet på andre områder, at det ikke er som om de har fått en annen del av virksomheten som allerede har gjort et trekk til å beregne minne. Så det er en alt-eller-ingenting bevegelse i tankene deres.
Så en av tingene jeg har tatt bort fra dette mer enn noe annet - jeg kommer til å treffe deg med et spørsmål om et øyeblikk - er at frykten nå, tror jeg, er innlagt på mange måter og den før i dag, hvis jeg lytter til CIO, ville jeg, tenkt, “Vel, hvordan skal jeg gjøre denne overgangen? Hvordan skal jeg garantere den samme muligheten som vi har i den relasjonsdatabaseadministrasjonsplattformen og mange års erfaring fra DBAer, til en ny plattform som vi for øyeblikket ikke har ferdighetene i? ”Så spørsmålet mitt med det er, tror du at folk har forstått at verktøyene er der nå med det du tilbyr, og at de på en måte kan puste dypt og sukke av lettelse over at overgangen ikke er så skummel som den kan ha vært før at dette verktøyet er tilgjengelig? Tror du at folk har forstått det, eller er det fortsatt, slags, en ting som de bare kjemper med overgangen til dataminne i minne og lagring i forhold til gamle skolekombinasjoner av NVMe, flash og disk?
Bill Ellis: Ja, så det er utvilsomt mye teknologi og verktøy som grafisk kan vise dette, hva som skjer og gjøre det veldig enkelt å finne de beste ressursforbrukere. Jeg mener det hjelper å forenkle ting, og det hjelper teknologipersonalet virkelig å få et godt håndtak. Hei, de vil være i stand til å vite hva som skjer og kunne forstå alt av kompleksitet. Så absolutt verktøyene på markedet er absolutt nyttige, og derfor tilbyr vi arbeidsmengde-analyse for SAP HANA.
Dez Blanchfield: Ja, jeg synes at det som er bra med det du har vist oss i dag, er at når du overvåker maskinvarestykket, operativsystemstykket, til og med overvåker noe av arbeidsmengden som beveger seg, som sagt, jeg mener, verktøyene har vært der i noen tid. Litt for meg, spesielt innen slike som HANA, er at vi ikke nødvendigvis har hatt evnen til å få et forstørrelsesglass og kikke inn i det og se helt ned til hva verktøyet ditt gjør med det som skjer med spørsmålene og hvordan de er å være strukturert og hvor den belastningen er.
Med de distribusjonene du har sett så langt, gitt at du er bokstavelig talt den mest autoritative på dette rommet i plattformen din i verden, noen av de raske gevinstene du har sett - har du fått noen anekdotisk kunnskap du kan dele med oss rundt noen av eureka-øyeblikkene, aha-øyeblikkene, der folk har distribuert IDERA-verktøyet, de har funnet ting de bare ikke var klar over, var i plattformene og forestillingene de har hatt. Har du fått noen gode anekdotiske eksempler på hvor folk nettopp har distribuert det, ikke egentlig visste hva de har hatt og plutselig borte, "Wow, vi visste faktisk ikke at det var der inne?"
Bill Ellis: Ja, så en stor begrensning av de originale verktøyene er at hvis en løpende forespørsel blir avbrutt, skyller den informasjonen, og du har i utgangspunktet ikke historien. Av oss som lagrer historikken offline, som et løpende spørsmål, har du en historie, du vet hva som hadde skjedd, vil du kunne se utførelsesplan og så videre. Og slik at du, på en måte, kan hjelpe sluttbrukermiljøet i utgangspunktet å operere bedre, skrive rapporter bedre osv. Og så, historien er noe som er veldig hyggelig å ha. Og en av tingene som jeg hadde ment å vise er at du kan se på sanntid opptil fire uker, og så kan du enkelt zoome inn på et hvilket som helst tidsinteresse av interesse, og så kan du avsløre den underliggende kjøreaktiviteten. Bare det å ha den synligheten er noe som er veldig nyttig å vite hvilken flaskehals som har oppstått.
Dez Blanchfield: Du nevnte at det er flerbrukere, når det først var distribuert, og jeg ble ganske imponert over det faktum at det er agentløs og effektivt null berøring på mange måter. Er det normalt at en enkelt distribusjon av verktøyet ditt blir tilgjengelig for alle fra nettverksoperasjonssenteret i NOC og ser på kjerneinfrastruktur som ligger til grunn for klyngen helt opp til applikasjons- og utviklingsteamet? Er det normen og bruker du en gang, og de vil dele det, eller forventer du at folk kan ha modellforekomster som ser på forskjellige deler av stabelen? Hvordan ser det ut?
Bill Ellis: Så basisteamet vil typisk ha en veldig sterk interesse for teknologiske grunnlag for hva som skjer i SAP. Det er klart det er flere lag som vil støtte hele landskapet. HANA-brikken er bare fokusert på det. Jeg vil bare bruke SAP-basisteamet som de viktigste forbrukerne av informasjonen.
Dez Blanchfield: Rett. Det slår meg imidlertid at hvis jeg har et utviklingsteam eller ikke engang bare på kodenivå, men hvis jeg har et team av dataforskere eller analytikere som gjør analytisk arbeid med datasettene der inne, spesielt gitt at det er et betydelig trykk på datavitenskap som blir brukt til alt i organisasjoner nå, i mitt sinn - og korrigere meg hvis jeg tar feil - ser det ut til at dette også vil være av stor interesse for dem, fordi man på mange måter av de alvorlige tingene du kan gjøre i et datalagermiljø, er å slippe løs en dataforsker og la den bare begynne å gjøre ad hoc-spørsmål. Har du hatt noen eksempler på at den typen ting har skjedd der butikker har ringt deg og sagt: “Vi har kastet et data science-team på saken, det er virkelig vondt, hva kan vi gjøre for dem kontra hva vi gjør bare tradisjonell operativ overvåking og styring? ”Er det til og med en ting?
Bill Ellis: Vel, ja, jeg ville snu dette litt og kuttet svaret mitt ville være at når jeg ser på ytelse, er prestasjonsbevisst når det gjelder å utvikle QA-produksjon, vet du, jo før du lagrer, jo mindre problemer, mindre overraskelser du har. Så absolutt.
Dez Blanchfield: I etterkant av det har mange verktøy som jeg har hatt erfaring med - og jeg er sikker på at Robin vil være enige - mye av verktøyene her, hvis du har et stort RDBMS, trenger du virkelig høyt dyktige, dypt kunnskapsrike, erfarne DBAer. Noen av infrastruktur- og plattformkravene som følger med SAP HANA fordi det for øyeblikket støttes på bestemte distribusjoner som er tilpasset spesiell maskinvare og så videre, så vidt jeg vet. Du vet, det er mennesker med tiår med erfaring som ikke er like. Det jeg ser er imidlertid at det ikke nødvendigvis er kravet med dette verktøyet. Det virker som om du kan distribuere verktøyet ditt og gi det til noen ganske nye ansikter og gi dem kraften med en gang til å finne ting som ikke fungerer bra. Er det slik at det er en ganske kort læringskurve for å komme opp i fart med dette og få litt verdi ut av å distribuere den? Du vet, min generelle sans er at du ikke trenger å ha 20 års erfaring med å kjøre et verktøy for å se verdien umiddelbart. Er du enig i at det er tilfelle?
Bill Ellis: Å absolutt, og til ditt poeng, tror jeg at mye av suksessen med en distribusjon virkelig avhenger av planleggingen og arkitekten av SAP HANA-miljøet. Og så er det utvilsomt mye kompleksitet, mye teknologi det er bygd på, men så kommer det bare til å overvåke bruksmønstrene til det som skjer. Så selv om det er mer sammensatt, er det på en måte pakket og noe forenklet. Det er veldig dårlig.
Dez Blanchfield: Ja, så før jeg gir tilbake til Eric, fordi jeg vet at han har et par spørsmål, særlig fra noen som har kommet gjennom spørsmål og svar som så interessante ut, og jeg er opptatt av å høre svaret på. Tradisjonell reise for noen til - du nevnte tidligere at du kan få den, du kan laste ned den og prøve den. Kan du bare gjøre rede på det raskt for å lytte til folk enten i dag eller for folk som kanskje kan spille på det senere? Hva er de raske to-tre trinnene for å få tak i en kopi og distribuere den og prøve den i miljøene sine før de kjøper den? Hvordan ser det ut? Hva er trinnene for det?
Bill Ellis: Ja. Så, IDERA.com og bare gå til Produkter, så ser du arbeidsbelastningsanalyse for SAP HANA. Det er en nedlastingsside. Jeg tror de vil be deg om litt kontaktinformasjon, og produktet er bare pakket med en lisensnøkkel, slik at du kan installere den med Setup.exe og bare få rullering, tror jeg, veldig raskt.
Dez Blanchfield: Så de kan gå til nettstedet ditt, de kan laste ned det. Jeg husker at jeg så på det for en stund siden, og jeg har også sjekket inn i går kveld, du kan be om en demo, fra minnet, hvor noen på teamet ditt, slags vil lede deg gjennom det? Men du kan faktisk laste den ned gratis og distribuere den lokalt i ditt eget miljø, på din egen tid, ikke sant?
Bill Ellis: Ja.
Dez Blanchfield: Utmerket. Jeg tror vel, mer enn noe annet, det er noe jeg personlig vil anbefale folk å gjøre, er å ta en kopi av nettstedet, ta tak i noe av dokumentasjonen der fordi jeg vet at det er mye godt innhold der å gjøre det med, og bare prøv det. Sett det i ditt miljø og se hva du finner. Jeg mistenker at når du først har sett deg under panseret med SAP HANA-miljøene med IDERA-verktøyet, kommer du til å finne ting du faktisk ikke var klar over at var der.
Se, tusen takk for det, og takk for tiden bare for spørsmål og svar med Robin og I. Eric. Jeg kommer til å gi meg tilbake til deg fordi jeg vet at noen spørsmål og svar har kommet fra våre deltagere også.
Eric Kavanagh: Ja, bare en skikkelig rask her. Så en av de fremmøtte kommenterer en virkelig god kommentar her bare når vi snakker om hvordan ting endrer seg. Når det er sagt fra før, kvelte minnet, gikk avtaket med hyppige personsøkinger, og for øyeblikket kveler CPU med for mye data i minnet. Du vet, det er nettverksproblemer. Det kommer alltid til å være et bevegelig mål, ikke sant? Hva ser du på som bane i disse dager når det gjelder hvor flaskehalsene skal være og hvor du kommer til å trenge å rette oppmerksomheten?
Bill Ellis: Ja. Inntil du måler, er det vanskelig å vite det. En av tingene med SQL-setningene er at de kommer til å være driverne for ressursforbruk. Og så i det tilfellet du skulle ha et stort minneforbruk eller CPU-forbruk, vil du kunne finne ut hvilken aktivitet som forårsaket det ressursforbruket. Nå ville du ikke nødvendigvis ønsket å drepe det, men du vil også være klar over det og, slags hva som skjer, hvor ofte skjer det osv. Vi er liksom fortsatt nye når det gjelder å adressere hele settet eller kokeboken med svar på forskjellige forhold. Og så er det et flott spørsmål og tiden vil vise seg. Vi vil ha mer informasjon etter hvert som tiden går.
Eric Kavanagh: Det er det. Vel, dere er på et veldig interessant sted. Jeg tror du kommer til å se mye aktivitet de kommende månedene og de neste par årene, fordi jeg vet at SAP, som du antydet i innholdssamtalen, har gitt en fin lang rampe for folk å gjøre overgangen til HANA. Men ikke desto mindre har den rampen en slutt, og på et visst punkt må folk ta noen alvorlige avgjørelser, så jo før, jo bedre, ikke sant?
Bill Ellis: Absolutt.
Eric Kavanagh: Ok, folkens, vi har brent en times tid her på Hot Technologies. Du kan finne informasjon på nettet, insideanalysis.com, også techopedia.com. Fokuser på dette nettstedet for mye interessant informasjon, inkludert en liste over alle arkivene våre over de siste webcastene. Men folkens, en stor takk til dere alle der ute, til vennene våre på IDERA, til Robin og selvfølgelig, Dez. Og vi henter deg neste uke, folkens. Takk igjen for din tid og oppmerksomhet. Ha det fint. Ha det.
