De personalul Techopedia, 25 ianuarie 2017
Take away : Gazda Eric Kavanagh discută despre calculul în memorie și SAP HANA cu invitații Dr. Robin Bloor, Dez Blanchfield și Bill Ellis IDERA.
În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.
Eric Kavanagh: Bine, doamnelor și domnilor. Buna ziua si bine ai venit din nou. Este ora patru ora estică într-o zi de miercuri și ultimii doi ani, ceea ce înseamnă că este timpul, încă o dată, pentru Hot Technologies. Da, într-adevăr, numele meu este Eric Kavanagh, voi fi gazda dvs. pentru conversația de astăzi.
Și oameni buni, vom vorbi despre câteva lucruri interesante astăzi. Vom să ne scufundăm în lumea memoriei, titlul exact este „În viitor: un on-rampă pentru calculatoare în memorie.” Este toată furia în aceste zile și cu un motiv întemeiat, mai ales pentru că în memoria este mult mai rapidă decât să te bazezi pe discuri învârtite. Totuși, provocarea este că trebuie să rescrieți o mulțime de software. Pentru că software-ul de astăzi, cea mai mare parte, a fost scris cu disc în minte și asta schimbă cu adevărat arhitectura aplicației. Dacă proiectați aplicația pentru a aștepta un disc învârtit, faceți lucrurile altfel decât dacă aveți toată acea putere a tehnologiei în memorie.
Există un spot despre al tău, lovește-mă pe Twitter, @eric_kavanagh. Încerc mereu să urmăresc și, de asemenea, să retweetez oricând mă menționează cineva.
Așa cum am spus, vorbim despre memoria în ziua de azi și mai exact despre SAP HANA. Cu adevărat ați petrecut ultimul an pentru a cunoaște foarte bine comunitatea SAP și este un mediu fascinant, trebuie să spun. Urcări pe cei care conduc acea operație și sunt pe primele linii, deoarece SAP este o operație incredibil de bună. La ce sunt foarte buni este să faci afaceri. Sunt, de asemenea, excelenți la tehnologie, și au investit cu adevărat o investiție grea în HANA. De fapt, îmi amintesc - probabil că a fost vreo șase sau șapte ani în urmă - că făceam ceva de lucru pentru Forțele Aeriene ale SUA de fapt și am primit pe cineva de la SAP să vină și să ne ofere o privire timpurie asupra lumii HANA și ce a fost planificat. Și, pentru a spune cel mai puțin, oamenii de la SAP Labs au depus mult timp și eforturi pentru a înțelege cum să construiți această arhitectură care este complet diferită, încă o dată, din mediile tradiționale, pentru că aveți totul în memorie. Deci, vorbesc despre realizarea operațională și analitică pe aceleași date în memorie, spre deosebire de modul tradițional, care este extragerea lui, a pune-l într-un cub, de exemplu, analizați-l acolo, versus tranzacțional, care se întâmplă într-un mod foarte diferit.
Acesta este un spațiu interesant și vom afla de fapt de la un alt furnizor, IDERA, un pic despre cum vor funcționa toate lucrurile și despre ce este vorba, în mod sincer. Deci, vom auzi de la dr. Robin Bloor, propriul nostru analist șef aici, la The Bloor Group; Dez Blanchfield, omul nostru de date și apoi bunul prieten Bill Ellis de la IDERA. Așa că, cu asta, voi înmâna cheile doctorului Robin Bloor, care o va lua.
Dr. Robin Bloor: Da, așa cum spunea Eric, perioada în care am primit pentru prima dată informații de SAP HANA era acum mulți ani, acum. Dar a fost foarte interesant, acea perioadă anume a fost foarte interesantă. Ne-am întoarce într-una sau două companii care, într-un fel sau altul, ofereau tehnologie în memorie. Era destul de clar că în memorie urma să vină. Și chiar nu a fost până când SAP s-a ridicat și a lansat brusc HANA. Adică, a fost șoc când am văzut că SAP face asta. A fost, parcă, un șoc, deoarece mă așteptam să vină din altă parte. Mă așteptam să fie, știți, Microsoft, Oracle sau IBM sau cineva de genul acesta. Ideea că SAP o făcea a fost foarte surprinzătoare pentru mine. Presupun că nu ar fi trebuit să fie pentru că SAP este unul dintre furnizorii strategici și destul de mult, știi, tot ceea ce se întâmplă în industrie provine de la unul dintre acești.
Oricum, tot ceea ce privește memoria în memorie, vreau să spun, ne-am dat seama, obișnuiam să vorbim despre asta, că de îndată ce intri efectiv în memorie - nu este vorba de a pune date în memorie, este vorba despre angajarea în ideea că stratul de memorie este înregistrarea de sistem - de îndată ce migrați înregistrarea de sistem în memorie, discul începe să devină un mijloc de transfer de un fel și devine un lucru diferit. Și am crezut că a fost foarte interesant atunci când asta a început să se întâmple. Deci, într-adevăr, s-a terminat pentru rotirea discului. Discul de filare va exista în curând doar în muzee. Nu sunt sigur cât de curând va fi în curând, dar, practic, discul solid-state se află acum pe curba legii lui Moore, este deja de zece ori mai rapid decât rugina învârtită, așa cum o numesc acum, și destul de curând va fi mai rapid și încă atunci asta înseamnă că cazurile de utilizare pentru disc devin din ce în ce mai puține.
Și faptul curios, DBMS tradițional, în realitate, o mulțime de software tradițional a fost construit pentru discul de filare, presupunând învârtirea discului. Avea tot felul de capabilități la nivel fizic în care erau programate cu atenție, pentru a exploata discul rotativ, făcând recuperarea datelor cât mai rapid posibil. Și toate acestea sunt spălate. Doar dispărând, știi? Și atunci, în mod evident, a existat un lucru - nu știu, lucrativ, cred, va fi la final - deschiderea unei baze de date în memorie care a încercat să ocupe poziția ca marile baze de date, Oracle și Microsoft, SQL Serverul și IBM DB2, acesta a ocupat în spațiul de memorie și a fost foarte interesant să urmăriți cei care merg înainte și să facă asta.
Să vorbim despre cascada de memorie; merită doar menționat. De asemenea, motivul pentru care am menționat acest lucru, motivul pentru care am aruncat asta, a fost doar să anunț pe toată lumea, când vorbesc despre memorie aici, toate aceste straturi despre care vorbesc sunt de fapt memorie. Dar dintr-o dată îți dai seama când privești acest lucru, acesta este un magazin ierarhic, nu este doar memorie. Și, prin urmare, se aplică și tot ceea ce am învățat cu mult timp în urmă despre magazinul ierarhic. Și, de asemenea, înseamnă că orice bază de date din memorie trebuie să-și navigheze prin asta, unii doar merg prin ea în sine, știți. Și tocmai a devenit din ce în ce mai mare și din ce în ce mai mare și acum este măsurat în megabyte. Dar aveți cache L1, care este de o sută de ori mai rapid decât memoria, cache L2 de 30 de ori mai rapid decât memoria și cache L3 de aproximativ 10 ori mai rapid decât memoria. Deci, știți, există o mulțime de tehnologii - bine, o cantitate corectă de tehnologie - a adoptat strategia de utilizare a acestor memorii ca un fel de spațiu de stocare pe calea executării lucrurilor, în special a bazei de date. Deci, știți, asta este o influență.
Apoi avem apariția 3D XPoint și a PCM-ului IBM. Și este aproape o viteză RAM, este practic ceea ce se laudă ambii furnizori. Cazurile de utilizare sunt probabil diferite. Experiența timpurie cu aceasta este încă finalizată. Nu știm cum va avea impact asupra utilizării RAM și a tehnologiei bazei de date în memorie pentru această problemă. Apoi, aveți RAM versus SSD. În prezent, RAM este de aproximativ 300 de ori mai rapid, dar, desigur, acest multiplu se diminuează. Și SSD versus discul care este de aproximativ 10 ori mai rapid, dacă îl înțeleg. Deci, acesta este tipul de situație pe care o ai. Este magazin ierarhic. Privind-o într-un alt mod, în memorie, desigur, este complet diferit. Așadar, diagrama de sus arată două aplicații, ambele accesând probabil o bază de date, dar cu siguranță accesarea datelor despre rugina învârtită. Iar modul în care efectuați lucrurile să curgă prin rețea, în funcție de dependențele din jur, este ETL. Deci, asta înseamnă că, datele știu că rugina se învârte și apoi se învârte rugina pentru a merge oriunde și pentru a ajunge oriunde se întoarce pe rugina învârtită, care este trei mișcări. Și rețineți că memoria poate fi de o sută de mii de ori mai rapidă decât discul învârtit și cu siguranță vă dați seama că a lua date și a le pune în memorie face ca totul să fie foarte diferit.
Așadar, s-ar putea să fi crezut că ceea ce s-ar întâmpla ar fi pe ceea ce este pe ecran chiar aici, s-ar putea să fi crezut că, într-un fel sau altul, ETL ar fi trecut de fapt de la date la date din memorie. Dar în realitate s-ar putea să nu facă asta; în realitate, este posibil să aveți situația din dreapta aici, unde două aplicații pot efectiv să declanșeze aceeași memorie. Cu siguranță, o bază de date în memorie vă poate oferi această capacitate, atâta timp cât aveți blocarea și orice alt lucru orchestrat în jurul acesteia. Deci, aceasta nu modifică doar viteza lucrurilor, aceasta modifică modul în care configurați de fapt aplicațiile și fluxurile de date întregi.
Deci, are un impact uriaș. Deci, memoria este perturbatoare, nu? Și ar trebui să obținem asta din ceea ce am spus. Prelucrarea în memorie este în prezent un accelerator, dar va deveni norma. Acesta va fi utilizat, aplicându-se în funcție de valoarea aplicației și, prin urmare, este foarte, foarte interesant, faptul că SAP va ieși cu o versiune a software-ului lor ERP care este în memorie. Și latența îmbunătățește până la trei ordine de mărime complet posibilă, și de fapt chiar mai mult decât este posibil, în funcție de modul în care o faci. Deci, veți obține îmbunătățiri uriașe ale vitezei accesând memoria. Și succesul, SAP HANA's S / 4 - pe care l-au lansat, cred, ei bine, oamenii spun că încă este lansat, dar cu siguranță a fost lansat anul trecut - este un schimbător de jocuri, dat fiind baza de clienți SAP. Adică, există 10.000 de companii care folosesc ERP-ul SAP și aproape toate sunt companii mari, știți. Așadar, ideea ca toți să aibă un stimulent pentru a intra în memorie și pentru a-și folosi elementele fundamentale, deoarece ERP este aproape întotdeauna aplicații fundamentale pe care afacerile le rulează, este doar un schimbător de jocuri imens și va fi foarte interesant. Dar, desigur, toate sună foarte bine, dar trebuie configurate în mod inteligent și trebuie monitorizate bine. Nu este atât de simplu pe cât sună.
Acestea fiind spuse, cred că voi transmite mingea, cine este acest tip? Oh, australian, Dez Blanchfield.
Dez Blanchfield: Foarte amuzant. Întotdeauna un act greu de urmat, dr. Robin Bloor. Mulțumesc că m-ai avut azi. Deci, subiect mare, dar interesant. Așadar, am ales o imagine pe care o conturez adesea în minte atunci când mă gândesc la lacurile de date moderne și depozitele de date ale întreprinderii și la micile mele pietre de date. Deci, aici am acest lac frumos înconjurat de munți și valuri care ies, iar valurile se prăbușesc peste aceste stânci. Acesta este felul în care vizualizez mental cum arată în interiorul unui lac cu date mari în aceste zile. Valurile sunt locuri de muncă în serie, iar analiticele în timp real sunt aruncate la date, fiind rocile. Și când mă gândesc la el ca la un lac fizic, îmi revin un apel de trezire că, știți, amploarea depozitelor de date pe care le construim acum, motivul pentru care am venit cu această monedă și termenul de un lac de date este că sunt foarte mari și sunt foarte adânci și, ocazional, poți avea furtuni în ele. Iar când o facem, trebuie să rezolvi întotdeauna ce creează furtuna.
Așa că, în tema acestui lucru, mi se pare că acest apel de sirenă de calcul in memorie este într-adevăr foarte puternic și pentru un motiv întemeiat. Aceasta aduce atât de multe câștiguri semnificative comerciale și tehnice. Este o discuție pentru câteva ore într-o altă zi. Dar trecerea generală către calculul în memorie, în primul rând vreau doar să acoperim modul în care am ajuns aici și ce face acest lucru posibil, deoarece, într-un fel, stabilește bazele locului în care unele dintre provocări pot sta mai întâi și ce trebuie să fim conștienți și să ne gândim, în lumea noastră de a ne îndepărta de discurile vechi de filare tradiționale care conțin date și de a fi păstrat pe disc și pe disc și în memorie și din memorie și în CPU, acum eliminăm aproape unul dintre aceste straturi întregi, fiind discul rotativ. Deoarece amintiți-vă, în primele zile de calcul, arhitectural, nu ne-am mutat mult timp din cadrul mainframe sau din lumea medie a ceea ce am crezut inițial ca memorie de bază și stocare tambur, știți.
După cum a spus dr. Robin Bloor, abordarea pe care am adoptat-o pentru a muta datele în jurul arhitecturii computerului nu s-a schimbat într-adevăr dramatic de ceva vreme, de câteva decenii, de fapt. Dacă vă gândiți la faptul că, știți, tehnologia modernă a fost în jur, dacă veți ierta știftul, de vreo 60 de ani ciudat, știți, șase decenii și mai multe și este în sensul că puteți cumpărați o cutie de pe raft, așa cum era. Trecerea la o nouă arhitectură mi-a venit cu adevărat în minte atunci când ne-am îndepărtat de gândirea în jurul mainframe-urilor și a arhitecturii medii, precum și a arhitecturilor de memorie de bază și de stocare a tamburului, spre cei curajoși sau supercomputing, în special cele ale lui Seymour Cray, unde lucrurile ca planurile de traversă a devenit un lucru. În loc să aveți doar o rută pentru a muta datele pe planul de fundal sau pe placa de bază, așa cum se numește în aceste zile. Și memoria inline, știți, în aceste zile oamenii nu se gândesc cu adevărat la ce înseamnă de fapt atunci când spun DIMM și SIMM. Dar, SIMM este o singură memorie inline, iar DIMM este o memorie dublă inline și avem mai complexe decât asta și există zeci de tipuri de memorie diferite pentru diferite lucruri: unele pentru video, altele pentru aplicații generale, altele încorporate în procesoare.
Deci, a existat această schimbare mare către un mod nou de stocare și accesare a datelor. Suntem pe cale să trecem prin aceeași schimbare într-o altă generație întreagă, dar nu atât în hardware-ul în sine, ci în adoptarea hardware-ului în logica de afaceri și în stratul de logică de date și este o altă schimbare de paradigmă mare în mintea mea .
Dar doar pe scurt despre cum am ajuns aici. Adică, tehnologia hardware s-a îmbunătățit și s-a îmbunătățit dramatic. Am plecat de la a avea procesoare și ideea unui nucleu a fost un concept destul de modern. Considerăm acum că telefoanele noastre au două sau patru nuclee, iar computerele noastre au două sau patru, sau chiar opt, nuclee pe desktop și opt și 12 și mai mult, știți, 16 și 32 chiar și pe platforma serverului . Dar este de fapt un lucru destul de modern, că nucleele au devenit o capacitate în interiorul procesoarelor și că am trecut de la 32 de biți la 64 de biți. Câteva lucruri mari s-au întâmplat acolo: am obținut viteze mai mari de ceas pe mai multe nuclee, astfel încât să putem face lucrurile în paralel și fiecare dintre aceste nuclee ar putea rula mai multe fire. Dintr-odată am putea rula multe lucruri pe aceleași date în același timp. Distanța de șaizeci și patru de biți ne-a oferit până la două terabyți de RAM, ceea ce este un concept fenomenal, dar acum este un lucru. Aceste arhitecturi de planuri de fundal multiple, știți, plăci de bază, odată, puteți face lucrurile doar într-o singură direcție: înapoi și înainte. Și la fel ca zilele cu calcularea Cray și unele dintre design-urile de supercomputere din acea vreme, iar acum în computere desktop și comune off-the-raft, un fel de PC-uri de tip desktop, de tip desktop, pentru că într-adevăr, majoritatea modernelor PC-urile au trecut acum prin această eră de mainframe, midrange, micro-desktop-uri și le-am transformat în servere.
Și o mare parte din această capacitate de supercomputer, acel design de calitate supercomputer, a fost împins în componente comune în afara raftului. Știți, în aceste zile, ideea de a lua PC-uri foarte ieftine de montare pe rack și de a le introduce în rafturi de sute, dacă nu chiar de mii, și de a folosi software open-source pe ele, cum ar fi Linux și de a implementa pe SAP HANA pe el, știu, de multe ori ne luăm asta de la sine. Dar acesta este un lucru foarte interesant și vine cu complexitățile sale.
De asemenea, software-ul s-a îmbunătățit, în special gestionarea memoriei și partajarea datelor. Nu voi intra într-o mulțime de detalii despre asta, dar dacă te uiți la schimbarea mare din ultimii 15 ani sau chiar mai puțin, cum este gestionată memoria, în special datele din memoria RAM și modul în care datele sunt partiționate în memoria RAM, astfel încât, așa cum a indicat dr. Robin Bloor mai devreme sau a făcut aluzie, știți, lucrurile pot citi și scrie în același timp, fără a se afecta reciproc, decât să aibă timp de așteptare. O mulțime de caracteristici foarte puternice precum compresia și criptarea pe chip. Criptarea devine un lucru mai important și nu trebuie să facem asta neapărat în software, în RAM, în spațiul CPU, acum asta se întâmplă de fapt pe cip nativ. Aceasta grăbește lucrurile dramatic. Și stocarea și prelucrarea datelor distribuite, din nou, lucruri pe care le-am asumat cândva erau chestii de supercomputere și prelucrare paralelă, acum le asumăm în mod sigur în spațiul de genul SAP HANA și Hadoop și Spark, etc.
Așadar, în întregime, este această calculare de înaltă performanță, capabilitățile HPC au venit la întreprindere și acum întreprinderea se bucură de avantajele care vin cu asta în câștiguri de performanță și tehnologie, beneficii tehnice și câștiguri comerciale, pentru că, știți, timpul redus de valoare este scăzut dramatic.
Dar folosesc această imagine a unei povești pe care am citit-o cu ceva timp în urmă a unui domn care a construit un caz de calculator din Lego, pentru că îmi vine mereu în minte când mă gândesc la unele dintre aceste lucruri. Și asta este, pare o idee grozavă în momentul în care începi să-l construiești, apoi îți dai jumătate de drum și îți dai seama că de fapt este foarte complicat să pui toate bucățile Lego și să faci un lucru solid, suficient de solid pentru a pune o placă de bază și așa mai departe, asta va construi un caz pentru un computer personal. Și, în cele din urmă, îți dai seama că toate bucățile mici nu se lipesc bine și trebuie să fii puțin atent la ce bucăți le lipsești pentru a le face solid. Și este o idee foarte drăguță, dar este un apel de trezire când treci la jumătatea drumului și îți dai seama: „Hmm, poate că ar fi trebuit să cumpăr un caz de 300 USD pentru PC, dar îl voi termina acum și voi învăța ceva de la el.”
Pentru mine este o analogie excelentă pentru cum este să construiești aceste platforme foarte complexe, pentru că este bine și bine să o construiești și să termini cu un mediu în care ai routere, switch-uri și servere și racks. Și aveți procesoare, RAM și sistem de operare grupate împreună. Și puneți ceva de genul HANA pe deasupra pentru procesarea distribuită în memorie și stocarea datelor și gestionarea datelor. Vă construiți stiva SAP pe deasupra, obțineți funcțiile bazei de date, apoi încărcați datele și logica de afaceri și începeți să aplicați unele citiri, scrieri și întrebări și așa mai departe. Trebuie să țineți cont de I / O și trebuie să programați lucrurile și să gestionați sarcinile de muncă și multitenancy și așa mai departe. Această stivă devine foarte complexă, foarte repede. Aceasta este o stivă complexă în sine, dacă este doar pe o singură mașină. Înmulțiți-l cu 16 sau 32 de mașini, devine foarte, foarte netivar. Când înmulțiți până la sute și, eventual, mii de mașini, pentru a trece de la 100 de terabyți la scara petabyte, este un concept înfricoșător și acestea sunt realitățile cu care avem de-a face acum.
Așadar, veți termina cu câteva lucruri care au ajutat și la schimbarea acestei lumi și că spațiul pe disc a devenit ridicol de ieftin. Știi, din când în când, ar fi cheltuit între 380 și 400 de mii de dolari pe un gigabyte de hard disk atunci când era un tambur masiv de dimensiunea unui - ceva care avea nevoie de stivuitor pentru a-l ridica. În aceste zile este vorba de un fel de unu sau doi centi pe gigabyte de spațiu pe disc. Și RAM a făcut același lucru. Aceste două curbe J în ambele grafice, apropo, sunt câte un deceniu, așa că, cu alte cuvinte, ne uităm la două blocuri de 10 ani, 20 de ani de reducere a prețurilor. Dar le-am rupt în două curburi J, deoarece în cele din urmă, cea din dreapta a devenit o linie punctată și nu puteți vedea detaliile, așa că am redimensionat-o. Un gigabyte de RAM în urmă cu 20 de ani era ceva de ordinul a șase milioane și jumătate de dolari. În aceste zile, dacă plătiți mai mult de trei sau patru dolari pentru un gigabyte de RAM pentru hardware-ul de marfă vi se fură.
Această scădere semnificativă a reducerii prețurilor în ultimele două decenii a făcut ca acum să putem trece dincolo de spațiul discului și să ne îndreptăm direct în memoria RAM, nu doar la nivelul de megabyte, ci acum la nivel de terabyte și să tratăm memoria RAM cum ar fi discul. Totuși, provocarea a fost aceea că RAM-ul era în mod efemer în mod nativ - ceea ce înseamnă ceva care durează o perioadă scurtă de timp - deci, a trebuit să găsim modalități de a asigura rezistența în spațiul respectiv.
Așadar, ideea mea este că calcularea în memorie nu este pentru cei cu inima slabă. Jonglarea acestei date la scară foarte mare în memorie și procesarea din jurul acesteia reprezintă o provocare interesantă; așa cum am indicat mai devreme, nu este pentru inima slabă. Deci, un lucru pe care l-am învățat din această experiență cu calcularea în memorie la scară largă și mare densitate este că complexitatea pe care o construim debutează riscă într-o serie de domenii.
Dar să ne uităm doar la un punct de vedere de monitorizare și răspuns. Când ne gândim la date, acestea încep în spațiu pe disc, se așează în baze de date în discuri, îl împingem în memorie. Odată ce este în memorie și distribuit și există copii ale acesteia, putem utiliza o mulțime de copii ale acesteia, iar dacă se aduc modificări, aceasta poate fi reflectată la nivel de memorie, în loc să trebuiască să meargă și să o oprească și pe planul de fundal la pe două niveluri diferite, intră și iese din memorie. Am terminat cu această platformă hardware de scară largă care ne permite să facem acest lucru acum. Când vorbim despre hiperscaling, este mai greu la niveluri ridicol de dense și de memorie cu densitate foarte mare, număr foarte mare de CPU și nuclee și thread-uri. Acum avem patologii de rețea extrem de complexe pentru a susține acest lucru, deoarece datele trebuie să se deplaseze prin intermediul rețelei la un moment dat, dacă va merge între noduri și clustere.
Deci, terminăm cu redundanța defectelor dispozitivului devenind o problemă și trebuie să monitorizăm dispozitivele și piesele acestuia. Trebuie să avem încorporată redundanța erorilor de date rezistente în acea platformă și să o monitorizăm. Trebuie să avem reziliența bazei de date distribuite încorporată, astfel încât trebuie să monitorizăm platforma bazei de date și să stivăm în interiorul acesteia. Trebuie să monitorizăm programarea distribuită a procesării, ce se întâmplă în unele procese până la interogare și interogare, precum și calea pe care o ia interogarea și modul în care este structurată și executată interogarea. Cum arată, a făcut cineva SELECT * pe „blah” sau au făcut de fapt o interogare foarte inteligentă și bine structurată, care să le obțină cantitatea minimă de date nominală care vine în arhitectura din planul de fundal? Avem sarcini de muncă multitenancy, mai mulți utilizatori și mai multe grupuri care rulează aceleași sau mai multe sarcini de lucru și joburi de lot și programare în timp real. Și avem această combinație de procesare în serie și în timp real. Unele lucruri rulează regulat - pe oră, zilnic, săptămânal sau lunar - alte lucruri sunt la cerere. Cineva poate sta acolo cu o tabletă care dorește să facă un raport în timp real.
Și din nou, ajungem în acest punct, că complexitatea care apare în aceste aspecte nu este doar o provocare acum, ci este destul de înspăimântătoare. Și avem această verificare a realității că o singură problemă de performanță, o singură problemă de performanță în sine, poate afecta întregul ecosistem. Și deci, terminăm cu această provocare foarte distractivă de a afla, bine, unde sunt impacturile? Și avem această provocare, suntem reactivi sau proactivi? Urmărim lucrul în timp real și vedem că ceva merge „de-a dreptul” și le răspundem? Sau am văzut o formă de tendință și ne-am dat seama că trebuie să ne implicăm în mod proactiv? Pentru că cheia este că toată lumea își dorește ceva rapid și ieftin și ușor. Dar sfârșim cu aceste scenarii, la care îmi place să mă refer și la linia mea preferată a conundrumului Donald Rumsfeld - care în mintea mea se aplică în toate aceste scenarii de complexitate ridicată - și asta este, am cunoscut cunoștințe pentru că este ceva am proiectat și construit și funcționează conform planificării. Am cunoscut necunoscute în care nu știm cine rulează ce, când și unde, dacă este la cerere. Și avem necunoscute necunoscute și acestea sunt lucrurile pe care trebuie să le monitorizăm și să le verificăm. Pentru că realitatea este, știm cu toții, că nu poți gestiona ceva ce nu poți măsura.
Deci, pentru a avea instrumentele potrivite și capabilitatea potrivită de a monitoriza programarea procesorului nostru, căutați timpii de așteptare, aflați de ce lucrurile trebuie să aștepte în cozile de program în conducte. Ce se întâmplă în memorie, ce fel de utilizare este efectuată, ce fel de performanță scoatem din memorie? Se distribuie corect lucrurile, se distribuie, avem suficiente noduri care conțin copii ale acestuia pentru a face față sarcinilor de lucru care sunt aruncate la acesta? Ce se întâmplă cu executarea procesului departe de procesele sistemului de operare? Locurile de muncă care funcționează, aplicațiile individuale și demoni care le susțin? Ce se întâmplă în cadrul acestor procese, în special structurarea interogărilor și cum sunt executate și compilate acele interogări? Și sănătatea acestor procese până la capăt? Știi, din nou, timpii de așteptare, este o programare corectă, trebuie să aștepți, unde așteaptă, așteaptă citirea memoriei, I / O, procesorul, I / O în rețea către utilizatorul final ?
Și apoi înapoi la acel punct pe care l-am menționat chiar repede înainte de a mă încheia și acesta este, cum abordăm timpii de soluționare a problemelor și de răspuns la acestea? Ne uităm în timp real și reacționăm la lucruri, care este cel mai puțin scenariu ideal, dar chiar și atunci, este mai bine să facem asta decât să nu știm și să apelăm la biroul de ajutor și să spunem că ceva a mers prost și trebuie să-l urmărim ? Sau o facem în mod proactiv și ne uităm la ce vine în linie? Deci, cu alte cuvinte, vedem că ne lipsește de memorie și trebuie să adăugăm mai multe noduri? Facem analiză de tendințe, facem planificarea capacității? Și în toate acestea, monitorizăm timpii de execuție istorici și ne gândim la planificarea capacității sau o urmărim în timp real și reprogramăm proactiv și facem echilibru de sarcină? Și suntem conștienți de volumul de muncă care se execută în primul rând? Știm cine face ce face în clusterul nostru și de ce?
Calculele din memorie sunt foarte puternice, dar cu această putere este aproape unul dintre aceste lucruri, cum ar fi, un pistol încărcat și te joci cu muniție live. În cele din urmă, poți să te tragi în picior dacă nu ești atent. Deci, această putere de calcul în memorie înseamnă doar că putem rula mult mai rapid și rapid pe seturi de date foarte distribuite și discrete. Dar atunci, atunci o cerere mai mare este condusă de la utilizatorii finali. Se obișnuiesc cu acea putere și vor. Nu se mai așteaptă ca locurile de muncă să dureze săptămâni și rapoartele să apară pe o hârtie simplă. Și apoi, sub toate acestea, avem întreținerea de zi cu zi încercuită în jurul patch-urilor, actualizărilor și actualizărilor. Și dacă vă gândiți la procesarea 24/7 cu calcul in-memory, la gestionarea datelor respective, la gestionarea sarcinilor de lucru peste ea, totul este în memorie, tehnic în platformă efemeră, dacă vom începe să aplicăm patch-uri și actualizări și actualizări în acolo vine și cu o serie întreagă de provocări de management și monitorizare. Trebuie să știm ce putem lua offline, când îl putem actualiza și când îl vom readuce online. Și asta mă aduce la punctul meu final și, adică, pe măsură ce obținem din ce în ce mai multă complexitate în aceste sisteme, nu este un lucru pe care un om îl poate face doar sugându-și degetul mare și trăgându-și urechea. Nu mai există niciun fel de abordări ale sentimentelor intestinale. Avem într-adevăr nevoie de instrumentele adecvate pentru a gestiona și oferi acest nivel ridicat de performanță în domeniul calculului și al gestionării datelor.
Și cu asta în minte, voi înmâna prietenului nostru de la IDERA și voi auzi cum au abordat această provocare.
Bill Ellis: Mulțumesc foarte mult. Îmi împărtășesc ecranul și aici mergem. Așadar, este cu adevărat umilitor să luăm în considerare doar toată tehnologia și toți oamenii care au venit înaintea noastră, pentru a face aceste lucruri disponibile în 2017, disponibile. Vom vorbi despre analiza volumului de muncă pentru SAP HANA - practic, o soluție de monitorizare a bazelor de date: cuprinzătoare, fără agent, furnizează în timp real și creează un istoric și astfel puteți vedea ce s-a întâmplat în trecut. SAP S / 4 HANA oferă potențialul mai bun, mai rapid și mai ieftin. Nu spun că este ieftin, ci spun doar că este mai puțin costisitor. În mod tradițional, ceea ce s-a întâmplat a fost că veți avea o instanță de producție principală - probabil rulând pe Oracle într-un magazin mai mare, potențial SQL Server - și apoi veți folosi acel proces ETL și veți avea mai multe versiuni, de tipul adevărului. . Și acest lucru este foarte scump deoarece plăteai pentru hardware, sistem de operare, licență Oracle pentru fiecare dintre aceste medii individuale. Și pe deasupra, va trebui să aveți oameni care să împace o versiune a adevărului cu următoarea versiune a adevărului. Și deci, această procesare ETL cu versiuni multiple a fost doar lentă și foarte, foarte greoaie.
Și astfel, HANA, practic o instanță HANA, poate înlocui toate aceste alte instanțe. Deci, este mai puțin costisitor pentru că este o platformă hardware, un sistem de operare, în loc de multipli. Și deci, HANA S / 4, într-adevăr, schimbă totul și, practic, te uiți la evoluția SAP de la R / 2 la R / 3, diversele pachete de îmbunătățiri. Acum, sistemul moștenitor este disponibil până în 2025, deci aveți opt ani până când sunteți într-adevăr obligat să migrați. Deși vedem oameni, știți, împletindu-și degetele de la picioare pentru că știu că vine și, în cele din urmă, știți, ECC va funcționa pe HANA și deci ar trebui să fiți cu adevărat pregătiți pentru asta și să înțelegeți tehnologia.
Deci, o singură bază de date, nici un proces ETL, nici o copie care trebuie reconciliată. Deci, încă o dată, mai rapid, mai bine și mai ieftin. HANA este în memorie. SAP furnizează software-ul, furnizați hardware-ul. Nu există tabele agregate. Unul dintre lucrurile pe care ei le sugerează atunci când te gândești la asta este că nu vrei să intri în asta, doar vom cumpăra cel mai mare server disponibil. Acestea sugerează că dvs., cu o dimensiune potrivită, peisajul SAP înainte de timp și, în principiu, spun că nu migrați date de 20 de ani. Consider că arhivarea este ceva subutilizat în IT, cam așa, în toate bordurile, nu doar în magazinele SAP. Și deci, următorul lucru este că SAP a petrecut de fapt mult timp rescrierea codului lor natal pentru a nu utiliza SELECT *. SELECT * returnează toate coloanele din tabel și este deosebit de scump într-o bază de date columnar. Și deci, nu este o idee bună pentru SAP HANA. Deci, pentru magazinele care au o mulțime de personalizare, o mulțime de rapoarte, acesta este un lucru pe care doriți să îl căutați și veți dori să specificați numele coloanelor pe măsură ce progresați pentru a migra totul la HANA.
Ne place să spunem că HANA nu este un panaceu. La fel ca toate bazele de date, toate tehnologiile, trebuie monitorizat și, așa cum am menționat anterior, aveți nevoie de numere pentru a gestiona excesul, măsurarea prin măsurare. Și unul dintre lucrurile despre care vorbesc în zona IDERA este că fiecare tranzacție de afaceri interacționează cu sistemul de înregistrare și, în acest caz, va fi HANA. Și astfel, HANA devine fundamentul pentru efectuarea tranzacțiilor SAP, experiența utilizatorului final. Și deci, este vital să fie continuat să funcționeze cu viteză maximă. Devine un singur punct de eșec, iar în a vorbi cu oamenii, acesta este un lucru care poate decoperi acolo unde ai un utilizator final și poate folosește aceste date în timp real și au o interogare ad-hoc care, probabil, nu este destul dreapta. Poate că nu se alătură tabelelor și au creat o aderare exterioară, un produs partizan și, practic, consumă o mulțime de resurse. Acum, HANA va recunoaște că până la urmă și va ucide acea sesiune. Și, deci, este partea crucială a arhitecturii noastre care vă va permite să surprindeți de fapt asta în istorie, astfel încât să puteți vedea ce s-a întâmplat în trecut și să recunoașteți acele situații.
Deci, să aruncăm o privire la analiza volumului de muncă pentru SAP HANA. Aceasta este versiunea 1, așa că vă invităm foarte mult să vă alăturați în călătorie, iar acesta este un produs de la IDERA. Este cuprinzător, dar simplu. Timp real cu trend. Sănătate gazdă, sănătate de exemplu. Urmărim stările de așteptare, interogările SQL, consumatorii de memorie și serviciile. Așa, arată aspectul GUI și puteți vedea chiar de pe bât că este activat web. Am deschis de fapt această soluție care rulează live pe sistemul meu. Sunt câteva lucruri cruciale pe care vrei să le arunci o privire. Ne-am împărțit într-un fel de spații de lucru diferite. Unul dintre cele mai cruciale este ceea ce se întâmplă la nivel de gazdă dintr-o utilizare a procesorului și utilizarea memoriei. Cu siguranță nu doriți să ajungeți la un punct de schimb schimbător sau zguduitor. Și apoi, practic, vă descurcați în ceea ce se întâmplă în trend, din timpul de răspuns, utilizatori, declarații SQL, adică ceea ce conduce activitatea pe sistem.
Unul dintre lucrurile cu IDERA este că, știți, nu se întâmplă nimic într-o bază de date până când nu există activitate. Iar acea activitate sunt declarații SQL care provin din aplicație. Deci, măsurarea declarațiilor SQL este absolut vitală pentru a putea detecta cauza rădăcină. Deci, haideți să mergem mai departe și să perfecționați. Deci, la nivel de gazdă, putem efectua o privire asupra memoriei, urmărirea timpului, utilizarea procesorului gazdă. Pas înapoi, puteți privi instrucțiunile COBSQL. Acum, unul dintre lucrurile pe care le veți vedea în latura noastră de arhitectură este că aceste informații sunt stocate în HANA, așa că, dacă s-ar întâmpla ceva cu HANA, în realitate captăm informații până la, Doamne ferește, o situație indisponibilă . De asemenea, putem captura tot ceea ce se întâmplă pe sistem, astfel încât să aveți vizibilitate clară. Și unul dintre lucrurile pe care le vom face este să prezentăm instrucțiunile SQL în ordine ponderată. Deci, asta va ține cont de numărul de execuții, deci este consumul de resurse agregat.
Și, astfel, puteți intra în valori individuale aici - când s-a executat acea instrucțiune SQL? Și atunci consumul de resurse este determinat în mare parte de planul de execuție, astfel încât să putem capta asta în mod continuu. HANA este în memorie. Este extrem de paralel. Are indici primari pe fiecare tabel, pe care unele magazine aleg să creeze un index secundar pentru a rezolva anumite probleme de performanță. Și deci, un fel de a ști ce s-a întâmplat cu planul de execuție pentru anumite instrucțiuni SQL poate fi foarte valoros. De asemenea, vom analiza serviciile, consumul de memorie încă o dată, graficat în timp. Arhitectura: deci, aceasta este o soluție de sine stătătoare pe care o puteți descărca de pe site-ul nostru web, iar arhitectura este că este activată pe web.
Puteți avea mai mulți utilizatori conectați la o anumită instanță. Puteți monitoriza instanțele locale ale SAP HANA. Și păstrăm o istorie continuă de patru săptămâni în depozitul nostru și asta este autogestionat. Pentru a implementa acest lucru, este destul de simplu. Ai nevoie de un server Windows. Trebuie să îl descărcați. Majoritatea serverelor Windows vor avea un cadru .NET încorporat și vine livrat cu o licență. Așadar, ați merge la asistentul de instalare, care este condus de Setup.exe și ar deschide de fapt un ecran, un acord de licență și pur și simplu ați crea acest contur făcând clic pe „Următorul”. Și deci, unde doriți să HANA fi instalat? Următoarea este proprietățile bazei de date și aceasta va fi conexiunea dvs. la SAP HANA, deci aceasta este monitorizarea fără agent a instanței HANA. Și atunci, practic, vom oferi o previzualizare, acesta este portul pe care îl comunicăm implicit. Faceți clic pe „Instalare” și, practic, pornește HANA și începeți să construiți istoricul. Așadar, doar un pic din informațiile despre grafic. Putem monitoriza până la 45 de instanțe HANA și veți dori să folosiți acest lucru pe o scară glisantă pentru a determina numărul de nuclee, memorie, spațiu pe disc de care veți avea nevoie. Și acest lucru presupune că aveți o istorie completă de patru săptămâni în curs.
Deci, doar ca o recapitulare rapidă, ne uităm la sănătatea serverului, sănătatea instanțelor, utilizarea procesorului / memoriei. Care sunt consumatorii de memorie, care sunt driverele de activitate, care sunt serviciile? Instrucțiunile SQL sunt vitale - care sunt stările de execuție? Arată-mi planurile de execuție, când au fost executate lucrurile, care oferă trending? Acest lucru vă va oferi în timp real și o istorie a ceea ce s-a întâmplat. Și după cum am menționat, deoarece istoria noastră este separată de HANA, vom surprinde chestii care au scurs din timp și care fuseseră șterse din istoria HANA. Pentru a putea vedea consumul adevărat de resurse pe sistemul dvs. din cauza istoricului separat.
Deci, așa cum am menționat, site-ul IDERA, sub Produse, puteți găsi cu ușurință acest lucru. Dacă doriți să încercați acest lucru, cu siguranță sunteți bineveniți. Vedeți cum vă oferă informații pentru dvs. și există informații suplimentare pe site-ul respectiv. Deci, orice părți interesate sunt mai mult decât fericite să participe la asta. Acum, în portofoliul de produse oferit de IDERA, există și un monitor de tranzacții SAP ECC, iar acesta se numește Precis pentru SAP. Și ceea ce face este - indiferent dacă utilizați portal sau doar ECC simplificat - va capta efectiv tranzacția utilizatorului final de la clic pe disc, până la declarația SQL și vă va arăta ce se întâmplă.
Acum, vă arăt un singur ecran sumar. Vă doresc să aveți câteva din acest ecran sumar. Este timpul de răspuns al axei Y, ora axei X plus ziua, iar în această vizualizare a tranzacției vă vom arăta ora clientului, ora de așteptare, ora codului ABAP, ora bazei de date. Putem capta ID-uri de utilizator final, coduri T și puteți filtra și arăta de fapt serverele printr-o anumită tranzacție traversată. Și astfel, multe magazine rulează partea frontală a peisajului sub VMware, astfel încât să puteți măsura efectiv ce se întâmplă pe fiecare dintre servere și să intrați într-o analiză foarte detaliată. Deci, această vizualizare a tranzacției este pentru tranzacția utilizatorului final prin întregul peisaj SAP. Și puteți găsi că pe site-ul nostru de la Produse APM Tools și aceasta ar fi soluția SAP pe care o avem. Instalarea pentru aceasta este puțin mai complicată, deci nu este doar să o descarci și să o încerci, așa cum avem pentru HANA. Acesta este un lucru în care am lucra împreună pentru a face, proiecta și implementa tranzacția generală pentru dvs.
Deci, doar oa treia recapitulare rapidă, analiza volumului de muncă pentru SAP HANA, este completă, fără agent, în timp real, oferă un istoric. Oferim posibilitatea de a descărca și de a încerca site-ul dvs.
Deci, cu asta, voi trece timpul înapoi lui Eric, Dez și Dr. Bloor.
Eric Kavanagh: Da, poate Robin, ai întrebări de la tine și apoi Dez după Robin?
Dr. Robin Bloor: Bine. Adică, primul lucru pe care aș dori să-l spun este că îmi place foarte mult vizualizarea tranzacțiilor, deoarece este exact ceea ce mi-aș dori în această situație. Am făcut multă muncă - ei bine, este acum mult timp în acest moment - făcând monitorizare a performanței și asta a fost un lucru; nu am avut grafică în acele zile, dar acesta a fost genul de lucruri pe care mi-am dorit în mod special să le pot face. Pentru a putea, într-un fel sau altul, să vă injectați oriunde se întâmplă problema.
Prima întrebare pe care o am este, știți, majoritatea oamenilor implementează S / 4 într-un fel sau altul din cutie, știți. Când v-ați implicat în orice implementare dată de S / 4, ați descoperit că a fost implementat bine sau dacă ajungeți, știți, descoperind lucruri care ar putea face clientul să dorească reconfigurarea? Adică, cum merg toate astea?
Bill Ellis: Ei bine, fiecare magazin este puțin diferit. Și există diferite modele de utilizare, există rapoarte diferite. Pentru site-urile care au raportări ad-hoc, vreau să spun că este de fapt un wildcard din sistem. Și deci, unul dintre lucrurile cruciale este să începeți măsurarea și să aflați care este valoarea de bază, ce este normal pentru un anumit site, unde este acel anumit site, bazat pe modelele lor de utilizare, subliniind sistemul. Și apoi faceți ajustări de acolo. În mod obișnuit, optimizarea monitorizării nu este o singură dată, ci este într-adevăr o practică continuă în care monitorizezi, reglezi, descoperiți, îmbunătățind sistemul pentru ca comunitatea utilizatorilor finali să poată servi mai eficient afacerea.
Dr. Robin Bloor: Bine, atunci când implementați - adică, știu că aceasta este o întrebare dificilă de răspuns, deoarece va varia în funcție de dimensiunea implementării - dar cât de multă resursă are capacitatea de monitorizare IDERA, cât de mult consumă ? Face vreo diferență în ceva sau este, doar nu interferă? Cum funcționează?
Bill Ellis: Da, aș spune că cheltuielile generale sunt de aproximativ 1-3 la sută. Multe magazine sunt foarte dispuse să sacrifică asta, deoarece, în mod potențial, veți putea cumpăra asta în termeni de optimizare. Depinde de tiparele de utilizare. Dacă faceți un peisaj complet, acesta depinde de tehnologiile individuale care sunt monitorizate. Deci, un fel de kilometri variază, dar, așa cum am vorbit, este cu siguranță mai bine să cheltuiți un pic pentru a ști ce se întâmplă, decât să fugiți orbi. În mod special, ar fi, în ianuarie, ne aflăm în procesarea anilor și acumulezi date în valoare de 12 luni. Știi, asta face performanță, comunicarea rapoartelor către organizații de reglementare, bănci, către acționari, este absolut vitală pentru o performanță critică a afacerii.
Dr. Robin Bloor: Corect. Și doar rapid, din perspectiva ta - pentru că presupun că ești implicat acolo cu o serie întreagă de site-uri SAP - cât de mare este mișcarea între baza de clienți SAP către S / 4? Vreau să spun, este un lucru care este, știi, că există un fel de avalanșă de clienți entuziaști care merg pentru asta sau este doar un truc constant? Cum vezi asta?
Bill Ellis: Cred că acum câțiva ani, aș spune că a fost un deget de la picior. Acum aș spune că oamenii sunt cam generoși până la genunchi. Cred că, în timp ce oamenii vor fi cufundați în HANA în următorii doi ani. Și deci monitorizarea, transformarea, știți, cred că majoritatea clienților sunt, într-un fel, pe curba de învățare împreună. Și deci cred că nu suntem la avalanșă așa cum ați spus, dar cred că suntem pe cuspul transformării majore în HANA.
Dr. Robin Bloor: Bine, așa că, în ceea ce privește site-urile pe care le-ați văzut care s-au prezentat în acest sens, sunt și ele care adaptează HANA pentru alte aplicații sau sunt, într-un fel sau altul, un fel complet de consumat pentru a face acest lucru lucrurile merg? Care este poza acolo?
Bill Ellis: Da, de multe ori oamenii vor integra SAP cu alte sisteme, în funcție de modulele și așa mai departe, deci există un pic. Nu văd cu adevărat oamenii care implementează alte aplicații pe HANA încă. Cu siguranță este posibil să faci. Și deci este mai mult peisajul din jurul infrastructurii SAP.
Dr. Robin Bloor: Presupun că ar fi mai bine să vă predau lui Dez. V-am îmbrăcat timpul. Dez?
Dez Blanchfield: Mulțumesc. Nu, asta e bine. Două foarte rapide, doar pentru a încerca să stabilesc tema. SAP HANA a ieșit de câțiva ani și oamenii au avut șansa să o ia în considerare. Dacă ar fi să ne oferiți o estimare aproximativă a procentului de oameni care îl rulează - pentru că există o mulțime de oameni care rulează aceste lucruri - ceea ce credeți că procentul de piață de care sunteți conștient este în prezent. de la implementări SAP tradiționale la SAP pe HANA? Ne uităm la 50/50, 30/70? Care este, ce fel de procent din piață, vedeți oameni care au făcut tranziția și au făcut mutarea acum față de oamenii care doar stau înapoi și așteaptă ca lucrurile să se îmbunătățească sau să se îmbunătățească sau să se schimbe sau indiferent de caz?
Bill Ellis: Da, aș pune, din perspectiva mea, aș pune procentul în jur de 20 la sută. SAP tinde să fie afaceri tradiționale. Oamenii tind să fie foarte conservatori și astfel oamenii lor își vor trage picioarele. Cred că depinde și de dvs., știți, ați derulat SAP de mult timp sau sunteți un fel de SMB care poate avea SAP mai recent implementat? Și deci, există o serie de factori, dar în general nu cred că procentul este de 50/50. Aș spune că 50 la sută sunt cel puțin obositori și au HANA care rulează undeva în centrul lor de date.
Dez Blanchfield: Interesantă preluare pe care ne-ați dat-o mai devreme a fost că acesta este un fapt completat într-un sens și că ceasul bifează fizic și literalmente momentul trecerii. În procesul de a face acest lucru, credeți că oamenii au considerat asta? Care este sensul general al înțelegerii populare că aceasta este o schimbare tranzitorie a platformei, nu este doar o opțiune, ci devine implicit?
Și, din punctul de vedere al SAP, sunt sigur că aceștia apasă astfel, deoarece există un avantaj competitiv semnificativ în ceea ce privește performanța, dar este, de asemenea, cred, ei combate controlul platformei în loc să treacă la o a treia … baza de date pentru petreceri, acum o readuc la propria platformă. Crezi că companiile au primit de fapt acel mesaj? Crezi că oamenii înțeleg asta și acum se orientează spre asta? Sau este încă un fel de neclar, credeți, pe piață?
Bill Ellis: Nu cred că SAP este timid în ceea ce privește comunicarea, iar oamenii care au plecat la SAPPHIRE au văzut HANA peste tot. Deci, cred că oamenii sunt bine conștienți, dar natura umană este ceea ce este, știți, unii oameni sunt, cam dragul, târându-și puțin picioarele.
Dez Blanchfield: Pentru că cred că motivul pentru care am pus această întrebare și va trebui să mă iertați, dar este că sunt de acord. Cred că nu au fost timizi în comunicarea ei. Cred că semnalul a ieșit în mai multe feluri. Și sunt de acord cu tine - nu știu că toată lumea a sărit încă. Știi, întreprinderea tradițională, întreprinderile foarte mari care se ocupă de acest lucru, sunt încă în multe feluri, nu destul de târâți picioarele, ci doar încearcă să înțeleagă cu complexitatea schimbării. Deoarece cred că unicul lucru pe care instrumentul dvs. și, cu siguranță, demonstrația dvs. de azi l-a evidențiat, iar pentru mine, un singur aspect de preluare-cheie aș dori ca toți cei care ascultă și să acorde azi să se așeze și să acorde atenție reflectorizantului este: instrument care acum a simplificat acest proces în mintea mea. Cred că există o mulțime de CIO-uri foarte nervoase și echipele lor de sub care se gândesc: „Cum fac tranziția de la tradiționalele sisteme de gestionare a bazelor de date tradiționale RDBMS, pe care le știm de zeci de ani, la o paradigmă cu totul nouă de calcul și gestionarea stocării într-un spațiu care este încă relativ curajos? ”în mintea mea. Dar este o necunoscută din multe puncte de vedere, și sunt foarte puțini oameni care au făcut această schimbare în alte domenii, că nu este ca și cum ar avea o altă secțiune de afaceri care a făcut deja o mișcare în calculul din memorie. Deci, este o mișcare totală sau nimic în mintea lor.
Așadar, unul dintre lucrurile pe care le-am îndepărtat mai mult decât orice - o să vă lovesc cu o întrebare într-un minut - este că frica de acum, cred, este calmată în multe feluri și că înainte de astăzi, Dacă asculta un CIO, m-aș gândi, într-un fel, „Păi, cum voi face această tranziție? Cum voi garanta aceeași capacitate pe care am avut-o în platforma relațională de gestionare a bazelor de date și anii de experiență ai DBA-urilor, către o nouă platformă în care nu avem în prezent abilitățile? ”Deci, întrebarea mea despre asta este, credeți că oamenii au înțeles că instrumentele sunt acum cu ceea ce oferiți și că pot respira adânc și suspin de ușurare, că tranziția nu este atât de înfricoșătoare pe cât ar fi fost anterior pentru ca acest instrument să fie disponibil? Credeți că oamenii au înțeles sau este încă un fel de lucru pe care îl înțeleg doar cu trecerea la calculul din memorie și stocarea în memorie versus combinațiile vechi de școală de NVMe, flash și disc?
Bill Ellis: Da, așa că, fără îndoială, există o mulțime de tehnologii și instrumente care pot afișa grafic acest lucru, ceea ce se întâmplă și face foarte ușor să evidențiezi consumatorii de top din resurse. Adică, ajută la simplificarea lucrurilor și ajută personalul tehnologiei să aibă într-adevăr un bun control. Hei, vor putea ști ce se întâmplă și vor putea înțelege toată complexitatea. Deci, absolut, instrumentele de pe piață sunt cu siguranță de ajutor, astfel încât oferim o analiză a volumului de muncă pentru SAP HANA.
Dez Blanchfield: Da, cred că mare lucru despre ceea ce ne-ați arătat astăzi este că, în monitorizarea piesei hardware, a piesei sistemului de operare, chiar și a monitoriza o parte din volumul de muncă care se deplasează, așa cum ați spus, vreau să spun, instrumentele sunt acolo de ceva timp. Un pic pentru mine, mai ales în interiorul like-urilor HANA este că nu am avut neapărat capacitatea de a obține o lupa și de a arunca o privire în ea și de a vedea exact ce face instrumentul dvs. cu ceea ce se întâmplă cu interogările și cum sunt acestea fiind structurată și unde se află această încărcare.
Cu implementările pe care le-ați văzut până acum, având în vedere că sunteți destul de literalmente cel mai autoritar din acest spațiu din platforma dvs. din lume, unele dintre câștigurile rapide pe care le-ați văzut - aveți cunoștințe anecdotice cu care puteți împărtăși noi în jurul unor momente eureka, momentele aha, în care oamenii au desfășurat setul de instrumente IDERA, au descoperit lucruri pe care doar ei nu știau le erau în platformele și performanțele pe care le-au avut. Aveți exemple grozave de anecdotice despre locul în care oamenii tocmai l-au desfășurat, fără să știe cu adevărat ce au avut și dintr-o dată, „Uau, de fapt nu știam că este acolo?”
Bill Ellis: Da, deci o mare limitare a instrumentelor native este aceea că, dacă o interogare neîntreruptă este anulată, aceasta curăță informațiile și deci practic nu aveți istoricul. Prin intermediul stocării istoricului offline, precum o interogare evadată, veți avea un istoric, veți ști ce s-a întâmplat, veți putea vedea planul de execuție și așa mai departe. Și deci, asta vă permite să ajutați comunitatea utilizatorilor finali, practic, să funcționeze mai bine, să scrieți rapoarte mai bine, etc. Și uite așa, istoria este ceva care este foarte drăguț. Și unul dintre lucrurile pe care mi-am propus să le arăt este faptul că puteți privi în timp real până la patru săptămâni și apoi puteți mări cu ușurință orice interval de timp de interes și puteți expune activitatea de conducere de bază. Doar că această vizibilitate este foarte utilă pentru a ști ce gât a apărut.
Dez Blanchfield: Ați menționat că este multi-user, odată ce a fost implementat, și am fost destul de impresionat de faptul că este fără contact și efectiv atingere zero în multe feluri. Este normal ca o singură implementare a instrumentului dvs. să fie apoi disponibilă pentru toată lumea din centrul de operațiuni de rețea din NOC care urmărește infrastructura de bază care stă la baza clusterului până la echipa de dezvoltare și aplicație? Este norma și te implementezi o dată și ar împărtăși asta, sau anticipezi că oamenii ar putea avea instanțe de model care se uită la diferite părți ale stivei? Cum arată asta?
Bill Ellis: Deci, echipa de bază va avea, de obicei, un interes foarte puternic pentru fundamentarea tehnologiei a ceea ce se întâmplă în SAP. Evident, există mai multe echipe care vor susține peisaje întregi. Piesa HANA este doar concentrată pe asta. Voi face implicit o echipă de bază SAP ca principali consumatori de informații.
Dez Blanchfield: Corect. Mă dorește însă că dacă am o echipă de dezvoltare sau nu doar la nivel de cod, dar dacă am o echipă de oameni de știință de date sau analiști care lucrează analitic la seturile de date acolo, în special în condițiile în care există o apăsare semnificativă pentru ca știința datelor să fie aplicată la tot ceea ce se află în organizații acum, în mintea mea - și să mă corecteze dacă greșesc - mi se pare că acest lucru va fi de asemenea un interes deosebit pentru ei, deoarece în multe privințe unul dintre lucrurile serioase pe care le puteți face într-un mediu de depozit de date este să dezlănțuiți un om de știință de date asupra acestuia și să-i permită să înceapă doar să facă interogări ad hoc. Ai avut exemple de astfel de lucruri care se întâmplă în care magazinele te-au cântat și ai spus: „Am aruncat o echipă de știință a datelor la acest lucru, chiar doare, ce putem face pentru ei față de ceea ce facem doar monitorizarea și gestionarea operațională tradițională? ”Este chiar un lucru?
Bill Ellis: Bine, da, aș schimba puțin acest lucru și aș reduce răspunsul meu ar fi că, privind performanța, fiind performant conștient în dezvoltarea producției de QA, știi, cu cât vei comercializa mai devreme, cu atât mai puține probleme, mai puțin surprize ai. Deci, absolut.
Dez Blanchfield: În urma acestui lucru, o mulțime de instrumente cu care am avut experiență - și sunt sigur că Robin va fi de acord - o mulțime de instrumente aici, dacă aveți un RDBMS mare, aveți nevoie de un nivel foarte ridicat - DBA-uri calificate, profund cunoscute și cu experiență. Unele dintre cerințele de infrastructură și platformă care vin cu SAP HANA, deoarece în prezent sunt acceptate pentru distribuții particulare care se aliniază de la un anumit hardware și altele, în conformitate cu cunoștințele mele. Știți, există oameni cu experiență de zeci de ani care nu sunt aceiași. Ceea ce văd, totuși, este că nu este neapărat necesitatea acestui instrument. Mi se pare că puteți să vă implementați instrumentul și să-i dați unor fețe destul de noi și să le oferiți imediat puterea de a găsi lucruri care nu funcționează bine. Este cazul că există o curbă de învățare destul de scurtă pentru a obține viteza cu acest lucru și pentru a obține o anumită valoare din utilizarea acesteia? Știi, sensul meu general este că nu trebuie să ai 20 de ani de experiență în conducerea unui instrument pentru a vedea imediat valoarea. Ați fi de acord că acesta este cazul?
Bill Ellis: Oh, absolut și, după părerea dvs., cred că o mare parte din succesul unei implementări depinde cu adevărat de planificarea și arhitectura mediului SAP HANA. Și atunci există, fără îndoială, multă complexitate, multă tehnologie pe care este construită, dar atunci se reduce doar la monitorizarea tiparelor de utilizare a ceea ce se întâmplă. Deci, deși este mai complex, într-un fel este ambalat și oarecum simplificat. Este foarte sărac.
Dez Blanchfield: Da, deci înainte de a-i da mâna lui Eric, pentru că știu că a primit câteva întrebări, în special din unele care au venit prin Q&A, care mi s-au părut interesante și sunt dornic să aud răspunsul. Călătorie tradițională pentru cineva - ați menționat mai devreme că îl puteți obține, îl puteți descărca și încerca. Puteți doar să recapitați asta rapid pentru ascultarea de folclor astăzi sau pentru folk-uri care ar putea reda mai târziu? Care sunt cei doi sau trei pași rapizi pentru a pune mâna pe o copie și a o implementa și a o încerca în mediile lor înainte de a o cumpăra? Cum arată asta? Care sunt pașii pentru asta?
Bill Ellis: Da. Deci, IDERA.com și pur și simplu accesați Produse și veți vedea Analiza volumului de lucru pentru SAP HANA. Există o pagină de descărcare. Cred că vă vor solicita câteva informații de contact, iar produsul este doar ambalat cu o cheie de licență, astfel încât să îl instalați cu Setup.exe și să faceți doar rularea, cred, foarte repede.
Dez Blanchfield: Deci, pot merge pe site-ul dvs. web, îl pot descărca. Îmi amintesc că m-am uitat cu ceva timp în urmă și am verificat dublu și aseară, poți solicita o memorie, din memorie, unde cineva din echipa ta te va sorta, te va plimba? Dar puteți să îl descărcați gratuit și să îl implementați local în propriul dvs. mediu, în timpul propriu, nu-i așa?
Bill Ellis: Da.
Dez Blanchfield: Excelent. Ei bine, cred că, mai mult decât orice, acesta este probabil lucrul cu care aș sfătui personal să fac, este să preluăm o copie de pe site-ul web, să aduc o parte din documentația de acolo pentru că știu că există o mulțime de conținut bun acolo pentru a face asta, și încearcă-l. Pune-l în mediul tău și vezi ce găsești. Bănuiesc că, odată ce aruncați o privire sub capota cu mediile dvs. SAP HANA cu instrumentul IDERA, veți găsi lucruri despre care de fapt nu știați.
Uite, îți mulțumesc foarte mult pentru asta și mulțumesc pentru timpul doar pentru întrebările de răspuns cu Robin și I. Eric, o să-ți trec înapoi, deoarece știu că și unele întrebări de întrebare au trecut de la participanții noștri.
Eric Kavanagh: Da, doar unul rapid aici. Așadar, unul dintre participanți face un comentariu foarte bun aici vorbind doar despre cum se schimbă lucrurile. Spunând în trecut, memoria s-a sufocat, încetinind prin paginarea frecventă, în prezent CPU se sufocă cu prea multe date din memorie. Știți, există probleme de rețea. Întotdeauna va fi o țintă mișcătoare, nu? Ce vedeți ca traiectorie în aceste zile în ceea ce privește locul în care vor fi blocajele și unde va trebui să vă concentrați atenția?
Bill Ellis: Da. Până la măsurare, este greu de știut. Unul dintre lucrurile despre instrucțiunile SQL este că vor fi driverele consumului de resurse. Și astfel, în situația în care ați avut, cum ar fi, un consum mare de memorie sau un procesor, veți putea să vă dați seama ce activitate a provocat consumul de resurse. Acum, nu ai dori neapărat să-l ucizi, dar vrei să fii conștient și, ce se întâmplă, cât de des se întâmplă, etc. Suntem, într-adevăr, încă noi în ceea ce privește abordarea întregului set sau a cărții de bucate a răspunsurilor în diferite circumstanțe. Și deci, este o întrebare grozavă și timpul va spune. Vom avea mai multe informații pe măsură ce trece timpul.
Eric Kavanagh: Așa este. Ei bine, voi sunteți într-un spațiu foarte interesant. Cred că veți vedea o mulțime de activități în următoarele luni și în următorii doi ani, deoarece știu că SAP, așa cum ați sugerat în apelul nostru de conținut, a oferit un timp îndelungat pentru oameni pentru a face tranziția la HANA. Cu toate acestea, rampa are un final și, la un moment dat, oamenii vor trebui să ia anumite decizii serioase, deci cu atât mai devreme, mai bine?
Bill Ellis: Absolut.
Eric Kavanagh: Bine, oameni, ne-am ars încă o oră aici pe Hot Technologies. Puteți găsi informații online, insideanalysis.com, de asemenea techopedia.com. Concentrați-vă pe acel site pentru o mulțime de informații interesante, inclusiv o listă cu toate arhivele noastre despre aceste transmisiuni web anterioare. Dar oameni buni, o mulțumire mare tuturor celor prezenți acolo, prietenilor noștri de la IDERA, lui Robin și, desigur, Dez. Și ne vom prinde săptămâna viitoare, oameni buni. Mulțumesc din nou pentru timpul acordat și atenție. Ai grijă. Pa! Pa.
