Ära võtma: Võõrustaja Eric Kavanagh arutab külaliste dr. Robin Bloori, Dez Blanchfieldi ja IDERA Bill Ellis'iga mälumahtu ja SAP HANA-d.
Te pole praegu sisse logitud. Video nägemiseks logige sisse või registreeruge.
Eric Kavanagh: Hea küll, daamid ja härrad. Tere ja Tere tulemast veel kord. Kolmapäeval on kell neli Ida-aeg ja paar viimast aastat, mis tähendab, et on jälle käes Hot Technologiesi aeg. Jah, tõepoolest, minu nimi on Eric Kavanagh, ma olen teie tänase vestluse host.
Ja inimesed, me räägime täna lahedatest asjadest. Sukeldume mälumaailma, täpne pealkiri on “Into the Future: In-Ramp for In-Memory Computing”. Tänapäeval on see kõik raev ja seda mõjuval põhjusel, peamiselt seetõttu, et mälu on nii palju kiirem, kui loota ketravatele ketastele. Väljakutse on aga see, et peate palju tarkvara ümber kirjutama. Kuna tänapäeva tarkvara, suurem osa sellest, on kirjutatud ketast silmas pidades ja see muudab tõesti rakenduse arhitektuuri. Kui kavandate rakenduse ketravat ketast ootama, siis teete asju lihtsalt teisiti kui siis, kui teil on mälutehnoloogias kogu see võimsus.
Teie kohta on olemas täpne koht, lööge mind @eric_kavanagh. Üritan alati järgida ja ka uuesti teha, kui keegi mind mainib.
Nagu ma ütlesin, räägime täna mälust ja täpsemalt SAP HANA-st. Teie veetsite viimase aasta tõesti SAP-i kogukonnaga väga hästi tundma õppides. Ma pean ütlema, et see on põnev keskkond. Müts maha inimestele, kes juhivad seda operatsiooni ja on eesliinil, sest SAP on uskumatult hea toiming. See, mis neil on tegelikult väga hea, on äri ajamine. Nad on muidugi ka suurepärased tehnoloogia alal ja on tõesti teinud HANA-sse suuri investeeringuid. Tegelikult mäletan - see oli vist umbes kuus või seitse aastat tagasi -, et tegime tegelikult mingit tööd USA õhujõudude heaks ja saime SAP-ist kellegi sisse, kes tuli kohale ja andis meile varase pilgu maailma HANA ja mis plaanitud oli. Ja pehmelt öeldes - SAP Labsi inimesed olid palju aega ja vaeva näinud, et mõista seda arhitektuuri, mis on taas täiesti erinev traditsioonilisest keskkonnast, sest teil on kõik mälu. Nad räägivad nii tehingute kui ka analüütiliste andmete tegemisest mälus samadel andmetel, erinevalt traditsioonilisest viisist, milleks on see välja tõmmata, panna see näiteks kuuti, analüüsida seal, võrreldes tehingutega, mis juhtub väga erineval viisil.
See on huvitav ruum ja tahame teiselt müüjalt IDERA-lt teada saada, kuidas kõik need asjad tööle hakkavad ja mida otse kaldtee endast kujutab. Niisiis, me kuuleme dr Robin Bloorit, meie endi peaanalüütikut siin Bloori rühmas; Dez Blanchfield, meie andmeteadlane ja siis hea sõber Bill Ellis IDERA-st. Niisiis, ma annan kätte võtmed dr Robin Bloorile, kes selle ära võtab.
Dr Robin Bloor: Jah, nagu Eric ütles, oli aeg, mida SAP HANA esmakordselt meile andis, tagasi aastaid tagasi, nüüd. Kuid see oli väga huvitav, see konkreetne aeg oli väga huvitav. Oleme sattunud ühte või kahesse ettevõttesse, kes ühel või teisel viisil pakkusid mäluseadme tehnoloogiat. Oli üsna selge, et mälu tuleb. Ja alles siis, kui SAP tõusis püsti ja käivitas äkitselt HANA. See oli šokk, kui nägin, kuidas SAP seda tegi. See oli nagu šokk, sest ma eeldasin, et see tuleb mujalt. Ma eeldasin, et see on Microsoft, Oracle või IBM või keegi teine. Idee, et SAP seda tegi, oli minu jaoks tõesti väga üllatav. Ma arvan, et see ei oleks tohtinud, sest SAP on üks strateegilisi müüjaid ja, tead, kõik, mis tööstuses juhtub, pärineb ühest neist.
Igatahes, kogu mõte mälus, ma mõtlesin, et me mõistsime, et me kasutasime sellest rääkimist, et niipea, kui te tegelikult mällu lähete - see ei seisne andmete mällu panemises, see on pühendumine idee, et mälukiht on süsteemikirje - niipea kui süsteemiregistrid mällu rändate, hakkab ketas muutuma üht sorti jaotusmeediumiks ja see saab teistsuguseks. Ja minu arust oli see väga põnev, kui see juhtuma hakkas. Nii, et ketra ketramine on tõesti otsas. Ketrusketas on peagi olemas ainult muuseumides. Ma pole kindel, kui kiiresti see niipea on, kuid põhimõtteliselt on tahkisketas nüüd Moore'i seaduse kõveral, see on juba kümme korda kiirem kui pöörlev rooste, nagu nad seda praegu nimetavad, ja üsna varsti on see ikkagi kiirem ja siis tähendab see, et kettakasutusjuhtumeid jääb aina vähemaks.
Ja uudishimulik tõdemus, traditsiooniline DBMS, tegelikult ketramiseks oli ehitatud palju traditsioonilist tarkvara, eeldati, et ketramine on ketas. Sellel olid igasugused füüsilise taseme võimalused, millesse oli vaevata sisse programmeeritud, et ketravat ketast ära kasutada, muutes andmete hankimise võimalikult kiireks. Ja kõik see pestakse ära. Lihtsalt kaovad, teate? Ja siis oli ilmselgelt väga - ma ei tea, tulus, ma arvan, et see on lõpuks - avamine mälus olevale andmebaasile, mis püüdis asuda seisukohale, et suured andmebaasid, Oracle ja Microsoft, SQL Server ja IBM DB2, see hõivas mäluruumis ja seda oli väga huvitav vaadata, kui nad edasi marssivad.
Räägime mälukaskaadist; see on lihtsalt mainimist väärt. See on ka põhjus, miks seda mainiti, põhjus, miks ma selle sinna sisse viskasin, just selleks, et kõigile teada anda, kui ma siin mälust räägin, on kõik need kihid, millest ma räägin, tegelikult mälu. Kuid kui järsku aru saate, on see hierarhiline kauplus, mitte ainult mälu. Ja seetõttu kehtib ka peaaegu kõik see, mida me ammu-ammu hierarhilise poe kohta teada saime. Ja see tähendab ka seda, et igas mälusiseses andmebaasis tuleb selle kaudu liikuda, mõned lihtsalt kõnnivad seda RAM-i enda kaudu, teate. Ja see on lihtsalt muutumas üha suuremaks ja suuremaks ning seda mõõdetakse nüüd megabaitides. Kuid teil on L1 vahemälu, mis on sada korda kiirem kui mälu, L2 vahemälu 30 korda kiirem kui mälu ja L3 vahemälu umbes 10 korda kiirem kui mälu. Niisiis, teate, on olemas palju tehnoloogiat - ka õiglane kogus tehnoloogiat -, mis on vastu võtnud strateegia, mille kohaselt kasutatakse neid vahemälusid nagu salvestusruumi asjade täitmiseks, eriti andmebaasitehnoloogiat. Nii et teate, see on üks mõjutaja.
Siis on tekkinud 3D XPoint ja IBM-i PCM. Ja see on peaaegu RAM-kiirus, põhimõtteliselt see, millega mõlemad need müüjad kiitlevad. Kasutusjuhud on ilmselt erinevad. Sellega varajane katsetamine on veel lõpule viimata. Me ei tea, kuidas see mõjutab RAM-i kasutamist ja mälus olevate andmebaaside tehnoloogiat selles küsimuses. Seejärel on teil RAM ja SSD. Praegu on RAM umbes 300 korda kiirem, kuid muidugi see arv väheneb. Ja SSD versus ketas, mis on umbes 10 korda kiirem, kui sellest aru saan. Niisiis, selline olukord teil on. See on hierarhiline pood. Teistmoodi vaadates on mälu muidugi täiesti erinev. Niisiis, ülemisel diagrammil on kaks rakendust, mõlemad võivad pääseda juurde andmebaasile, kuid pääsevad kindlasti juurde roostevabaduse andmeid. Ja kuidas te tegelikult asju võrgu kaudu voolate, sõltuvalt sellest, millised sõltuvused on ümberringi, kas teil on ETL. Niisiis, see tähendab, et teate, andmed lähevad ketramis rooste kohta ja siis väljuvad rooste ketramisest, et kuhu iganes minna, ja kuhu iganes jõuda, läheb see tagasi ketrus rooste juurde, mis on kolm osa. Ja pidage meeles, et mälu võib olla sada tuhat korda kiirem kui ketramine ja te mõistate kindlasti, et andmete võtmine ja mällu panemine muudab selle asja tegelikult hoopis teistsuguseks.
Ehk siis oleksite võinud arvata, mis juhtub siin ekraanil kuvatavaga, võisite arvata, et ühel või teisel viisil läheb ETL tegelikult andmetelt mälus olevatele andmetele. Kuid tegelikult ei pruugi see seda teha; tegelikult võib siin olla olukord paremal, kus kaks rakendust saavad sama mälu tegelikult käivitada. Kindlasti võiks mälupõhine andmebaas teile selle võimaluse anda, kui teil on lukustus ja kõik muu selle ümber korraldatud. Niisiis, see ei muuda lihtsalt asjade kiirust, see muudab ka seda, kuidas tegelikult rakendusi ja terveid andmevooge konfigureerite.
Niisiis, see on tohutu laadi mõju. Niisiis, mälu on häiriv, eks? Ja me peaksime selle saama sellest, mida ma ütlesin. Mälusisene töötlemine on praegu kiirendi, kuid sellest saab norm. Seda kasutatakse vastavalt rakenduse väärtusele ja see on väga-väga huvitav, et SAP tuleb tegelikult välja nende ERP-i tarkvara versiooniga, mis on mälus. Ja latentsusaega parandamine kuni kolme suurusjärgu võrra on täiesti võimalik ja tegelikult isegi rohkem kui see on võimalik, sõltuvalt sellest, kuidas te seda teete. Niisiis, mälu abil saate kiirust märkimisväärselt parandada. Ja tulemus, SAP HANA's S / 4 - mille nad on välja lasknud, arvan, et noh, inimesed ütlevad, et noh, see öeldakse veel välja, kuid see ilmus kindlasti eelmisel aastal - see on SAP-i kliendibaasi arvestades mängude vahetaja. Ma mõtlen, et SAP-i ERP-i kasutab seal 10 000 ettevõtet ja teate, et peaaegu kõik nad on suured ettevõtted. Niisiis, idee, et neil kõigil oleks stiimul mällu minna ja oma põhitegevust kasutada, kuna ERP on peaaegu alati põhilised rakendused, mida ettevõtted juhivad, see on lihtsalt tohutu mänguvahetaja ja see on väga huvitav. Kuid muidugi kõlab see kõik väga hästi, kuid see tuleb arukalt konfigureerida ja seda tuleb hästi jälgida. See pole nii lihtne, kui kõlab.
Seda öeldes arvan, et annan palli edasi: kes see kutt on? Oh, Austraalia kutt Dez Blanchfield.
Dez Blanchfield: Väga naljakas. Järgneb alati raske tegu, dr Robin Bloor. Täname, et mind täna külastasite. Niisiis, suur teema, kuid põnev. Niisiis, ma olen valinud pildi, mida sageli loon, kui mõtlen kaasaegsele andmejärvele ja ettevõtte andmeladudele ning oma väikestele andmetele. Nii et siin on mul see kaunis järv, mida ümbritsevad mäed ja lained tulevad välja, ja lained kraapivad nende kivide kohal. See on omamoodi, kuidas ma vaimselt kujutan, kuidas need tänapäeval suure andmejärve sees välja näevad. Lained on pakkimistööd ja reaalajas analüütikat heidetakse andmetele, olles kaljudeks. Ja kui ma mõtlen sellele kui füüsilisele järvele, siis toob see minusuguse äratuskõne tagasi, et te teate, milliseid andmeladusid me praegu ehitame, selle mündi mündi ja selle tähtaja andmejärv on see, et nad on väga suured ja sügavad ning vahel võib neis torm olla. Ja kui me seda teeme, peate alati otsustama, mis tormi tekitab.
Nii et mulle tundub selle asja teemas, et see sireenikõne mälu sisselülitamiseks on tõepoolest väga tugev ja mõjuval põhjusel. See toob kaasa nii palju olulist ärilist ja tehnilist kasu. See on arutelu paar tundi teisel päeval.Kuid üldine nihe mäluarvutite juurde, esiteks tahan lihtsalt kajastada seda, kuidas me siia sattusime ja mis selle võimalikuks teeb, sest see justkui paneb aluse sellele, kus mõned väljakutsed võivad esikohal olla ja mida peame teadma Arvestades ja mõeldes meie maailmas, eemaldudes traditsioonilisest vanast ketravast ketast, kus on andmeid hoides, ja saates otsinguid kettale ja välja, mällu ja mälust ning protsessoritesse, eemaldame praegu peaaegu ühe neist tervetest kihtidest, on ketramine ketas. Sest pidage meeles, et juba arvutamise esimestel päevadel, arhitektuuriliselt, ei liikunud me pikka aega suurarvutist ega keskmike maailmast selleni, mida me algselt pidasime põhimäluks ja trummelmäluseadmeks, teate.
Nagu ütles dr Robin Bloor, ei muutunud andmete arvutisse ümberpaigutamisel kasutatud lähenemisviis tegelikult mõneks aastaks, tegelikult paarikümne aasta jooksul, dramaatiliselt. Kui mõelda tõsiasjale, et tänapäeval on tehniline moodne andmetöötlus umbes 60-aastase vea jooksul armunud, siis tead, kuus aastakümmet ja rohkem, ja selles mõttes, et saad osta kasti riiulilt, nagu oleks. Nihutamine uuele arhitektuurile tekkis minu meelest tõesti siis, kui me nihkusime mõtlemisest suurarvutite ja keskvahemike ning tuumemälu ja trummide hoiustamise arhitektuuride ümber julgetele või superarvutitele, eriti nagu Seymour Cray, kus sellised asjad nagu risttala tagaplaanid sai asjaks. Selle asemel, et kasutada ainult ühte marsruuti, et andmeid kogu tagaplaanil või emaplaadil teisaldada, nagu tänapäeval seda nimetatakse. Ja sisemälu, teate, ei mõtle tänapäeval inimesed tegelikult sellele, mida see tegelikult tähendab, kui öeldakse DIMM ja SIMM. Kuid SIMM on ühekordne sisemälu ja DIMM on kahekordne sisemälu ning meil on sellest keerulisem, kuna mitmesuguseid asju on kümneid erinevaid: mõni video jaoks, mõni ainult üldrakenduste jaoks, mõni sisseehitatud protsessoriks.
Niisiis, seal oli see suur nihe uuele viisile, kuidas andmeid talletati ja neile juurde pääseti. Peame läbima sama nihke teises terves põlvkonnas, kuid mitte niivõrd riistvaras endas, vaid riistvara omaksvõtmisel äriloogikas ja andmeloogikakihis ning see on minu meelest veel üks suur paradigma muutus. .
Aga põgusalt sellest, kuidas me siia sattusime. Ma mõtlen, et riistvara tehnoloogia paranes ja paranes dramaatiliselt. Läksime protsessorite olemasolust ja tuuma idee oli üsna kaasaegne kontseptsioon. Peame praegu iseenesestmõistetavaks, et meie telefonidel on kaks või neli südamikku ja meie arvutitel on kaks või neli või isegi kaheksa südamikku töölaual ja kaheksa ja 12 ja enam uut, teate, 16 ja 32 isegi serveriplatvormil . Kuid see on tegelikult üsna kaasaegne asi, et tuumad said protsessorites võimeks ja et me läksime 32-bitiselt 64-bitisele. Seal juhtus paar suurt asja: saime mitme südamiku jaoks suurema kellakiiruse, et saaksime asju teha paralleelselt ja igaüks neist südamikest saaks käivitada mitu lõime. Järsku saime samade andmetega korraga käitada palju asju. Kuuskümmend neli-bitine aadressivahe andis meile kuni kaks terabaiti RAM-i, mis on fenomenaalne mõiste, kuid nüüd on asi selles. Need mitmerealised tagaplaani arhitektuurid, teate, emaplaadid, said kunagi teha asju ainult ühes suunas: edasi ja tagasi. Nagu päevade Cray andmetöötluse ja mõne tolleaegse superarvuti disainilahenduse puhul, ja nüüd lauaarvutites ja tavalistes riiulites, omamoodi lauaarvutitele mõeldud rack-tüüpi arvutites, sest tõesti, enamik tänapäevaseid Arvutid läbisid nüüd selle suurarvutite, keskvahemiku, mikrolaudade ajastu ja oleme nad muutnud serveriteks.
Ja suur osa sellest superarvuti võimalusest, see superarvuti klassi disain, sai sisse lükatud tavalistesse riiulikomponentidesse. Tead, tänapäeval on idee võtta väga odavaid rack-mount PC-sid ja paigutada need sadade, kui mitte tuhandete sekka, ja käitada nendel nagu Linux avatud lähtekoodiga tarkvara ning juurutada SAP HANA-le meeldivaid lahendusi teile, teie tead, me võtame seda sageli enesestmõistetavana. Kuid see on väga uus põnev asi ja selle keerukus on kaasas.
Ka tarkvara sai paremaks, eriti mäluhaldus ja andmete eraldamine. Ma ei hakka selle kohta palju üksikasju laskma, kuid kui vaadata suuremat nihet viimase 15 või umbes sellise aasta jooksul või veelgi vähem, siis kuidas mälu hallatakse, eriti RAM-is sisalduvaid andmeid ja kuidas andmeid RAM-is jaotatakse, nii et nagu dr Robin Bloor juba varem mainis või millele viitas, teate, et asjad saavad lugeda ja kirjutada samal ajal üksteist mõjutamata, selle asemel et ooteaegadel olla. Paljud väga võimsad funktsioonid, näiteks kiibil tihendamine ja krüptimine. Krüptimine on muutumas üha olulisemaks ja me ei pea seda tingimata tegema tarkvara, RAM-i ja CPU-ruumi korral, nüüd, kui see kiibil tegelikult toimub. See kiirendab asju dramaatiliselt. Jagatud andmete salvestamine ja töötlemine, jällegi asjad, mis me kunagi eeldasime olevat superarvutite ja paralleelse töötlemise asjad, võtame seda nüüd iseenesestmõistetavana nagu SAP HANA, Hadoop ja Spark jne.
Niisiis, selle suure jõudlusega andmetöötluse mõte on see, et HPC võimalused tulid ettevõttele ja nüüd naudib ettevõte eeliseid, mis kaasnevad sellega seoses jõudluse ja tehnoloogilise ruumi ning tehniliste ja äriliste eeliste suurendamisega, kuna, teate, väärtuseni vähendatud aeg langeb dramaatiliselt.
Kuid ma kasutan seda pilti loost, mida ma mõni aeg tagasi lugesin härrasmehest, kes ehitas Lego küljest arvuti korpuse, sest see tuleb alati meelde, kui ma mõnda neist asjadest mõtlen. Ja see on see, et see tundub suurepärase ideena sellel ajal, kui hakkate seda ehitama, ja siis jõuate pooleldi läbi ja saate aru, et tegelikult on keeruline panna kõik Lego bitid kokku ja teha kindel asi, piisavalt kindel emaplaadi ja nii edasi panemiseks, see loob juhtumi personaalarvuti jaoks. Ja lõpuks saate aru, et kõik väikesed bitid ei kleepu õigesti kokku ja peate olema natuke ettevaatlik selle suhtes, milliste väikeste bittidega kokku kleepida, et see kindlaks saaks. Ja see on väga armas idee, kuid see on äratuskõne, kui olete poole peal ja mõistate: “Hmm, võib-olla oleksin lihtsalt pidanud ostma 300-dollarise arvutiümbrise, kuid lõpetan selle nüüd ja lõpetan sellest midagi.”
Minu jaoks on see suurepärane analoogia nende väga keerukate platvormide ehitamiseks, kuna selle ehitamine ja keskkond, kus teil on ruuterid ja kommutaatorid, serverid ja nagid, on hästi ja hea. Ja CPU-d, RAM ja operatsioonisüsteem on kokku koondatud. Ja panite selle peale HANA-taolise hajutatud mälustöötluse ning andmete salvestamise ja andmete haldamise. Selle peale ehitate SAP-virna, saate andmebaasi võimalused ja laadite seejärel oma andmed ja äriloogika ning hakkate sellele lugema ja kirjutama ning päringuid rakendama ja nii edasi. Peate hoidma peal I / O-d ja pidama asju ajakava ning juhtima töökoormust ja mitmekordset töötamist jne. See virn muutub väga keerukaks, väga kiiresti. See on iseenesest keeruline virn, kui see asub ainult ühes masinas. Korrutades selle 16 või 32 masinaga, on see väga-väga ebaoluline. Kui korrutate sadade ja lõpuks tuhandete masinatega, et liikuda 100 terabaidilt petabüüdi skaalale, on see hirmutav kontseptsioon ja need on reaalsused, millega me praegu kokku puutume.
Niisiis, lõpetate siis paari asjaga, mis on ka aidanud seda maailma muuta, ja see tähendab, et kettaruum muutus naeruväärselt odavaks. Teate, kui te oleksite kunagi kulutanud 380–400 tuhat dollarit gigabaidisele kõvakettale, kui see oli massiivne trummel, mille suurus oli - asi, mille korjamiseks oli vaja tõstukit. Tänapäeval on see umbes ühe sendi või kahe sendini alla gigabaiti kauba kettaruumi. Ja RAM tegi sama asja. Mõlemas graafikus on need kaks J-kõverat, muide, kumbki kümnend, seega teisisõnu vaatame kahte 10-aastast plokki, 20-aastast hinnaalandust. Kuid ma murdsin need kaheks J-kõveriks, kuna lõpuks paremal olev sai lihtsalt punktiirjooneks ja te ei näinud detaili, nii et muutsin selle ümber. Gigabaidine RAM 20 aastat tagasi oli suurusjärgus kuus ja pool miljonit dollarit. Nendel päevadel, kui maksate röövitud kauba riistvara eest rohkem kui kolm või neli dollarit gigabaidise RAM-i eest.
Need märkimisväärsed hinnalangused viimase kahe aastakümne jooksul on tähendanud, et nüüd saame liikuda kettaruumist kaugemale ja otse RAM-i, mitte ainult megabaidi tasemel, vaid nüüd ka terabaiti tasemel ja käsitleda RAM-i nagu kettalt. Sellegipoolest oli väljakutseks see, et RAM oli natiivselt lühiajaline - see tähendab midagi, mis kestab lühikese aja jooksul -, seega pidime leidma viise, kuidas selles ruumis vastupidavust pakkuda.
Ja nii, siin on minu mõte, et mälu sisemine andmetöötlus pole nõrga südamega inimene. Selle väga mahuka mälusisese teabe ja selle ümber toimuva töötlemine on huvitav väljakutse; nagu ma juba varem mainisin, pole see nõrga südamega. Niisiis, üks asi, mille oleme sellest kogemusest suuremahulise ja tihedusega mäluarvutitega õppinud, on see, et meie ehitatav keerukus paneb ohtu mitmes valdkonnas.
Vaatame seda lihtsalt jälgimise ja reageerimise vaatenurgast. Andmetele mõeldes algab see kettaruumis, kettades asuvates andmebaasides, surume need mällu. Kui see on mällu salvestatud ja selle koopiad olemas, saame sellest palju koopiaid kasutada ja kui muudatusi tehakse, saab neid mälu tasemel kajastada, selle asemel, et edasi-tagasi liikuda ja üle tahaplaani minna kaks erinevat taset, see läheb mälust sisse ja välja. Oleme lõpetanud selle üliskaala riistvaraplatvormi, mis võimaldab meil seda nüüd teha. Kui räägime hüperskaalatsioonist, on see naeruväärselt tihedal tasemel ja väga suure tihedusega mälu, protsessorite, südamike ja niitide väga suure tihedusega loendis raskem. Selle toetamiseks on meil nüüd olemas väga keerulised võrgupatoloogiad, kuna andmed peavad mingil hetkel liikuma üle võrgu, kui need lähevad sõlmede ja klastrite vahel.
Niisiis, lõpuks on probleemiks seadme rikete koondamine ja peame jälgima seadmeid ja nende osi. Sellele platvormile on sisseehitatud paindlik andmevea redundants ja peame seda jälgima. Jaotatud andmebaasi vastupidavus peame olema sisse ehitatud, nii et peame andmebaasi platvormi jälgima ja selle sisse laduma. Peame jälgima hajutatud töötlemise ajakava, seda, mis toimub mõne protsessi sees kuni küsitluseni ja päringuni, päringu kulgevat teed ning päringu struktureerimise ja täitmise viise. Kuidas see välja näeb, kas keegi on teinud SELECT * "blah" peal või on nad tõesti teinud väga nutika ja hästi struktureeritud päringu, mille eesmärk on saada neile nominaalne, minimaalne andmemaht, mis tuleb kogu tagaplaani arhitektuuri kohta? Meil on mitu erinevat töökoormust, mitu kasutajat ja mitu rühma, kes käitavad sama või mitut töökoormust ja pakkimistöid ning reaalajas ajakava. Ja see segu pakettidest ja reaalajas töötlemisest on meil olemas. Mõni asi jookseb regulaarselt - tund, päev, nädal või kuu - muud on nõudmisel. Keegi istub seal tabletiga, kes soovib teha reaalajas aruannet.
Ja jälle jõuame selle mõttekäiguni, et nendes tekkiv keerukus pole mitte ainult praegu väljakutse, see on üsna hirmutav. Ja meil on see reaalsuskontroll, kas üksik jõudlusprobleem, ainult üks jõudlusprobleem omaette, võib mõjutada kogu ökosüsteemi. Ja nii, et me lõpetame selle väga toreda väljakutse - teada saada, kus on mõjud? Ja meil on see väljakutse: kas oleme reageerivad või proaktiivsed? Kas jälgime asja reaalajas ja näeme, et midagi läheb „pauguks“ ning reageerime sellele? Või oleme näinud mingisugust suundumust ja mõistnud, et peame selle ennetavalt kasutusele võtma? Sest peamine on see, et kõik tahavad midagi kiiret, odavat ja lihtsat. Kuid jõuame lõpuks nende stsenaariumiteni, millele mulle meeldib viidata, ja minu lemmikliin Donald Rumsfeldi nõuandele - mis minu meelest kehtib kõigis neis väga keerukates stsenaariumides - ja see tähendab, et meil on teada tuntud, sest see on midagi kavandasime ja ehitasime ning see töötab plaanipäraselt. Meil on teada tundmatuid, kuna me ei tea, kes mida, millal ja kus töötab, kui see on nõudmisel. Ja meil on tundmatuid tundmatuid ja just neid asju peame jälgima ja kontrollima. Kuna reaalsus on, me kõik teame, ei saa te hallata midagi, mida te ei saa mõõta.
Niisiis, kui teil on CPU ajakava jälgimiseks sobivad tööriistad ja võimalused, otsige ooteaegu ja uurige, miks peavad asjad ootama torujuhtmetes järjekordade järjekorda. Mis toimub mälus, millist kasutamist teostatakse, millist lavastust me mälust kaotame? Kas kraami jagatakse õigesti, kas seda jagatakse laiali, kas meil on piisavalt koopiaid, kus oleks selle koopiaid, et tulla toime sellega visatava koormusega? Mis juhtub protsesside täitmisega eemal opsüsteemi protsessidest? Kas töökohad ise töötavad, üksikud rakendused ja neid toetavad deemonid? Mis toimub nendes protsessides, eriti päringute struktureerimine ning kuidas neid päringuid täidetakse ja koostatakse? Ja nende protsesside tervis on virnades täiesti väljas? Tead jälle, jälle ooteaegadeni jõudes, kas see on ajastatud õigesti, kas see peab ootama, kus see ootab, kas mälu ootamine ootab, I / O, CPU, I / O üle võrgu lõpptarbijale ?
Ja siis tagasi selle punkti juurde, mida ma just enne kokkupanemist just mainisin, on see, kuidas me läheneme nende lahendamise ja reageerimise ajale? Kas me jälgime reaalajas ja reageerime asjadele, mis on kõige vähem ideaalne stsenaarium, kuid isegi siis on parem, kui teeme seda, kui ei teata ja lastakse infotelefonil helistada ja öelda, et midagi läks valesti, ja peame selle jälgima ? Või teeme seda ennetavalt ja vaatame, mis saab edasi? Ehk teisisõnu, kas meil on praegu mälu puudu ja peame lisama rohkem sõlme? Kas teeme trendianalüüsi, planeerime suutlikkust? Ja kõige selle juures jälgime ajaloolisi teostusaegu ja mõtleme läbilaskevõime planeerimisele või jälgime seda reaalajas ning plaanime ennetavalt ümber ja kavandame koormuse tasakaalustamist? Ja kas me oleme teadlikud töökoormusest, mis praegu käivad? Kas me teame, kes mida meie klastris teeb ja miks?
Mälus olevad arvutused on väga võimsad, kuid selle võimsusega on see peaaegu üks neist asjadest, näiteks laetud relv ja mängite reaalajas laskemoonaga. Kui te pole ettevaatlik, saate end lõpuks jalaga tulistada. Niisiis tähendab see, et mälusisene arvutusvõimsus tähendab lihtsalt seda, et suudame väga hajutatud ja diskreetsetes andmekogumites palju rohkem ja kiiremini käitada. Kuid siis on lõpptarbijatelt suurem nõudlus. Nad harjuvad selle väega ja tahavad seda. Nad ei oota enam, et tööde kulgemine võtab nädalaid ja aruanded ilmuvad lihtsas vanas paberis. Ja siis on meil kõige selle all igapäevane hooldus, mis on ümbritsetud lappimise, värskenduste ja täiendustega. Ja kui mõelda 24-tunnisele töötlemisele mälusisese arvutiga, nende andmete haldamisega, kogu töökoormuse haldamisega, siis on see kõik mälus, tehniliselt lühiajalises platvormis, kui hakkame plaastreid ja värskendusi ning täiendusi rakendama seal on kaasas ka terve rida muid juhtimis- ja seireprobleeme. Peame teadma, mida saame võrguühenduseta kasutada, kui saame seda uuendada ja kui me selle võrgus tagasi toome. Ja see viib mind oma viimase punktini, st kuna me muutume neis süsteemides üha keerukamaks, ei ole see midagi, mida inimene saaks teha lihtsalt selleks, et ta imeks neile pöialt ja tõmbaks neile enam kõrva. Enam pole soolestiku lähenemist. Me vajame tõesti arvutus- ja andmehalduse kõrgetasemelise jõudluse haldamiseks ja edastamiseks vajalikke tööriistu.
Ja seda silmas pidades, annan ma IDERA-le üle meie sõbra ja kuulen, kuidas nad selle väljakutse vastu võtsid.
Bill Ellis: Tänan teid väga. Jagan oma ekraani välja ja siin me lähme. Niisiis, see 2017. aastal saadaval oleva kraami kättesaadavaks tegemine on tõesti nõme, kui kaaluda kogu tehnoloogiat ja kõiki meie ette tulnud inimesi. Räägime SAP HANA töökoormuse analüüsist - põhimõtteliselt andmebaaside jälgimise lahendusest: põhjalik, agentideta, pakub reaalajas reaalaega ja selle põhjal koostatakse ajalugu ning seega näete minevikus toimunut. SAP S / 4 HANA pakub parema, kiirema ja odavama potentsiaali. Ma ei ütle, et see on odav, ma lihtsalt ütlen, et see on odavam. Omamoodi, traditsiooniliselt juhtus see, et teil oleks peamine tootmise eksemplar - tõenäoliselt töötab Oracle suuremas kaupluses, potentsiaalselt SQL Serveris - ja siis kasutaksite seda ETL-i protsessi ja teil oleks tõe mitu, omamoodi versiooni. . Ja see on väga kallis, kuna maksite iga nende üksikute keskkondade riistvara, opsüsteemi ja Oracle'i litsentsi eest. Ja peale selle peaks teil olema inimesi, kes sobitaksid ühe tõe versiooni järgmise tõe versiooniga. Ja nii, see mitme versiooniga ETL-i töötlemine oli lihtsalt aeglane ja väga-väga tülikas.
Ja nii, HANA, põhimõtteliselt üks HANA eksemplar, võib potentsiaalselt asendada kõiki neid teisi eksemplare. Niisiis, see on odavam, kuna see on korrutiste asemel üks riistvaraplatvorm, üks opsüsteem. Ja nii, et S / 4 HANA, tõesti, see muudab kõike ja te vaatate põhimõtteliselt SAP-i arengut R / 2-lt R / 3-le, mitmesugustele lisaseadmetele. Nüüd on pärandsüsteem saadaval aastani 2025, seega on teil kaheksa aastat aega, kuni olete tõesti sunnitud rändama. Ehkki me näeme inimesi, teadvustate, varjata seda nende varvastega, sest nad teavad, et see tuleb ja lõpuks teate, et ECC töötab HANA-l ja nii et peate tõesti selleks olema valmis ja mõistma tehnoloogiat.
Niisiis, üks andmebaas, ei töödelda ETL-i ega koopiaid, mida tuleb ühitada. Nii et jällegi kiirem, parem ja odavam. HANA on mälus. SAP tarnib tarkvara ja teie riistvara. Koondtabeleid pole. Üks neist asjadest, mida nad mõtlevad, kui te seda mõtlete, on see, et te ei soovi sellesse süveneda, ostame just kõige suurema serveri, mis on saadaval. Nad soovitavad teil, nagu teie, SAP-i maastikul enne tähtaega paraja suurusega ja põhimõtteliselt öeldakse, et te ei rända 20-aastaseid andmeid.Arvan, et arhiveerimine on infotehnoloogias alakasutatud, seda üldiselt ja mitte ainult SAP-poodides. Ja nii et järgmine asi on see, et SAP on tegelikult kulutanud palju aega oma emakeelse koodi ümberkirjutamisele, et mitte kasutada nuppu SELECT *. SELECT * tagastab kõik veerud tabelist ja see on veergude andmebaasis eriti kallis. Ja nii, see pole SAP HANA jaoks hea mõte. Niisiis, poodides, kus on palju kohandamist ja palju aruandeid, peate seda otsima ja te peaksite täpsustama veerunimesid, kui hakkate Hana-sse kõike üle viima.
Meile meeldib öelda, et HANA ei ole imerohi. Nagu kõiki andmebaase ja kõiki tehnoloogiaid, tuleb seda jälgida ja nagu varem mainitud, on teil vaja numbreid, et ülejääki hallata, mõõtmise abil mõõtmist. Ja üks asi, millest ma IDERA piirkonnas räägin, on see, et iga äritehing on integreeritud dokumendisüsteemiga ja antud juhul saab sellest HANA. Ja nii saab HANA teie SAP-tehingute teostamise, lõppkasutaja kogemuse vundamendiks. Ja seepärast on ülioluline, et seda pidevalt tippkiirusel töötaks. Sellest saab tõepoolest üks läbikukkumispunkt ja inimestega rääkides võib see juhtuda nii, et teil on lõppkasutaja ja võib-olla kasutab neid reaalajas andmeid ning neil on ad hoc päring, mis potentsiaalselt pole päris eks. Võib-olla nad ei ühenda tabeleid ja nad on loonud välimise liitumise, partisanitoote ja tarbivad põhimõtteliselt palju ressursse. Nüüd tunnistab HANA selle lõpuks ära ja tapab selle seansi. Ja seal on meie arhitektuuri ülioluline osa, mis võimaldab teil seda ajaloos tegelikult jäädvustada, et saaksite näha minevikus toimunut ja neid olukordi ära tunda.
Vaatame siis SAP HANA töökoormuse analüüsi. See on versioon 1, seega kutsume teid väga meiega reisile kaasa ja see on IDERA toode. See on kõikehõlmav, kuid samas lihtne. Reaalajas trendidega. Vastuvõtva tervise, näiteks tervise. Jälgime ooteseisundeid, SQL-päringuid, mälutarbijaid ja teenuseid. Niisiis näeb selline GUI välja ja kohe näete, et see on veebis lubatud. Avasin selle lahenduse reaalajas oma süsteemis. Siin on mõned olulised asjad, mida soovite vaadata. Jaotatud oleme omamoodi erinevateks tööruumideks. Kõige olulisem on see, mis toimub hostitasandil alates protsessori ja mälu kasutamisest. Kindlasti ei taha te jõuda seisukohtade vahetamiseni või viskamiseni. Ja siis töötate põhimõtteliselt edasi toimuvate suundumuste suunas, alates reageerimise ajast, kasutajatest, SQL-i väljavõtetest, st sellest, mis süsteemi tegevust juhib.
IDERA üks asi on see, et tead, andmebaasis ei juhtu enne toimingute toimumist midagi. Ja see tegevus on SQL-avaldused, mis pärinevad rakendusest. Seega on SQL-lausete mõõtmine algpõhjuse tuvastamiseks hädavajalik. Liigume siis edasi ja uurime põhjalikumalt. Nii et hostimajanduse tasandil saame tegelikult vaadata mälu, jälgida aja jooksul ja hostprotsessori kasutamist. Astuge tagasi ja vaadake COBSQL-i avaldusi. Nüüd on üks asi, mida te meie arhitektuuri poolel näete, see teave on salvestatud HANA-st väljaspool, nii et kui HANA-ga peaks midagi juhtuma, jäädvustame me põhimõtteliselt teavet kuni, jumal hoidku, olukorrani, kus see pole kättesaadav. . Samuti saame jäädvustada kõike, mis süsteemis toimub, nii et teil oleks selge nähtavus. Ja üks asi, mida me teeme, on see, et me esitame SQL-avaldused kaalutud järjekorras. Niisiis, see võtab arvesse hukkamiste arvu ja seega on see ressursi kogutarbimine.
Ja nii saate siin tutvuda üksikute mõõdikutega - millal see SQL-lause käivitus? Ja siis on ressursitarbimine suuresti ajendatud täitmisplaanist ja seega oleme võimelised seda jooksvalt jäädvustama. HANA on mälus. See on väga paralleelne. Sellel on igal tabelil primaarsed indeksid, mida mõned poed valivad teatud jõudluse probleemide lahendamiseks sekundaarse indeksi loomiseks. Niisiis, teatud tüüpi SQL-i avalduste täitmiskavaga juhtunu tundmine võib olla väga väärtuslik. Vaatame ka teenuseid, mälu tarbimist, kaardistatud aja jooksul. Arhitektuur: jah, see on iseseisev lahendus, mille saate alla laadida meie veebisaidilt, ja arhitektuur on selle veebipõhine.
Kindla eksemplariga saab ühendada mitu kasutajat. Saate jälgida SAP HANA kohalikke eksemplare. Ja me hoiame oma hoidlas jooksvat neljanädalast ajalugu ja seda saab ise hallata. Selle juurutamine on üsna lihtne. Teil on vaja Windowsi serverit. Peate selle alla laadima. Enamikul Windowsi serveritest on sisseehitatud .NET-raamistik ja see on komplekteeritud litsentsiga. Ja siis läheksite installiviisardi juurde, mida juhib Setup.exe, ja see avaks tegelikult ekraani, litsentsilepingu ning töötaksite selle visandi lihtsalt alla, klõpsates nupul „Järgmine“. Ja nii, kuhu soovite HANA paigaldada? Järgmine on andmebaasi atribuudid ja see saab olema teie ühendus SAP HANA-ga, nii et see on HANA eksemplari agendivaba jälgimine. Ja siis anname põhimõtteliselt eelvaate, see on port, millel vaikimisi suhtleme. Klõpsake nuppu „Install” ja see käivitab põhimõtteliselt HANA ja alustate ajaloo loomist. Niisiis, natuke teavet suurustabelite kohta. Saame jälgida kuni 45 HANA eksemplari ja te soovite seda kasutada libisevas skaalas, et määrata vajalike tuumade arv, mälu ja kettaruum. Ja see eeldab, et teil on täielik neljanädalane käimasolev ajalugu.
Nii et kui kiire ülevaade, käsitleme ka serveri tervist, eksemplari tervist, protsessori / mälu kasutamist. Mis on mälukasutajad, millised on tegevuste ajendid, millised on teenused? SQL-avaldused on ülitähtsad - mis on täitmisseisundid? Näidake mulle täitmisplaane, millal asjad täide viidi, trendide lisamine? See annab teile reaalajas ja toimunu ajaloo. Ja nagu ma mainisin, kuna meie ajalugu on HANAst lahus, jäädvustame asju, mille aeg oli aegunud ja mis olid HANA ajaloost kustutatud. Nii, et näete oma süsteemi tegelikku ressursitarbimist eraldi ajaloo tõttu.
Nii et nagu ma juba mainisin, leiate IDERA veebisaidilt jaotist Tooted selle hõlpsalt üles. Kui soovite seda proovida, olete kindlasti teretulnud. Vaadake, kuidas see teile teavet pakub, ja sellel veebisaidil leiate lisateavet. Niisiis on kõigil huvitatud isikutel selle üle hea meel olla. Nüüd on IDERA pakutavates portfellitoodetes ka SAP ECC-tehingute jälgija ja seda nimetatakse SAP-i täpsustamiseks. Ja mis see endast kujutab - kas kasutate portaali või lihtsalt sirgjoonelist ECC-d - see lüüakse lõppkasutaja tehingu klõpsalt kettale kuni SQL-i väljavõtteni ja näitab teile, mis toimub.
Nüüd näitan teile ainult ühte kokkuvõttekraani. Sellel kokkuvõtte ekraanil soovite, et teil oleks paar kaasavõtmist. See on Y-telje reageerimise aeg, X-telje aeg pluss päev ja selles tehinguvaates näitame teile kliendi aega, järjekorda võtmise aega, ABAP-koodi aega, andmebaasi aega. Saame lüüa lõppkasutajate ID-sid, T-koode ja tegelikult saate filtreerida ja näidata servereid konkreetse tehingu kaudu. Ja nii käivad paljud poed VMware'i all maastiku esiosa, nii et saate tegelikult mõõta igas serveris toimuvat ja asuda väga detailsesse analüüsi. Niisiis, see tehinguvaade on mõeldud lõppkasutaja tehingutele kogu SAP maastiku ulatuses. Ja selle leiate meie veebisaidilt toodete APM-i tööriistade alt ja see oleks SAP-lahendus, mis meil on. Selle jaoks on installimine natuke keerulisem, nii et see pole lihtsalt allalaadimine ja proovimine, nagu meil HANA jaoks. See on asi, kus me teeksime koostööd teie jaoks kogu tehingu kavandamiseks ja teostamiseks.
Niisiis, SAP HANA jaoks on vaid kolmas kiire kokkuvõte, töökoormuse analüüs - see on terviklik, agentideta ja reaalajas pakutav ajalugu. Pakume võimalust oma saidil seda alla laadida ja proovida.
Niisiis, ma annan selle aja Ericu, Dezile ja dr Bloorile tagasi.
Eric Kavanagh: Jah, võib-olla Robinil on minult küsimusi ja Dez pärast Robini?
Dr Robin Bloor: Okei. Ma mõtlen, et esimene asi, mida tahaksin öelda, on see, et mulle väga meeldib tehingute vaade, kuna see on täpselt see, mida ma selles olukorras tahaksin. Tegin palju tööd - noh, see on ammu juba praegu - jälgisin jõudluse jälgimist ja see oli omamoodi asi; neil päevil polnud meil graafikat, kuid just seda tahtsin ma teha. Nii et saate ühel või teisel viisil süstida ennast kõikjale, kus probleem ilmneb.
Esimene küsimus, mis mul on, on see, et teate, et enamik inimesi rakendab S / 4 mingil moel kasti, teate. Kui olete S / 4 rakendamisesse sattunud, kas avastasite, et seda on hästi rakendatud või kas olete lõpuks avastanud asju, mis võivad kliendi soovida uuesti konfigureerida? Ma mõtlen, kuidas kõik see läheb?
Bill Ellis: Noh, iga pood on natuke erinev. Ja seal on erinevad kasutusharjumused, aruanded on erinevad. Ajutise aruandlusega saitide all pean silmas seda, nagu süsteemis, tavaliselt, metamärki. Ja nii, üks ülioluline asi on alustada mõõtmist ja välja selgitada, mis on lähteolukord, mis on konkreetse saidi jaoks tavaline, kus on see konkreetne sait, lähtudes nende kasutusharjumustest, rõhutades süsteemi. Ja siis tee sealt muudatusi. Tavaliselt ei ole jälgimise optimeerimine ühekordne, see on tõesti pidev praktika, mille käigus jälgite, häälestate ja lihvite süsteemi, muutes süsteemi lõpptarbijate kogukonna jaoks paremaks, et see saaks äri tõhusamalt teenindada.
Dr Robin Bloor: Hea küll, nii et kui rakendate - ma mõtlen, siis tean, et sellele küsimusele on keeruline vastata, kuna see varieerub sõltuvalt rakenduse suurusest - aga kui palju ressurssi IDERA jälgimisvõimalus moodustab, kui palju see kulutab? Kas see mõjutab midagi või on, lihtsalt see ei sega? Kuidas see töötab?
Bill Ellis: Jah, ma ütleksin, et üldkulud on umbes 1–3 protsenti. Paljud poed on selle nimel väga nõus ohverdama, kuna potentsiaalselt saate selle optimeerimise eest tagasi osta. See sõltub kasutusharjumustest. Kui teete täielikku maastikku, sõltub see individuaalsest jälgitavast tehnoloogiast. Niisiis, läbisõit erineb, kuid nagu me rääkisime, on kindlasti parem kulutada natuke selleks, et teada saada, mis toimub, kui lihtsalt pimedaks ajada. Eriti see oleks, kui teate, siin oleme jaanuaris, kui hakkate töötlema aastaid ja koondate 12 kuu väärtuses andmeid. Teate, et see on tulemuslikkuse saavutamine, aruannete saamine reguleerivatele organisatsioonidele, pankadele ja aktsionäridele, on kriitilise äritulemuse jaoks ülioluline.
Dr Robin Bloor: Õige. Ja just teie vaatevinklist kiiresti - kuna ma arvan, et olete seal seotud terve rea SAP-saitidega - kui suur on SAP-i kliendibaasi liikumine S / 4 suunas? Ma mõtlen, et kas see on asi, mida praegu toimub, on sellele omamoodi entusiastlike klientide laviin või on see lihtsalt püsiv nipp? Kuidas sa seda näed?
Bill Ellis: Ma arvan, et paar aastat tagasi, ma ütleksin, et see oli varvas. Nüüd ma ütleksin, et inimesed on omamoodi kuni põlveni. Arvan, et te teate, arvestades ajakava, mida inimesed järgmise paari aasta jooksul HANA-sse sukeldavad. Ja nii et jälgimine, ümberkujundamine, teate, arvan, et enamik kliente on justkui õppekõveral. Ja nii et ma arvan, et me pole päris laviinis, nagu te ütlesite, kuid ma arvan, et oleme HANA-sse toimuva suure ümberkorraldamise tipus.
Dr Robin Bloor: Olgu, kas olete juba näinud saitide jaoks kohandanud HANA-d ka muudeks rakendusteks või on nad ühel või teisel viisil selle kraami toimimiseks täielikult ära kasutatud? Mis pilt seal on?
Bill Ellis: Jah, sageli integreerivad inimesed SAP-i teiste süsteemidega, sõltuvalt sellest, millised moodulid ja nii edasi, nii et seal on natuke. Ma ei näe veel, et inimesed rakendaksid HANA-s veel muid rakendusi. Seda on kindlasti võimalik teha. Ja see tähendab rohkem SAP-i infrastruktuuri ümbritsevat maastikku.
Dr Robin Bloor: Ma arvan, et parem annaksin teid Dezile. Olen teie aega rääkinud. Dez?
Dez Blanchfield: Aitäh. Ei, see kõik on hea. Kaks väga kiiret, lihtsalt selleks, et proovida teema üles seada. SAP HANA on olnud väljas juba paar aastat ja inimestel on olnud võimalus sellega arvestada. Kui te annaksite meile umbkaudse hinnangu seda kasutavate inimeste protsendile - kuna seda kraami jookseb palju inimesi - siis mis te arvate, mis protsent turust, millest olete teadlik, on praegu läinud alates traditsioonilistest SAP-i rakendustest kuni SAP-ni HANA-s? Kas vaatame 50/50, 30/70? Millist, millist protsenti turust näete inimestest, kes on nüüd ümber astunud ja liikunud, võrreldes rahvaga, kes lihtsalt hoiavad tagasi ja ootavad, et asjad paraneksid või paremaks muutuvad või muutuvad või mis iganes olukorras on?
Bill Ellis: Jah, ma tegelikult ütleksin, et minu vaatenurgast näeksin, et protsent on umbes 20 protsenti. SAP kipub olema traditsiooniline ettevõte. Inimesed kipuvad olema väga konservatiivsed ja nii tõmbab nende rahvas jalgu. Arvan, et see sõltub ka sellest, kas teate, kas olete SAP-i juba pikka aega juhtinud või olete selline väikeettevõte, mis võib-olla oli hiljuti SAP-i kasutusele võtnud? Niisiis, on olemas mitmed tegurid, kuid üldiselt ei usu, et protsent on 50/50. Ma ütleksin, et 50 protsenti vähemalt ragistavad ja lasevad HANA-d kuskil nende andmekeskuses töötada.
Dez Blanchfield: Huvitav kaasavõtt, mille te meile varem andsite, oli see, et see on teatud mõttes faktiline teos ja et kell tiksub füüsiliselt ja sõna otseses mõttes üleminekuaega. Kas arvate, et inimesed on seda tehes seda kaalunud? Milline on rahva arusaam, et see on üleminek platvormile, see pole lihtsalt valik, vaid sellest saab vaikeseade?
Ja SAP-i vaatepunktist olen kindel, et nad lükkavad seda teed, kuna toimivusel on märkimisväärne konkurentsieelis, aga ma arvan, et nad maadlevad ka platvormi tagaosa kontrolli selle asemel, et minna kolmandale- parteide andmebaasi, viivad nad selle nüüd oma platvormile tagasi. Mis te arvate, kas ettevõtted on seda tegelikult saanud? Kas sa arvad, et inimesed saavad sellest aru ja on nüüd sellega valmis? Või on see ikkagi omamoodi ebaselge asi, kas te arvate, et turult välja?
Bill Ellis: Ma ei arva, et SAP suhtleb häbelikult ja SAPPHIRE-s käinud inimesed on HANA-d kõikjal näinud. Niisiis, ma arvan, et inimesed on hästi teadlikud, kuid inimloomus on see, mis see on, tead, mõned inimesed, tõmbavad natuke jalga.
Dez Blanchfield: Sest ma arvan, et selle küsimuse esitamise põhjus ja te peate mulle andeks andma, aga ma olen sellega nõus. Ma arvan, et nad pole olnud häbelikud sellest suheldes. Arvan, et signaal on mitmeti kustunud. Ja ma olen teiega nõus - ma ei tea, et kõik on veel hüpanud. Teate, traditsiooniline ettevõte, väga suured ettevõtted, kes seda juhivad, tegutsevad endiselt paljuski - ei tõmba mitte lihtsalt jalgu, vaid üritavad lihtsalt vahetuse keerukusega hakkama saada. Kuna ma arvan, et üks asi, mida teie tööriist ja kindlasti ka teie tänane meeleavaldus rõhutas, ja minu jaoks on üks võtmeks võtmist, siis tahaksin, et kõik, kes täna kuulavad ja häälestaksid, istuksid üles ja pööraksid sellele peegeldavalt tähelepanu, on teil: tööriist, mis on minu meelest seda protsessi lihtsustatud. Arvan, et nende all on hunnik väga närvilisi CIOsid ja nende meeskondi, kes mõtlevad: “Kuidas teha üleminek traditsioonilistelt RDBMS-idelt, relatsiooniliste andmebaaside haldussüsteemidelt, mida oleme juba aastakümneid tuntud, täiesti uuele arvutus- ja ladustamise juhtimine ruumis, mis on endiselt suhteliselt vapper? ”minu meelest. Kuid see on mitmes mõttes tundmatu ja teistes valdkondades on nihe olnud väga vähe inimesi, et pole nii, nagu oleks neil mõni teine osa ärist, mis on juba liikunud mälusisese arvutuse poole. Niisiis, see on nende mõtetes kõik või mitte midagi.
Niisiis, üks asi, mille ma olen sellest kõigest enam ära võtnud - vastan teile mõne minutiga -, on see hirm, ma arvan, et nüüd ma leian mitmel viisil ja et enne tänast, kui ma oleksin CIO-d kuulanud, mõtleksin ma omamoodi: “Noh, kuidas ma selle ülemineku teen? Kuidas ma saan uuele platvormile, milles meil praegu puuduvad oskused, sama võime, mis meil on relatsioonandmebaaside haldamise platvormil ja aastatepikkuse kogemusega DBAs? "Niisiis, minu küsimus selles on , kas te arvate, et inimesed on aru saanud, et tööriistad on teie pakutavatega nüüd olemas ja et nad saavad omamoodi hingata ja kergendust tunda, et üleminek pole nii hirmutav, kui see võis olla varasem kas see tööriist on saadaval? Kas sa arvad, et inimesed on aru saanud või on see ikkagi selline asi, millega nad lihtsalt võitlevad üleminekuga mälusisesele arvutisse ja mälusisesele salvestusele võrreldes vana koolikombinatsiooni NVMe, välk ja kettaga?
Bill Ellis: Jah, seega on kahtlemata palju tehnoloogiaid ja tööriistu, mis seda graafiliselt kuvada saavad, mis toimub ja mis muudavad ressursside parimate tarbijate tuvastamise väga lihtsaks. Ma mõtlen, et see aitab asju lihtsustada ja aitab ka tehnoloogiapersonalil tõepoolest hästi hakkama saada. Hei, nad saavad teada, mis toimub, ja mõista kogu keerukust. Nii et absoluutselt on turul olevad tööriistad kindlasti abiks ja seetõttu pakume SAP HANA-le töökoormuse analüüsi.
Dez Blanchfield: Jah, ma arvan, et suurepärane asi, mida te meile täna näitasite, on see, et riistvaraüksuse, operatsioonisüsteemiüksuse jälgimisel, isegi osa töökoormuse jälgimisest, nagu te ütlesite, mõtlen, et tööriistad on seal olnud mõnda aega. Minu jaoks, eriti HANA-teemal, on natuke see, et meil pole ilmtingimata olnud võimalust hankida luubi ja sinna piiluda ning vaadata, mida teie tööriist teeb päringutega ja kuidas need toimivad on üles ehitatud ja kus see koormus on.
Siiani nähtud juurutamistega, arvestades, et olete maailmas sõna otseses mõttes kõige autoriteetsem selles ruumis oma platvormil, näete mõnda kiiret võitu, mida olete näinud - kas teil on anekdootlikke teadmisi, mida saaksite jagada Meie ümber on mõned eureka-hetked, aha-hetked, kus inimesed on IDERA tööriistakomplekti juurutanud, ja nad on leidnud oma platvormidel ja etendustel asju, mida nad lihtsalt ei teadnud. Kas teil on mingeid suurepäraseid anekdootlikke näiteid selle kohta, kus inimesed on selle just kasutusele võtnud, ega teadnud tegelikult, mis neil on, ja äkki on läinud: "Vau, me tegelikult ei teadnud, et see seal asub?"
Bill Ellis: Jah, looduslike tööriistade suur piirang on see, et kui põgenenud päring tühistatakse, tühjendab see teavet ja seega pole teil põhimõtteliselt ajalugu. Salvestades ajaloo võrguühenduseta, nagu põgenenud päring, on teil ajalugu, teate, mis oli juhtunud, näete täitmiskava ja nii edasi. Ja see võimaldab teil omamoodi aidata lõppkasutajate kogukonnal paremini tegutseda, aruandeid paremini kirjutada, jne. Ja nii on ajalugu midagi väga toredat omada. Ja üks asi, mida ma tahtsin näidata, on see, et saate reaalajas vaadata kuni neli nädalat ja siis saate hõlpsalt suumida mis tahes huvipakkuvale ajakavale ja siis saate paljastada selle aluseks oleva sõidutegevuse. Lihtsalt selle nähtavuse korral on väga kasulik teada saada, milline kitsaskoht on tekkinud.
Dez Blanchfield: Mainisite, et see on mitme kasutajaga, pärast selle kasutuselevõttu, ja mulle avaldas mulle suurt muljet, et see on mitmel viisil agendivaba ja tõhus. Kas on normaalne, kui teie tööriista ühekordne juurutamine on NOC-i võrguoperatsioonide keskuse kaudu kõigile kättesaadav, jälgides klastri aluseks olevat põhiinfrastruktuuri kuni rakendus- ja arendusmeeskonnani? Kas see on norm ja kui võtate ükskord kasutusele ning nad jagaksid seda, või kas arvate, et inimestel võib olla mudeleid, mis vaatavad virna erinevaid osi? Kuidas see välja näeb?
Bill Ellis: Nii on baasmeeskonnal tavaliselt väga tugev huvi SAP-is toimuva tehnoloogia aluspõhja vastu. Ilmselt on mitu meeskonda, kes toetavad terveid maastikke. HANA tükk on just sellele keskendunud. Ma jätkan SAP-i põhimeeskonna vaikimisi teabe esmaste tarbijatena.
Dez Blanchfield: Õige. Mind paneb jahmatama see, et kui mul on arendusmeeskond või isegi mitte ainult kooditasandil, aga kui mul on meeskond andmeteadlasi või analüütikuid, kes tegelevad seal asuvate andmekogumitega analüütiliselt, eriti arvestades, et seal on olemas kui olulist tõuget infoteaduste rakendamiseks kõikides organisatsioonide sisestes küsimustes, mis on minu arust - ja parandage mind, kui ma eksin - tundub mulle, et see pakub neile ka suurt huvi, sest paljuski tõsistest andmelao keskkonnas tehtavatest võimalustest vabastab andmeteadlane selle ja laseb tal lihtsalt hakata tegema ad hoc päringuid. Kas teil on olnud näiteid selle kohta, et poed on teid juhtinud ja öelnud: „Oleme asja juurde lasknud andmeteaduse meeskonna, see teeb tõesti haiget, mida me saame nende heaks teha, võrreldes sellega, mida me lihtsalt teeme traditsiooniline operatiivne jälgimine ja juhtimine? ”Kas see on isegi asi?
Bill Ellis: Jah, jah, ma muudaksin seda natuke ja lõikaksin vastuseks, et kui vaadata jõudlust ja olla jõudluse teadlik QA tootmise arendamisel, siis teate, mida varem te talletate, seda vähem probleeme, seda vähem üllatusi olete . Niisiis, absoluutselt.
Dez Blanchfield: Pärast seda on palju tööriistu, millega mul on kogemusi olnud - ja ma olen kindel, et Robin nõustub - paljude siin olevate tööriistadega, kui teil on suur RDBMS, vajate tõesti kõrgelt kvalifitseeritud töötajaid, sügavalt teadlikud, kogenud DBA-d. Mõned SAP HANA-ga seotud infrastruktuuri- ja platvorminõuded, kuna seda toetatakse minu teada praegu teatud levitamistel, mis vastavad konkreetsele riistvarale ja nii edasi. Tead, seal on aastakümnete pikkuse kogemusega inimesi, kes pole samad. Kuid ma näen, et see pole selle tööriista puhul tingimata vajalik. Mulle tundub, et saate oma tööriista juurutada ja anda mõnele üsna uuele näole ning anda neile kohe jõu leida asju, mis ei toimi hästi. Kas on nii, et selleks, et sellega kiiresti edasi liikuda ja selle kasutuselevõtmisest mingit kasu saada, on üsna lühike õppimiskõver? Tead, minu üldine mõte on see, et selle väärtuse koheseks nägemiseks ei pea teil olema 20-aastast tööriista juhtimise kogemust. Kas oleksite nõus, et see nii on?
Bill Ellis: Oh absoluutselt ja ma ütlen teile, et suuresti juurutamise edukus sõltub tõesti SAP HANA keskkonna kavandamisest ja arhitektuurist. Ja siis on kahtlemata palju keerukust, palju tehnoloogiat, millele see on üles ehitatud, kuid siis tuleb lihtsalt jälgida toimuva kasutusharjumusi. Ehkki see on keerulisem, on see teatud mõttes pakitud ja mõnevõrra lihtsustatud. See on väga kehv.
Dez Blanchfield: Jah, nii et enne kui pöördun Ericu juurde tagasi, kuna tean, et tal on paar küsimust, eriti sellistelt, mis on tulnud küsimuste ja vastuste kaudu, mis tundusid huvitavad, ja ma soovin seda vastust kuulda. Kellegi traditsiooniline teekond - mainisite juba varem, et saate selle hankida, saate selle alla laadida ja proovida. Kas saate lihtsalt täna kiiresti rahva kuulamise või siis rahva, kes võiks seda hiljem korrata, kiiresti meelde tuletada? Millised on kiired kaks või kolm sammu, et saada koopia kätte ja seda enne keskkonda ostmist juurutada ning oma keskkonnas proovida? Kuidas see välja näeb? Millised sammud selleks on?
Bill Ellis: Jah. Seega, IDERA.com ja minge lihtsalt lehele Tooted ja näete SAP HANA töökoormuse analüüsi. Seal on allalaadimisleht. Arvan, et nad küsivad teilt teatud kontaktteavet ja toode on lihtsalt litsentsivõtmega pakendatud, et saaksite selle installida Setup.exe-iga ja saaksite minu arust väga kiiresti kasutusele.
Dez Blanchfield: Nad saavad teie veebisaidile minna ja selle alla laadida. Ma mäletan, et vaatasin seda mõni aeg tagasi ja kontrollisin ka eile õhtul. Võite mälust taotleda demo, kus keegi teie meeskonnast teid sellest läbi aitab? Kuid saate selle tasuta alla laadida ja kohapeal oma keskkonnas omal ajal kasutada, kas te ei saa?
Bill Ellis: Jah.
Dez Blanchfield: Suurepärane. Noh, ma arvan, et enam kui midagi, see on ilmselt asi, mida ma soovitaksin inimestel isiklikult teha - haarata veebisaidilt koopia, haarata osa seal olevast dokumentatsioonist, kuna ma tean, et seal on palju head sisu selleks, ja lihtsalt proovida. Pange see oma keskkonda ja vaadake, mida leiate. Ma kahtlustan, et kui olete IDERA tööriistaga SAP HANA-keskkonnas kapoti alla pilgu heitnud, leiate te seal asju, mida te tegelikult ei teadnud.
Vaadake, tänan teid selle eest nii palju ja tänu aja eest lihtsalt küsimuste ja vastuste eest koos Robini ja I. Ericuga, annan teile tagasiside tagasi, sest tean, et mõned küsimused ja vastused tulevad ka meie kohalolijate poolt.
Eric Kavanagh: Jah, siin on lihtsalt üks kiire. Niisiis, üks kohalolijatest kommenteerib siin tõeliselt head kommentaari, rääkides lihtsalt sellest, kuidas asjad muutuvad. Varem öeldes, mälu lämbus, aeglustades seda sagedase otsingu abil, praegu on CPU lämbumas liiga palju mälus olevaid andmeid. Teate, et on võrguprobleeme. See on alati liikuv sihtmärk, eks? Mida näete tänapäeval trajektoorina seoses sellega, kus kitsaskohad asuvad ja kuhu peate oma tähelepanu koondama?
Bill Ellis: Jah. Kuni mõõdate, on seda raske teada. Üks asi SQL-lausete juures on see, et nemad saavad ressursitarbimise tõukejõuks. Ja kui teil peaks olema näiteks suur mälukasutus või protsessori tarbimine, saate aru saada, milline tegevus põhjustas ressursside tarbimise. Nüüd ei tahaks te tingimata seda tappa, vaid tahaksite ka sellest teadlik olla ja, mis juhtub, kui sageli see juhtub, jne. Me oleme omamoodi ikka veel uued, käsitledes kogu vastuse komplekti või kokaraamatut erinevatele asjaoludele. Ja nii, see on suurepärane küsimus ja aeg näitab. Aja möödudes on meil rohkem teavet.
Eric Kavanagh: See selleks. Noh, kutid, olete väga huvitavas ruumis. Arvan, et näete lähikuudel ja paaril järgmisel aastal palju tegevust, sest ma tean, et SAP, nagu te meie sisukutses soovitasite, on inimestele üleminekuks pakkunud kena pika tõusu. HANA-le. Kuid sellest hoolimata on sellel rambil lõpp ja mingil hetkel peavad inimesed tegema tõsiseid otsuseid, nii et mida varem, seda parem, eks?
Bill Ellis: Absoluutselt.
Eric Kavanagh: Olgu, inimesed, oleme siin Hot Technologiesis veel tund aega läbi põlenud. Lisateavet leiate veebisaidilt insideanalysis.com, samuti techopedia.com. Keskenduge sellele saidile palju huvitavat teavet, sealhulgas kõigi meie varasemate veebisaadete arhiivide loend. Aga inimesed, suur aitäh teile kõigile, meie IDERA sõpradele, Robinile ja muidugi Dez'ile. Ja me võtame teiega ühendust järgmisel nädalal, inimesed. Täname teid veel kord teie aja ja tähelepanu eest. Ole tubli. Headaega.