Hämtmat: Värd Eric Kavanagh diskuterar datorminne och SAP HANA med gästerna Dr. Robin Bloor, Dez Blanchfield och IDERAs Bill Ellis.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar. Hej och välkommen tillbaka igen. Det är fyra för östlig tid på en onsdag och de senaste par åren, vilket betyder att det är dags igen för Hot Technologies. Ja, jag heter verkligen Eric Kavanagh, jag kommer att vara din värd för dagens konversation.
Och folk, vi ska prata om några coola saker idag. Vi kommer att dyka in i minnesvärlden, den exakta titeln är "Into the Future: A On-Ramp for In-Memory Computing." Det är all raseri i dessa dagar, och med goda skäl, mest för att minnet är så mycket snabbare än att lita på snurrskivor. Utmaningen är dock att du måste skriva mycket mjukvara. Eftersom programvaran i dag, det mesta, har skrivits med disken i åtanke och det verkligen förändrar programmets arkitektur. Om du utformar applikationen för att vänta på en snurrdisk gör du bara saker annorlunda än om du har all den kraften i minnetekniken.
Det finns en plats om din, verkligen, slå mig på, @eric_kavanagh. Jag försöker alltid följa tillbaka och också att retweeta när som helst någon nämner mig.
Som jag sa, vi pratar om i minnet idag, och specifikt om SAP HANA. Din tillbringade verkligen det senaste året att lära känna SAP-gemenskapen riktigt bra, och det är en fascinerande miljö, måste jag säga. Hattar till folk som kör den operationen och är i frontlinjerna, för SAP är en otroligt bra operation. Vad de är riktigt bra på är att göra affärer. De är naturligtvis också bra på teknik och de har verkligen lagt en tung investering i HANA. Jag kan faktiskt komma ihåg - det var förmodligen för cirka sex eller sju år sedan - att vi faktiskt gjorde något för det amerikanska flygvapnet och att vi fick någon från SAP att komma in och ge oss en tidig titt på världen av HANA och vad som var planerat. Och minst sagt, folk på SAP Labs hade lagt mycket tid och ansträngningar på att förstå hur man bygger ut denna arkitektur som är helt annorlunda än en gång från traditionella miljöer, eftersom du har allt i minnet. Så de pratar om att göra både transaktionella och analytiska på samma data i minnet, i motsats till det traditionella sättet, som är att dra ut det, lägga det i en kub, till exempel analysera det där, kontra transaktionellt, som händer på ett helt annat sätt.
Detta är ett intressant utrymme och vi kommer att ta reda på det från en annan leverantör, IDERA, lite om hur allt det här kommer att fungera och vad rampen handlar om, ärligt talat. Så vi kommer att höra från Dr. Robin Bloor, vår egen chefanalytiker här på The Bloor Group; Dez Blanchfield, vår datavetare och sedan god vän Bill Ellis från IDERA. Så med det kommer jag att dela ut nycklarna till Dr. Robin Bloor, som tar bort den.
Dr. Robin Bloor: Ja, som Eric sa, den tid som vi först informerades av SAP HANA var tillbaka för många år sedan, nu. Men det var väldigt intressant, den speciella tiden var väldigt intressant. Vi skulle stöta på ett eller två företag som på ett eller annat sätt erbjöd teknik i minnet. Det var helt tydligt att minnet skulle komma. Och det var verkligen inte förrän SAP stod upp och plötsligt lanserade HANA. Jag menar, det var chock när jag såg SAP göra det. Det var som om det var en chock eftersom jag förväntade mig att den skulle komma från någon annanstans. Jag förväntade mig att det skulle vara, du vet, Microsoft eller Oracle eller IBM eller någon liknande. Tanken att SAP gjorde det var verkligen mycket förvånande för mig. Jag antar att det inte borde ha varit för att SAP är en av de strategiska leverantörerna och ganska mycket, du vet, allt stort som händer i branschen kommer från en av dessa.
Hur som helst, hela poängen om i minnet, jag menar, insåg vi, vi brukade prata om det, att så snart du faktiskt går in i minnet - det här handlar inte om att lägga data i minnet, det handlar om att begå till tänker att minneskiktet är systemposten - så snart du migrerar systemposten till minnet börjar skivan bli ett handoff-medium av en sort och det blir en annan sak. Och jag tyckte att det var väldigt spännande när det började hända. Så, verkligen är det slut för spinning disk. Snurrdisken kommer snart att finnas endast i museer. Jag är inte säker på hur snart det snart är, men i princip är solid-state-disken nu på Moore's lagkurva, den är redan tio gånger snabbare än att snurra rost, som de nu kallar det, och ganska snart är det fortfarande snabbare och då betyder det att användningsfall för disk bara blir färre och färre.
Och det märkliga faktumet, traditionell DBMS, i själva verket, en hel del traditionell programvara byggdes för att snurra disken, antog det snurrdisk. Den hade alla möjliga fysiska nivåer som var noggrant programmerade i för att utnyttja spinndisken, vilket gör att datahämtning så snabbt som möjligt. Och allt detta tvättas bort. Bara försvinner, vet du? Och sedan fanns det uppenbarligen en väldigt - jag vet inte, lukrativt, antar jag, det kommer att vara i slutändan - öppnande för en databas i minnet som försökte ta den position som de stora databaserna, Oracle och Microsoft, SQL Server och IBM: s DB2, det upptog i minnet utrymme och det var mycket intressant att se som kommer marscherar framåt och gör det.
Låt oss prata om minneskaskaden; det är bara värt att nämna. Det är också, anledningen till att nämna detta, anledningen till att jag kastade in det, var egentligen bara för att låta alla få veta, när jag pratar om minne här, är alla dessa lager jag pratar om i själva verket minne. Men du inser plötsligt när du tittar på det här, det här är en hierarkisk butik, det är inte bara minnet. Och därför gäller i stort sett allt vi lärde oss för en lång, lång tid sedan om hierarkisk butik. Och det betyder också att varje databas i minnet måste navigera sig igenom detta, vissa går bara igenom den på själva RAM, du vet. Och det har bara blivit större och större och större och det mäts nu i megabyte. Men du har L1-cache som är hundra gånger snabbare än minne, L2-cache 30 gånger snabbare än minne och L3-cache ungefär 10 gånger snabbare än minne. Så, du vet, det finns mycket teknik - ja, en hel del teknik - har antagit strategin att använda dessa cachar som, typ av, lagringsutrymme på vägen för att få saker att köras, särskilt databasteknologi. Så, du vet, det är en påverkan.
Sedan har vi framväxten av 3D XPoint och IBM: s PCM. Och det är nästan RAM-hastigheter, är i princip vad båda dessa leverantörer skryter. Användningsfallen är förmodligen olika. Det tidiga experimentet med detta är ännu inte slutfört. Vi vet inte hur det kommer att påverka användningen av RAM och tekniken i minnesdatabasen för den delen. Du har då RAM jämfört med SSD. För närvarande är RAM cirka 300 gånger snabbare men naturligtvis minskar den multipeln. Och SSD kontra disk som är ungefär tio gånger snabbare, om jag förstår det. Så det är den typ av situation du har fått. Det är hierarkisk butik. Att titta på det på ett annat sätt är naturligtvis helt annat i minnet. Så det översta diagrammet visar två applikationer, båda kanske åtkomst till en databas, men säkert tillgång till data om snurrande rost. Och hur du faktiskt får saker att flyta genom nätverket, beroende på vilka beroenden som finns, är att du har ETL. Så, detta betyder att data, du vet, går över på rotationsrost och sedan kommer av att rotera rost för att gå någonstans, och för att komma någonstans går de tillbaka till roterande rost, vilket är tre rörelser. Och kom ihåg att minnet kan vara hundra tusen gånger snabbare än snurrdisken, och du inser verkligen att det att ta data och lägga dem i minnet gör det hela verkligen annorlunda.
Så du kanske trodde att vad som skulle hända skulle vara på det som finns på skärmen här, du kanske trodde att ETL på ett eller annat sätt faktiskt bara skulle gå från data till data i minnet. Men i själva verket kanske det inte gör det; i själva verket kan du ha situationen till höger här där två applikationer faktiskt kan avfyra samma minne. Visst en databas i minnet kan ge dig den förmågan, så länge du har låst och allt annat orkestrerat runt det. Så detta förändrar inte bara hastigheten på saker, det ändrar hur du faktiskt konfigurerar applikationer och hela dataflöden.
Så det är en enorm typ av påverkan. Så i minnet är störande, eller hur? Och det borde vi få från det jag sa. Behandling i minnet är för närvarande en accelerator men det kommer att bli normen. Det kommer att användas, tillämpas enligt applikationsvärde, och det är därför mycket, väldigt intressant, att SAP faktiskt kommer ut med en version av deras ERP-programvara som är i minnet. Och latensförbättringar upp till tre storleksordningar helt möjligt, och faktiskt ännu mer än det är möjligt, beroende på hur du gör det. Så du får enorma förbättringar i hastigheten genom att gå i minnet. Och resultatet, SAP HANAs S / 4 - som de har släppt, tror jag, ja, folk säger att det fortfarande släpps, men det släpptes verkligen förra året - det är en spelväxlare med tanke på SAPs kundbas. Jag menar, det finns 10 000 företag där som använder SAP: s ERP och nästan alla är stora företag, du vet. Så tanken på att alla har ett incitament att gå in i minnet och använda deras grundläggande, eftersom ERP nästan alltid är grundläggande applikationer som företagen driver, det är bara en enorm spelväxlare och det kommer att vara väldigt intressant. Men naturligtvis låter allt mycket bra, men det måste konfigureras på ett intelligent sätt och det måste övervakas väl. Det är inte så enkelt som det låter.
Med det sagt tror jag att jag kommer att skicka bollen till vem är den här killen? Åh, australiensiska killen, Dez Blanchfield.
Dez Blanchfield: Väldigt roligt. Alltid en tuff handling att följa, Dr. Robin Bloor. Tack för att du har mig idag. Så stort ämne, men spännande. Så jag har valt en bild som jag ofta tänker på när jag tänker på det moderna datasjön och företagets datalager och mina små pärlor med data. Så här har jag fått den här vackra sjön omgiven av berg och vågor som kommer ut, och vågorna kraschar över dessa stenar. Detta är typ av hur jag mentalt visualiserar hur det ser ut i en stor datasjö i dessa dagar. Vågorna är batchjobb och realtidsanalys kastas mot data, som är stenarna. Och när jag tänker på det som en fysisk sjö, ger det mig ett slags väckarkall till mig att, du vet, omfattningen av datalager som vi bygger nu, anledningen till att vi kom med detta mynt och termen för en datasjö är att de är väldigt stora och de är mycket djupa, och ibland kan du ha stormar i dem. Och när vi gör det måste du alltid lösa vad som skapar stormen.
Så i temat för denna sak verkar det för mig att detta siren-samtal av datorminne är mycket starkt och av goda skäl. Det ger så många betydande kommersiella och tekniska vinster. Det är en diskussion ett par timmar på en annan dag.Men den allmänna övergången till datorminne, för det första vill jag bara täcka hur vi kom hit och vad som gör detta möjligt eftersom det, till exempel, lägger grunden till var några av utmaningarna kan ligga först och vad vi behöver vara uppmärksamma av och tänker på, i vår värld med att flytta bort från traditionell gammal spinnande skiva som innehar data och bläddras på och av skivan och i minnet och ur minnet och till CPU: er, nu tar vi bara bort nästan ett av dessa hela lager, är den snurrande disken. För kom ihåg att vi i de allra första tidiga dagarna av datorer, arkitektoniskt, inte rörde oss länge från mainframe eller mellanslagsvärlden för det vi ursprungligen tänkte på som kärnminne och trumlagring, du vet.
Som Dr. Robin Bloor sa, den metod vi tog för att flytta data runt datorarkitektur förändrades inte riktigt dramatiskt under en tid, faktiskt i ett par decennier. Om du tänker på det faktum att du känner till modern teknik, tekniskt, har funnits, om du förlåter ordspelet i några 60-udda år, vet du, sex decennier och mer och det är i den meningen att du kan köpa en låda från hyllan, som det var. Övergången till ny arkitektur inträffade verkligen i mitt sinne när vi skiftade ut ur tanken kring stordatorer och mellanslag, och kärnminne- och trumlagringsarkitekturer, till de modiga eller superkomponenterna, särskilt sådana som Seymour Cray, där saker som tvärgående bakplan blev en sak. Istället för att bara ha en rutt för att flytta data över bakplanet eller moderkortet, som det kallas i dessa dagar. Och inline-minne, du vet, i dessa dagar tänker människor inte riktigt på vad det faktiskt betyder när de säger DIMM och SIMM. Men SIMM är ett enda inline-minne och DIMM är dubbelt inline-minne och vi har blivit mer komplexa sedan det och det finns dussintals olika minnestyper för olika saker: vissa för video, några för bara allmänna applikationer, några inbyggda i CPU: er.
Så det var denna stora övergång till ett nytt sätt att data lagras och nås. Vi håller på att gå igenom samma skift i en annan hel generation, men inte så mycket i själva hårdvaran utan införandet av hårdvaran i affärslogiken och i datalogikskiktet, och det är ytterligare ett stort paradigmskifte i mitt sinne .
Men bara kort om hur vi kom hit. Jag menar, hårdvaruteknik förbättrades och förbättrades dramatiskt. Vi gick från att ha CPU: er och idén om en kärna var ett ganska modernt koncept. Vi tar det för givet nu när våra telefoner har två eller fyra kärnor och våra datorer har två eller fyra, eller till och med åtta, kärnor på skrivbordet och åtta och 12 och mer till, du vet, 16 och 32 även på serverplattformen . Men det är faktiskt en ganska modern sak att kärnor blev en kapacitet i CPU: er och att vi gick från 32-bitars till 64-bitars. Ett par stora saker hände där: vi fick högre klockhastighet på flera kärnor så att vi kunde göra saker parallellt och var och en av dessa kärnor kunde köra flera trådar. Plötsligt kunde vi köra massor av saker på samma data samtidigt. 64-bitars adressavstånd gav oss upp till två terabyte RAM, vilket är ett fenomenalt koncept, men det är en sak nu. Dessa flervägs bakplanplanarkitekturer, du vet, moderkort, en gång kunde du bara göra saker i en riktning: bakåt och framåt. Och som med dagarna med Cray-datoranvändning och några av dators superdatorutformningar, och nu i stationära datorer och vanliga hylla, typ av rackmonterade datorer på skrivbordskvalitet, för verkligen, de flesta av de moderna Datorer har nu gått igenom denna era av stordator-, mellanklass-, mikro-stationära datorer och vi har förvandlat dem tillbaka till servrar.
Och mycket av den superdatorförmågan, den superdatorutformningen, sköts in i vanliga komponenter utanför hyllan. Du vet idag idén att ta väldigt billiga rackmonterade datorer och lägga dem i rack av hundratals, om inte tusentals, och köra open source-programvara på dem som Linux och distribuera sådana som SAP HANA på det, du vet, vi tar det ofta för givet. Men det är en mycket ny spännande sak och den kommer med dess komplexitet.
Programvaran blev också bättre, särskilt minneshantering och datapartitionering. Jag kommer inte gå in på många detaljer om det, men om du tittar på det stora skiftet under de senaste 15 eller så åren, eller ännu mindre, hur minnet hanteras, särskilt data i RAM och hur data blir uppdelat i RAM, så som Dr. Robin Bloor antydde tidigare eller hänvisat till, du vet, kan saker läsa och skriva på samma gång utan att påverka varandra, snarare än att ha väntetider. Många mycket kraftfulla funktioner som komprimering och kryptering på chip. Kryptering blir en viktigare sak och vi behöver inte nödvändigtvis göra det i programvara, i RAM, i CPU-utrymme, nu som faktiskt händer på chipet nativt. Det påskyndar saker dramatiskt. Och distribuerad datalagring och bearbetning, återigen, saker som vi en gång antog var saker av superdatorer och parallellbehandling, vi tar det nu för givet i utrymmet för sådana som SAP HANA och Hadoop och Spark, och så vidare.
Så hela poängen med detta är denna högpresterande datoranvändning, HPC-kapaciteter kom till företaget och nu åtnjuter företaget de fördelar som följer med prestandaförstärkningar och teknikutrymme och tekniska fördelar och kommersiella vinster, för du vet, den reducerade tiden till värde sjunker dramatiskt.
Men jag använder den här bilden av en historia som jag läste för en tid sedan av en gentleman som byggde ett PC-fodral av Lego, för det kommer alltid att tänka på när jag tänker på några av dessa saker. Och det är det, det verkar som en bra idé när du börjar bygga den, och sedan kommer du halvvägs genom det och du inser att det faktiskt är riktigt knepigt att sätta ihop alla Lego-bitar och göra en solid sak, tillräckligt solid att sätta in ett moderkort och så vidare, det kommer att bygga ett mål för en persondator. Och så småningom inser du att alla små bitar inte håller fast vid varandra och att du måste vara lite försiktig med vilka små bitar du håller ihop för att göra den solid. Och det är en väldigt söt idé, men det är ett väckarklocka när du är halvvägs igenom och du inser, "Hmm, kanske jag borde ha köpt ett 300 dollar PC-fodral, men jag ska avsluta det nu och lära mig något av det."
För mig är det en fantastisk analogi för hur det är att bygga dessa mycket komplexa plattformar, eftersom det är bra och bra att bygga den och hamna i en miljö där du har routrar och switchar och servrar och rack. Och du har CPU och RAM och operativsystem grupperade ihop. Och du lägger något liknande HANA på det för den distribuerade processen i minnet och datalagring och datahantering. Du bygger SAP-stacken ovanpå, du får databasfunktionerna och sedan laddar du in dina data och din affärslogik och du börjar tillämpa några läsningar och skrivningar och frågor osv. På den. Du måste hålla dig uppdaterad om I / O och du måste schemalägga saker och hantera arbetsbelastningar och mångfald och så vidare. Denna stack blir mycket komplex, mycket snabbt. Det är en komplex stack i sig själv om den bara är på en maskin. Multiplicera det med 16 eller 32 maskiner blir det väldigt, mycket icke-trivialt. När du multiplicerar upp till hundratals och så småningom tusentals maskiner, för att gå från 100 terabyte till petabyte skala, är det ett skrämmande koncept, och det är dessa verkligheter vi har att göra med nu.
Så slutar du sedan med ett par saker som också har hjälpt till att förändra denna värld, och det är att diskutrymmet blev löjligt billigt. Du vet, en gång skulle du spendera 380 till 400 tusen dollar på en gigabyte hårddisk när det var en massiv trumma på storleken - något som behövde en gaffeltruck för att plocka upp den. Idag är det ned till, typ av, ett eller två cent per gigabyte med utrymme för hårddisk. Och RAM gjorde samma sak. Dessa två J-kurvor i båda dessa diagram är förresten ett decennium vardera, så med andra ord, vi tittar på två block på 10 år, 20 års prisminskning. Men jag delade dem i två J-kurvor för så småningom blev den till höger bara en prickad linje och du kunde inte se detaljerna i, så jag skalade den igen. En gigabyte RAM för 20 år sedan var något i storleksordningen sex och en halv miljon dollar. Idag om du betalar mer än tre eller fyra dollar för en gigabyte RAM för råvaruhårdvara blir du rånad.
Denna betydande tumbling av prisnedgången under de senaste två decennierna har inneburit att vi nu kan flytta bortom diskutrymme och rakt in i RAM, inte bara på megabyte-nivån, utan nu på terabyte-nivån och behandla RAM som den är disken. Utmaningen med det var dock att RAM var nativt flyktigt - det betyder något som varar under en kort tid - så vi måste komma på sätt att ge motståndskraft i det utrymmet.
Och så, min poäng här är att datorminnet inte är för svaghjärtade. Att jonglera denna mycket storskaliga data i minnet och behandlingen kring dem är en intressant utmaning; som jag antydde tidigare är det inte för svaghjärtade. Så en sak som vi har lärt oss av denna erfarenhet med storskalig och hög täthet i minnet är att komplexiteten som vi bygger skapar risk på ett antal områden.
Men låt oss bara titta på det ur en övervakning och svarssynpunkt. När vi tänker på uppgifterna börjar de på diskutrymme, de sitter i databaser på diskar, vi skjuter upp dem i minnet. När det är i minnet och distribuerat och det finns kopior av det, kan vi använda massor av kopior av det, och om några förändringar görs kan det återspeglas över på minnesnivå istället för att behöva gå av och på och över backplanet vid två olika nivåer, det går in och ut ur minnet. Vi har slutat med den här hårdvaruplattformen som gör det möjligt för oss att göra det nu. När vi talar om överkalkning är det svårare på löjligt täta nivåer, och mycket hög densitet, mycket hög densitet räknas CPU och kärnor och trådar. Vi har nu väldigt komplexa nätverkspatologier för att stödja detta eftersom uppgifterna måste flytta över nätverket någon gång om det kommer att gå mellan noder och kluster.
Så vi slutar med att enhetsfelredundans blir ett problem och vi måste övervaka enheter och delar av det. Vi måste ha en robust redundans för datafel inbyggd i den plattformen och övervaka den. Vi måste ha den distribuerade databasmotståndskraften inbyggd så vi måste övervaka databasplattformen och stapla inuti den. Vi måste övervaka den distribuerade behandlingsplaneringen, vad som händer i några av processerna ända till polling och fråga och sökvägen som frågan tar och hur frågan struktureras och körs. Hur ser det ut, har någon gjort en VÄLJ * på "bla" eller har de faktiskt gjort en mycket smart och välstrukturerad fråga som kommer att få dem den nominella, minsta mängden data som kommer över arkitekturen i backplanet? Vi har flerbelastningsarbete, flera användare och flera grupper som kör samma eller flera arbetsbelastningar och batchjobb och realtidsplanering. Och vi har den här blandningen av batch och realtidsbehandling. Vissa saker körs bara regelbundet - varje timme, varje dag, varje vecka eller varje månad - andra saker är på begäran. Det kan hända att någon sitter där med en surfplatta som vill göra en realtidsrapport.
Och återigen kommer vi till hela den punkten, att komplexiteten som uppstår i dessa inte bara är en utmaning nu, det är ganska skrämmande. Och vi har den här verklighetskontrollen att en enda prestationsfråga, bara en prestationsfråga i sig själv, kan påverka hela ekosystemet. Och så, vi slutar med denna mycket roliga utmaning att ta reda på, var är effekterna? Och vi har den här utmaningen, är vi reaktiva eller proaktiva? Ser vi på saken i realtid och ser att något går ”bang” och svarar på det? Eller har vi sett någon form av trend och insett att vi proaktivt måste komma ombord med det? Eftersom nyckeln är att alla vill ha något snabbt och billigt och enkelt. Men vi slutar med dessa scenarier, vad jag gillar att hänvisa till och min favoritrad av Donald Rumsfeld conundrum - som i mitt sinne gäller i alla dessa scenarier med hög komplexitet - och det är det, vi har känt kända för det är något Vi designade och byggde och det fungerar som planerat. Vi har känt okända genom att vi inte vet vem som kör vad, när och var, om det är på begäran. Och vi har okända okända och det är de saker som vi behöver övervaka och kontrollera. Eftersom verkligheten är, vet vi alla, kan du inte hantera något du inte kan mäta.
Så för att ha rätt verktyg och rätt förmåga att övervaka vår CPU-schemaläggning, leta efter väntetider, ta reda på varför saker måste vänta i schemalagda köer i rörledningar. Vad händer i minnet, vilken typ av användning som utförs, vilken typ av prestanda får vi ut ur minnet? Delas saker upp rätt, distribueras det, har vi tillräckligt med noder som har kopior av det för att hantera arbetsbelastningen som kastas på det? Vad händer med processkörning bort från operativsystemprocesserna? Jobben själva som körs, de enskilda apparna och demonerna som stöder dem? Vad händer inom dessa processer, särskilt struktureringen av frågor och hur körs och sammanställs dessa frågor? Och hälsan hos dessa processer hela vägen ut i stacken? Du vet, återigen, tillbaka till väntetider, är det schemaläggning korrekt, är det att behöva vänta, var är det väntar, är det väntar på minnet läser, I / Os, CPU, I / O över nätverket till slutanvändaren ?
Och sedan tillbaka till den punkten som jag just har nämnt precis snabbt innan jag avslutas och det är det, hur närmar vi oss problemlösning och svarstider till dessa? Ser vi i realtid och reagerar på saker, vilket är det minst ideala scenariot, men även då är det bättre att vi gör det än att inte veta och få hjälpdeskén att ringa och säga att något gick fel och vi måste spåra det ? Eller gör vi det proaktivt och tittar vi på vad som kommer på väg? Så, med andra ord, ser vi att vi har brist på minne och behöver lägga till fler noder? Gör vi trendanalys, gör vi kapacitetsplanering? Och i allt detta, övervakar vi historiska genomförandetider och tänker på kapacitetsplanering eller tittar vi på det i realtid och proaktivt omplanerar och gör lastbalansering? Och är vi medvetna om de arbetsbelastningar som körs i första hand? Vet vi vem som gör vad i vårt kluster och varför?
Datorer i minnet är väldigt kraftfulla, men med den kraften är det nästan en av de sakerna, som en laddad pistol och du spelar med live ammo. Du kan så småningom skjuta dig själv i foten om du inte är försiktig. Så den kraften i minnet beräknar bara att vi kan köra mycket mer och snabbt över mycket distribuerade och diskreta datauppsättningar. Men sedan har det en högre efterfrågan som drivs från slutanvändare. De vänjer sig vid den kraften och de vill ha den. De förväntar sig inte längre att jobbet tar veckor att köra och rapporter dyker upp i vanligt gammalt papper. Och sedan, under allt detta, har vi det dagliga underhållet omkretsat kring lappning, uppdateringar och uppgraderingar. Och om du funderar på att bearbeta dygnet runt med in-minne-dator, hantera den informationen, hantera arbetsbelastningen över det, så är det allt i minnet, tekniskt i den flyktiga plattformen, om vi ska börja tillämpa korrigeringar och uppdateringar i där kommer det också en mängd andra utmaningar för hantering och övervakning. Vi måste veta vad vi kan ta offline, när vi kan uppgradera det och när vi tar tillbaka det online. Och det tar mig till min sista punkt och det är att när vi får mer och mer komplexitet i dessa system, är det inte något som en människa kan göra bara genom att suga tummen och dra i örat längre. Det finns ingen, typ av magkänsla närmar sig längre. Vi behöver verkligen lämpliga verktyg för att hantera och leverera denna höga prestanda i dator- och datahantering.
Och med det i åtanke ska jag överlämna till vår vän från IDERA och höra hur de har mött den här utmaningen.
Bill Ellis: Tack så mycket. Jag delar ut min skärm och här går vi. Så det är verkligen ödmjukt att bara ta hänsyn till all teknik och alla människor som kom före oss att göra det här som är tillgängligt 2017 tillgängligt. Vi kommer att prata om arbetsbelastningsanalys för SAP HANA - i princip en databasövervakningslösning: omfattande, agentlös, ger realtid och den bygger ut en historik, så att du kan se vad som har hänt tidigare. SAP S / 4 HANA erbjuder potentialen att bli bättre, snabbare och billigare. Jag säger inte att det är billigt, jag säger bara att det är billigare. Det typiska som hänt var att du skulle ha en huvudproduktionsinstans - antagligen kör på Oracle i en större butik, eventuellt SQL Server - och sedan skulle du använda den ETL-processen och du skulle ha flera, typ av, versioner av sanningen . Och detta är väldigt dyrt eftersom du betalade för hårdvara, operativsystem, Oracle-licens för var och en av dessa enskilda miljöer. Och sedan skulle du behöva få människor att förena en version av sanningen med nästa version av sanningen. Och så, denna flersversions ETL-behandling var bara långsam och mycket, mycket besvärlig.
Och så kan HANA, i princip en HANA-instans, eventuellt ersätta alla dessa andra instanser. Så det är billigare eftersom det är en hårdvaruplattform, ett operativsystem istället för multiplar. Och så S / 4 HANA, verkligen, det ändrar allt och du tittar i princip på utvecklingen av SAP från R / 2 till R / 3, de olika förbättringspaketen. Nu är det gamla systemet tillgängligt fram till 2025, så du har åtta år tills du verkligen tvingas migrera. Även om vi ser människor, du vet, dubblar tårna i detta eftersom de vet att det kommer och så småningom, du vet, ECC kommer att köras på HANA och du måste verkligen vara beredd på det och förstå tekniken.
Så en databas, inga ETL-processer, inga kopior som måste förenas. Så än en gång, snabbare, bättre och billigare. HANA är i minnet. SAP levererar programvaran, du levererar hårdvaran. Det finns inga sammanlagda tabeller. En av de saker som de, typ av, föreslår när du funderar på detta är att du inte vill komma in på det här, vi kommer bara att köpa den allra största servern som finns. De föreslår att du, typ av, rätt storlek på ditt SAP-landskap i förväg och de säger i princip inte migrera 20 års värde.Jag tror att arkivering är något som är underutnyttjat inom IT, typ över hela linjen, inte bara i SAP-butiker. Och så är nästa sak att SAP faktiskt har spenderat mycket tid på att skriva om sin ursprungliga kod för att inte använda SELECT *. SELECT * returnerar alla kolumner från tabellen och det är särskilt dyrt i en kolumndatabas. Och så är det inte bra för SAP HANA. Så för butiker som har mycket anpassning, många rapporter är det något du vill leta efter och du vill ange kolumnnamn när du fortsätter med att migrera allt till HANA.
Vi vill säga att HANA inte är ett universalmedel. Liksom alla databaser, alla tekniker, måste den övervakas, och som nämnts tidigare behöver du nummer för att hantera överskott, mätning efter mätning. Och en av sakerna som jag pratar om inom IDERA-området är att varje affärstransaktion interagerar med journalsystemet, och i det här fallet kommer det att bli HANA. Och så blir HANA grunden för utförandet av dina SAP-transaktioner, slutanvändarupplevelsen. Och så är det viktigt att den hålls igång i högsta hastighet. Det blir en enda punkt för misslyckande, och när man pratar med människor är det något som kan dyka upp där du har en slutanvändare och kanske använder den realtidsdata och de har en ad hoc-fråga som potentiellt inte är riktigt höger. Kanske kommer de inte att gå med i tabeller och de har skapat en yttre koppling, en partiprodukt och de konsumerar i grunden mycket resurser. Nu kommer HANA att erkänna det så småningom och döda den sessionen. Och så finns det den avgörande delen av vår arkitektur som kommer att göra det möjligt för dig att faktiskt fånga det i historien, så att du kan se vad som hänt tidigare och känna igen dessa situationer.
Så låt oss titta på arbetsbelastningsanalysen för SAP HANA. Detta är version 1 så vi inbjuder dig mycket att gå med oss på resan, och detta är en produkt från IDERA. Det är omfattande, men ändå enkelt. Realtid med trend. Värdhälsa, instanshälsa. Vi spårar väntetillstånd, SQL-frågor, minneskonsumenter och tjänster. Så här ser GUI ut och du kan se direkt utanför fladdermattan att det är aktiverat på webben. Jag öppnade faktiskt denna lösning som körs live på mitt system. Det är några viktiga saker du vill ta en titt på. Vi har, typ av, delat in i olika arbetsytor. Det mest avgörande är vad som händer på värdnivån från en CPU-användning och minnesanvändning. Du vill definitivt inte komma till ett bytande eller rasande ståndpunkt. Och sedan arbetar du i grund och botten på vad som händer under trend, från responstid, användare, SQL-uttalanden, det vill säga vad som driver aktiviteten i systemet.
En av sakerna med IDERA är att du vet att ingenting händer i en databas förrän det finns aktivitet. Och den aktiviteten är SQL-uttalanden som kommer från applikationen. Så att mäta SQL-uttalanden är absolut nödvändigt för att kunna upptäcka orsaken. Så låt oss gå vidare och borra i. Så på värdnivå kan vi faktiskt titta på minne, spåra över tid, värd CPU-användning. Gå tillbaka kan du titta på COBSQL-uttalanden. En av de saker som du kommer att se på vår arkitektursida är att denna information lagras utanför HANA, så om något skulle hända med HANA, fångar vi i princip information upp till, Gud förbjuda, en situation med otillgänglighet . Vi kan också fånga allt som händer på systemet så att du har tydlig synlighet. Och en av sakerna vi kommer att göra är att vi kommer att presentera SQL-uttalanden i viktad ordning. Så det kommer att ta hänsyn till antalet avrättningar, och så är detta den samlade resursförbrukningen.
Och så kan du komma in på enskilda mätvärden här - när körde SQL-uttalandet? Och sedan resursförbrukningen drivs till stor del av exekveringsplanen, och vi kan därför fånga den fortlöpande. HANA är i minnet. Det är mycket parallellt. Det har primära index på varje bord, som vissa butiker väljer att bygga ett sekundärt index för att ta itu med vissa prestandaproblem. Och så kan det vara mycket värdefullt att veta vad som hände med exekveringsplanen för vissa SQL-uttalanden. Vi tittar också på tjänsterna, minneskonsumtion igen, kartläggt över tiden. Arkitekturen: så detta är en fristående lösning som du kan ladda ner från vår webbplats och arkitekturen är att den är webbaktiverad.
Du kan ha flera användare att ansluta till en viss instans. Du kan övervaka lokala instanser av SAP HANA. Och vi håller en rullande fyra veckors historia i vårt förvar och det är självhanterat. För att distribuera detta är det ganska enkelt. Du behöver en Windows-server. Du måste ladda ner den. De flesta Windows-servrar har ett inbyggt .NET-ramverk och det levereras med en licens. Och så skulle du gå till installationsguiden som drivs av Setup.exe och den skulle faktiskt öppna en skärm, licensavtal, och du skulle helt enkelt arbeta ned denna kontur genom att klicka på "Nästa." Och så, var vill du att HANA ska installeras? Nästa är databasegenskaper, och detta kommer att bli din anslutning till SAP HANA, så det här är agentlös övervakning av HANA-instansen. Och då kommer vi i princip att ge en förhandsgranskning, det här är den port som vi kommunicerar som standard. Klicka på "Installera" så startar HANA i princip och du börjar bygga historiken. Så, bara lite av storleksdiagraminformationen. Vi kan övervaka upp till 45 HANA-instanser, och du vill använda den här typen på en glidande skala för att bestämma antalet kärnor, minne, diskutrymme som du behöver. Och detta förutsätter att du har en komplett fyra veckors rullande historia som går in.
Så precis som en snabb sammanfattning tittar vi på serverhälsa, instanshälsa, CPU / minnesanvändning. Vad är minneskonsumenterna, vad är aktivitetsdrivarna, vilka är tjänsterna? SQL-uttalanden är viktiga - vad är exekveringslägen? Visa mig verkställande planer, när genomfördes saker, gav trend? Detta kommer att ge dig realtid och en historia om vad som hade hänt. Och som jag nämnde, eftersom vår historia är skild från HANA, kommer vi att fånga saker som hade gått ut och hade spolats från HANAs historia. Så att du kan se den verkliga resursförbrukningen på ditt system på grund av den separata historiken.
Så, som jag nämnde, IDERAs webbplats, under Produkter, kan du enkelt hitta det här. Om du vill prova detta är du verkligen välkommen till. Se hur det ger information för dig och det finns ytterligare information på den webbplatsen. Så alla intresserade parter är mer än glada att gå in på det. I portföljprodukterna som erbjuds av IDERA finns det också en SAP ECC-transaktionsövervakare, och det kallas Precise for SAP. Och vad det gör är - oavsett om du använder portal eller bara upprätt ECC - det kommer faktiskt att fånga slutanvändartransaktionen från klick till disk, hela vägen ner till SQL-uttalandet och visa dig vad som händer.
Nu visar jag bara en sammanfattningsskärm. Det finns ett par takeaways som jag vill att du ska ha från den här sammanfattningsskärmen. Det är Y-axels svarstid, X-axelens tid plus dagen, och i den här transaktionsvyn visar vi dig klienttid, kötid, ABAP-kodtid, databastid. Vi kan fånga slutanvändar-ID, T-koder och du kan faktiskt filtrera och visa servrar via en viss transaktion. Och så många butiker driver landskapets främre del under VMware, så att du faktiskt kan mäta vad som händer på var och en av servrarna och få en mycket detaljerad analys. Så denna transaktionsvy är för slutanvändartransaktioner genom hela SAP-landskapet. Och du kan hitta det på vår webbplats under Produkter APM-verktyg och detta skulle vara den SAP-lösning som vi har. Installationen för detta är lite mer komplicerad, så det är inte bara att ladda ner och prova det, som vi har för HANA. Det här är något där vi skulle arbeta tillsammans för att göra, designa och genomföra den totala transaktionen för dig.
Så bara en tredje snabb sammanfattning, arbetsbelastningsanalys för SAP HANA, den är omfattande, agentlös, realtid, erbjuder en historia. Vi erbjuder möjligheten att ladda ner och prova det för din webbplats.
Så med det kommer jag att skicka tiden tillbaka till Eric, Dez och Dr. Bloor.
Eric Kavanagh: Ja, kanske Robin, några frågor från dig och sedan Dez efter Robin?
Dr. Robin Bloor: Okej. Jag menar, det första jag vill säga är att jag verkligen gillar transaktionsvyen eftersom det är exakt vad jag skulle vilja i den situationen. Jag gjorde en hel del arbete - det är för länge sedan just nu - att göra prestationsövervakning, och det var den typen; vi hade inte grafiken på de dagar, men det var den typen jag särskilt ville kunna göra. Så att du på ett eller annat sätt kan injicera dig själv varhelst problemet händer.
Den första frågan jag har är att du vet att de flesta implementerar S / 4 på något eller annat sätt utanför lådan. När du engagerar dig i en viss implementering av S / 4, upptäckte du att det har implementerats väl eller hamnar du, vet du och upptäcker saker som kan göra att kunden vill konfigurera om? Jag menar, hur går allt detta?
Bill Ellis: Tja, varje butik är lite annorlunda. Och det finns olika användningsmönster, det finns olika rapporter. För webbplatser som har ad hoc-rapportering, menar jag att det faktiskt är ett jokertecken på systemet. Och så, en av de avgörande sakerna är att börja mäta och ta reda på vad som är baslinjen, vad som är normalt för en viss webbplats, var är den specifika webbplatsen, baserat på deras användningsmönster, och betonar systemet. Och gör sedan justeringar därifrån. Vanligtvis är övervakningsoptimeringen inte en engångsperiod, det är verkligen en pågående praxis där du övervakar, stämmer, klämmer, gör systemet bättre för slutanvändargemenskapen att kunna betjäna verksamheten mer effektivt.
Dr. Robin Bloor: Okej, så när du implementerar - jag menar, jag vet att det här är en svår fråga att besvara eftersom det kommer att variera beroende på implementeringsstorlek - men hur mycket resurs förbrukar IDERA-övervakningsförmågan, hur mycket förbrukar den? Gör det någon skillnad till någonting eller är det bara någon typ av störning? Hur fungerar det?
Bill Ellis: Ja, jag skulle säga att omkostnaderna är ungefär 1–3 procent. Många butiker är mycket villiga att offra det eftersom du potentiellt kommer att kunna köpa det tillbaka när det gäller optimering. Det beror på användningsmönster. Om du gör ett fullt landskap beror det på de enskilda teknologier som övervakas. Så, typ av, körsträcka varierar, men som vi pratade om är det definitivt bättre att spendera lite för att veta vad som händer, än att bara bli blind. Särskilt skulle det vara, du vet, här är vi i januari och du kommer att behandlas i årstiden och du samlar data på 12 månader. Du vet att det är prestanda, att få rapporter till tillsynsorganisationer, bankerna, till aktieägarna är absolut nödvändigt i en kritisk affärsresultat.
Dr. Robin Bloor: Höger. Och bara snabbt, ur ditt perspektiv - för jag antar att du är ute och är involverad i en hel serie SAP-webbplatser - hur stor är rörelsen bland SAP-kundbasen mot S / 4? Jag menar, är det något som du vet att det finns ett slags lavin av entusiastiska kunder som går efter det, eller är det bara ett ständigt trick? Hur ser du det?
Bill Ellis: Jag tror att för ett par år sedan skulle jag säga att det var en tå. Nu skulle jag säga att människor är typ av upp till knäet. Jag tror att med tanke på tidslinjen kommer människor att bli riktigt nedsänkta i HANA de närmaste åren. Och så övervakningen, omvandlingen, du vet, jag tror att majoriteten av kunderna är typ på lärningskurvan tillsammans. Och så jag tror att vi inte riktigt har snöskredet som du hade sagt, men jag tror att vi är på väg till den stora omvandlingen till HANA.
Dr. Robin Bloor: Okej, så när det gäller de webbplatser som du har sett som har använts för detta, anpassar de också HANA för andra applikationer eller är de på ett eller annat sätt helt och hållet förbrukade för att göra det här? Vad är bilden där?
Bill Ellis: Ja, ofta kommer folk att integrera SAP med andra system, beroende på vilka moduler och så vidare, så det är lite. Jag ser inte riktigt människor som distribuerar andra applikationer på HANA ännu. Det är verkligen möjligt att göra. Och så är det mer runt landskapet kring SAP-infrastrukturen.
Dr. Robin Bloor: Jag antar att jag bäst skulle överlämna dig till Dez. Jag har tagit din tid. Dez?
Dez Blanchfield: Tack. Nej, det är allt bra. Två väldigt snabba, bara för att försöka ställa in temat. SAP HANA har varit ute i ett par år nu och människor har haft en chans att överväga det. Om du skulle ge oss en grov uppskattning av procentandelen folk som driver det - för det finns många människor som kör det här - vad tror du att andelen av marknaden som du är medveten om är för närvarande som har gått från bara traditionella SAP-implementationer till SAP på HANA? Ser vi på 50/50, 30/70? Vilken typ av procent av marknaden ser du på människor som har övergett och gjort flytten nu gentemot folk som bara håller kvar och väntar på att saker ska förbättras eller bli bättre eller förändras eller vad som än är fallet?
Bill Ellis: Ja, jag skulle faktiskt sätta, från mitt perspektiv, jag skulle sätta procenten runt 20 procent. SAP tenderar att vara traditionella företag. Människor tenderar att vara mycket konservativa och så deras folk kommer att dra sina fötter. Jag tror att det också beror på, du vet, har du kört SAP länge, eller är du en typ av en SMB som kanske hade nyligen distribuerat SAP? Och så finns det ett antal faktorer, men totalt sett tror jag inte att andelen är 50/50. Jag skulle säga att 50 procent åtminstone dabbar och har HANA kör någonstans i deras datacenter.
Dez Blanchfield: Den intressanta takeaway som du gav oss tidigare var att det här är en fullständig fullbordadhet på ett sätt och att klockan fysiskt och bokstavligen kryssar av vid tidpunkten för övergången. Tror du att människor har tänkt på det i processen? Vad är den allmänna känslan av folkförståelse att detta är en övergångsplattform, det är inte bara ett alternativ, det blir standard?
Och från SAP: s synvinkel är jag säker på att de skjuter på det sättet eftersom det finns en betydande konkurrensfördel i prestanda, men det är också, antar jag, de brottar kontrollen bakom plattformen istället för att den går till en tredje- partidatabasen, de tar nu tillbaka den till sin egen plattform. Tror du att företag faktiskt har fått det? Tror du att folk förstår det och nu anpassar sig till det? Eller är det fortfarande, typ av, en oklar sak, tror du, ut på marknaden?
Bill Ellis: Jag tror inte att SAP är blyg med att kommunicera och människor som har åkt till SAPPHIRE har sett HANA överallt. Så jag tror att människor är väl medvetna, men den mänskliga naturen är vad det är, du vet, vissa människor är, typ av, drar sina fötter lite.
Dez Blanchfield: Eftersom jag tror att anledningen till att jag ställde den frågan, och du måste förlåta mig, men det är som jag håller med. Jag tror att de inte har varit blyga med att kommunicera det. Jag tror att signalen har gått ut på många sätt. Och jag håller med dig - jag vet inte att alla har hoppat än. Du vet, traditionella företag, mycket stora företag som driver detta, är fortfarande på många sätt, inte riktigt dra sina fötter, utan bara försöker kämpa med skiftets komplexitet. Eftersom jag tror att det enda som ditt verktyg, och verkligen din demonstration idag har lyfts fram, och för mig, en viktig takeaway jag skulle vilja att alla lyssnar och stämmer in idag att sitta upp och uppmärksamma reflekterande är att du har en verktyg nu som förenklas den processen i mitt sinne. Jag tror att det finns ett gäng mycket nervösa CIO: er och deras team under dem som tänker: ”Hur gör jag övergången från traditionella RDBMS, relationella databashanteringssystem, som vi har känt i årtionden, till ett helt nytt paradigm av beräkningar och lagringshantering i ett utrymme som fortfarande är relativt modigt? ”i mitt sinne. Men det är en okänd på många sätt, och det är väldigt få människor som har gjort den förändringen inom andra områden, att det inte är som att de har fått en annan del av verksamheten som redan har gjort en övergång till datorminne. Så det är en allt-eller-inget drag i deras sinne.
Så en av de saker som jag har tagit bort från detta mer än någonting - jag kommer att slå dig med en fråga på en minut - är att rädsla nu, tror jag, försvagas på många sätt och den före idag, om jag lyssnade på CIO, skulle jag, tänka, "Tja, hur ska jag göra denna övergång? Hur ska jag garantera samma kapacitet som vi har i den relationella databashanteringsplattformen och många års erfarenhet av DBA: er, till en ny plattform som vi för närvarande inte har färdigheter i? ”Så min fråga med det är , tror du att folk har förstått att verktygen finns där nu med vad du erbjuder, och att de, till exempel, kan ta ett djupt andetag och sucka av lättnad att övergången inte är så skrämmande som den kan ha varit tidigare att det här verktyget är tillgängligt? Tror du att folk har förstått det eller är det fortfarande, typ av, en sak som de bara kämpar med övergången till datorminne och i minnet i förhållande till gamla skolan kombinationer av NVMe, flash och disk?
Bill Ellis: Ja, så det finns utan tvekan en hel del teknik och verktyg som grafiskt kan visa detta, vad som händer och göra det mycket enkelt att fastställa toppresurskonsumenter. Jag menar, det hjälper till att förenkla saker och det hjälper teknikpersonalen verkligen att få ett bra grepp. Hej, de kommer att kunna veta vad som händer och kunna förstå hela komplexiteten. Så, absolut, verktygen på marknaden är definitivt användbara och så vi erbjuder arbetsbelastningsanalys för SAP HANA.
Dez Blanchfield: Ja, jag tycker att det fantastiska med det du har visat oss idag är att när du övervakar hårdvarudelen, operativsystemstycket, till och med övervakar en del av den arbetsbelastning som går igenom, som du sa, menar jag, verktygen har varit där för en tid. Liten för mig, speciellt inom HANA är att vi inte nödvändigtvis har haft förmågan att få ett förstoringsglas och titta in i det och se helt ner till vad ditt verktyg gör med vad som händer med frågorna och hur de är att vara strukturerad och var den belastningen är.
Med de implementeringar som du hittills sett, med tanke på att du är bokstavligen den mest auktoritära i detta utrymme i din plattform i världen, några av de snabba vinsterna som du har sett - har du fått någon anekdotisk kunskap du kan dela med oss runt några av eureka-ögonblicken, aha-ögonblicken, där människor har distribuerat IDERA-verktygssatsen, de har hittat saker som de bara inte visste var i deras plattformar och föreställningar de har haft. Har du fått några fantastiska anekdotiska exempel på var folk just har använt det, inte riktigt veta vad de har haft och plötsligt gått, "Wow, vi visste faktiskt inte att det var där?"
Bill Ellis: Ja, så en stor begränsning av de ursprungliga verktygen är att om en språngfråga avbryts spolar informationen så att du i princip inte har historien. Genom att vi lagrar historiken offline, som en förfrågningsfråga, har du en historik, du vet vad som hänt, du kommer att kunna se exekveringsplan och så vidare. Och så gör det möjligt för dig att, till exempel, hjälpa slutanvändargemenskapen i princip fungera bättre, skriva rapporter bättre osv. Och så är historien något som är riktigt trevligt att ha. Och en av de saker som jag hade tänkt att visa är att du kan titta på realtid upp till fyra veckor och sedan enkelt kan zooma in på vilken tidsram som är intresserad och sedan kan du avslöja den underliggande köraktiviteten. Att bara ha den synligheten är något som är mycket användbart att veta vilken flaskhals som har uppstått.
Dez Blanchfield: Du nämnde att det är flera användare, när det väl har distribuerats, och jag blev ganska imponerad av det faktum att det är agentfritt och effektivt noll beröring på många sätt. Är det normalt att en enda implementering av ditt verktyg sedan är tillgängligt för alla från nätverksoperationscentret i NOC och tittar på kärninfrastrukturen som ligger till grund för klustret hela vägen upp till applikations- och utvecklingsgruppen? Är det normen och du distribuerar en gång och de skulle dela det, eller förutser du att folk kan ha modellinstanser som tittar på olika delar av stacken? Hur ser det ut?
Bill Ellis: Så basteamet har vanligtvis ett mycket starkt intresse för teknikunderlaget för vad som händer i SAP. Det finns uppenbarligen flera lag som kommer att stödja hela landskap. HANA-stycket är bara fokuserat på det. Jag går bara som standard till SAP-basteamet som informationens primära konsumenter.
Dez Blanchfield: Höger. Det slår mig dock att om jag har ett utvecklingslag eller inte ens bara på kodnivå, men om jag har ett team av datavetare eller analytiker som gör analytiskt arbete på datauppsättningarna där, särskilt med tanke på att det finns en betydande drivkraft för datavetenskap som tillämpas på allt inom organisationer nu, i mitt sinne - och korrigera mig om jag har fel - det verkar för mig att detta kommer att vara av stort intresse för dem också, för på många sätt av de allvarliga saker du kan göra i en datalagermiljö är att släppa ut en datavetare och låta den bara börja göra ad hoc-frågor. Har du haft några exempel på den typen av saker som händer där butiker har ringt dig och sagt: ”Vi har kastat ett datavetenskapsteam på saken, det är verkligen ont, vad kan vi göra för dem kontra vad vi gör i bara traditionell operationell övervakning och hantering? ”Är det ens en sak?
Bill Ellis: Tja, ja, jag skulle snälla vända det här lite och minska svaret skulle vara att när jag tittar på prestanda, är prestanda medveten om att utveckla QA-produktion vet du, ju tidigare du lagrar, desto mindre problem, mindre överraskningar har du . Så absolut.
Dez Blanchfield: Därefter följer en hel del verktyg som jag har haft erfarenhet av - och jag är säker på att Robin kommer att hålla med - mycket av verktygen här, om du har ett stort RDBMS behöver du verkligen högkvalificerad, djupt kunniga, erfarna DBA. Vissa av infrastruktur- och plattformskraven som följer med SAP HANA eftersom det för närvarande stöds på särskilda distributioner som är anpassade från särskild hårdvara och så vidare, så vitt jag vet. Du vet, det finns människor med decennier av erfarenhet som inte är samma sak. Men vad jag ser är att det inte nödvändigtvis är kravet med det här verktyget. Det verkar för mig att du kan distribuera ditt verktyg och ge det till några ganska nya ansikten och ge dem kraften direkt att hitta saker som inte fungerar bra. Är det så att det finns en ganska kort inlärningskurva för att komma snabbare med detta och få lite värde av att använda den? Du vet, min allmänna mening är att du inte behöver ha 20 års erfarenhet av att köra ett verktyg för att se värdet omedelbart. Skulle du acceptera att så är fallet?
Bill Ellis: Åh absolut, och till din punkt tror jag att mycket av framgången för en installation verkligen beror på planeringen och arkitekten av SAP HANA-miljön. Och sedan finns det utan tvekan mycket komplexitet, mycket teknik som det bygger på, men då kommer det bara att övervaka användningsmönstren för vad som händer. Så även om det är mer komplicerat är det på ett sätt förpackat och något förenklat. Det är väldigt dåligt.
Dez Blanchfield: Ja, så innan jag lämnar tillbaka till Eric, för jag vet att han har ett par frågor, särskilt från några som har kommit genom frågor och svar som såg intressant ut, och jag är angelägen om att höra svaret på. Traditionell resa för någon att - du nämnde tidigare att du kan få den, du kan ladda ner den och prova. Kan du bara skriva om det snabbt för att lyssna på folk antingen idag eller för folk som kanske spelar upp det senare? Vilka är de snabba två eller tre stegen för att få tag på en kopia och distribuera den och prova den i sina miljöer innan de köper den? Hur ser det ut? Vad är stegen för det?
Bill Ellis: Ja. Så IDERA.com och bara gå till Produkter så ser du arbetsbelastningsanalys för SAP HANA. Det finns en nedladdningssida. Jag tror att de kommer att be dig om lite kontaktinformation och produkten är bara förpackad med en licensnyckel så att du kan installera den med Setup.exe och bara rulla, tror jag, mycket snabbt.
Dez Blanchfield: Så de kan gå till din webbplats, de kan ladda ner den. Jag minns att jag tittade på det för en tid sedan och jag dubbelkontrollerade också i går kväll, du kan begära en demo, från minnet, där någon i ditt team kommer, till exempel, leda dig igenom det? Men du kan faktiskt ladda ner den gratis och distribuera den lokalt i din egen miljö, i din egen tid, eller hur?
Bill Ellis: Ja.
Dez Blanchfield: Excellent. Tja, jag tror att mer än någonting är det som jag personligen skulle råda folk att göra, är att ta en kopia från webbplatsen, ta lite av dokumentationen där för jag vet att det finns mycket bra innehåll att göra det med, och bara prova det. Lägg det i din miljö och se vad du hittar. Jag misstänker att när du tittar under huven med dina SAP HANA-miljöer med IDERA-verktyget kommer du att hitta saker som du faktiskt inte känner till var där.
Se, tack så mycket för det och tack för tiden bara för frågor och svar med Robin och I. Eric, jag kommer att gå tillbaka till dig eftersom jag vet att vissa frågor och svar har kommit igenom från våra deltagare också.
Eric Kavanagh: Ja, bara en riktig snabb här. Så en av de deltagande gör en riktigt bra kommentar här och bara pratar om hur saker och ting förändras. Tidigare säger att minnet kvävde, dämpade genom ofta sökning, för närvarande kvävs CPU med för mycket data i minnet. Du vet, det finns nätverksproblem. Det kommer alltid att vara ett rörligt mål, eller hur? Vad ser du som banan i dag när det gäller var flaskhalsarna ska vara och var du kommer att behöva fokusera din uppmärksamhet?
Bill Ellis: Ja. Tills du mäter är det svårt att veta. En av sakerna med SQL-uttalanden är att de kommer att vara drivkrafterna för resursförbrukning. Och så under en omständighet att du skulle ha en stor minneskonsumtion eller CPU-konsumtion kan du ta reda på vilken aktivitet som orsakade den resursförbrukningen. Nu skulle du inte nödvändigtvis vilja döda det, men du vill också vara medveten om det och, typ av, vad som händer, hur ofta händer det osv. Vi är, typ av, fortfarande nya när det gäller att adressera hela uppsättningen eller kokboken med svar på olika omständigheter. Och så är det en stor fråga och tiden kommer att visa sig. Vi får mer information när tiden går.
Eric Kavanagh: Det är allt. Tja, ni är på ett mycket intressant utrymme. Jag tror att du kommer att se mycket aktivitet under de kommande månaderna och nästa par år eftersom jag vet att SAP, som du föreslog i vårt innehållssamtal, har gett en trevlig lång ramp för folk att göra övergången till HANA. Men ändå har den rampen slut och vid en viss tidpunkt måste människor fatta några allvarliga beslut, så ju tidigare desto bättre, eller hur?
Bill Ellis: Absolut.
Eric Kavanagh: Okej folkens, vi har bränt igenom en timme här på Hot Technologies. Du kan hitta information online, insideanalysis.com, även techopedia.com. Fokusera på den här webbplatsen för massor av intressant information, inklusive en lista över alla våra arkiv för de senaste webbsändningarna. Men folkens, ett stort tack till er alla där ute, till våra vänner på IDERA, till Robin och naturligtvis Dez. Och vi kommer att komma ikapp dig nästa vecka, folkens. Tack igen för din tid och uppmärksamhet. Ta hand om dig. Hejdå.