Domov audio Do budúcnosti: rampa pre výpočty v pamäti

Do budúcnosti: rampa pre výpočty v pamäti

Anonim

Od zamestnancov Techopedia, 25. januára 2017

Jedlo so sebou: Host Eric Kavanagh diskutuje s počítačmi v pamäti a SAP HANA s hosťami Dr. Robinom Bloorom, Dezom Blanchfieldom a IDERA's Bill Ellisom.

Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.

Eric Kavanagh: Dobre, dámy a páni. Dobrý deň, ešte raz vitajte. Je to štvrtý východný čas v stredu a posledných pár rokov, čo znamená, že je čas opäť pre Hot Technologies. Áno, skutočne sa volám Eric Kavanagh, budem tvojím hostiteľom pre dnešnú konverzáciu.

A ľudia, dnes sa chystáme hovoriť o nejakých skvelých veciach. Ideme sa ponoriť do sveta in-memory, presný názov je “Do budúcnosti: An-On-Ramp pre In-Memory Computing.” Je to zlosť v dnešnej dobe as dobrým dôvodom, väčšinou kvôli in- pamäť je omnoho rýchlejšia ako spoliehanie sa na rotujúce disky. Výzvou však je, že musíte prepísať veľa softvéru. Pretože dnešný softvér, väčšina z toho, bol napísaný s ohľadom na disk, a ktorý skutočne mení architektúru aplikácie. Ak navrhnete aplikáciu tak, aby čakala na rotujúci disk, robíte veci inak, ako ak máte všetku silu technológie v pamäti.

Je tu skutočne vaše miesto, narazte na mňa na Twitteri, @eric_kavanagh. Vždy sa snažím sledovať to, čo sa týka mňa, a tiež kedykoľvek.

Ako som už povedal, dnes hovoríme o pamäti, konkrétne o SAP HANA. Váš minulý rok ste skutočne strávili poznaním komunity SAP naozaj dobre a musím povedať, že je to fascinujúce prostredie. Klobúky pre ľudí, ktorí spustia túto operáciu a sú v popredí, pretože SAP je neuveriteľne dobrá operácia. To, v čom sú naozaj dobré, je podnikanie. Samozrejme sú tiež vynikajúci v oblasti technológií a do spoločnosti HANA skutočne investovali veľkú investíciu. V skutočnosti si pamätám - asi to bolo asi pred šiestimi alebo siedmimi rokmi -, že sme vlastne robili nejakú prácu pre americké letectvo a že sme dostali niekoho zo spoločnosti SAP, aby prišiel a čoskoro sa na nás pozrel HANA a čo bolo plánované. A prinajmenšom, ľudia v laboratóriách SAP vynaložili veľa času a úsilia na pochopenie toho, ako vybudovať túto architektúru, ktorá je opäť úplne odlišná od tradičných prostredí, pretože máte všetko v pamäti. Hovorí teda o transakčných aj analytických transakciách na rovnakých údajoch v pamäti, na rozdiel od tradičného spôsobu, ktorý ich vytiahne, vloží ich do kocky, napríklad ich tam analyzuje versus transakčné, ktoré sa deje úplne inak.

Toto je zaujímavý priestor a my sa skutočne dozvieme od iného dodávateľa, IDERY, trochu o tom, ako budú všetky tieto veci fungovať a čo je to vlastne povedané, na rampe. Robin Bloor, náš vlastný hlavný analytik, tu v skupine The Bloor Group. Dez Blanchfield, náš vedec údajov a potom dobrý priateľ Bill Ellis z spoločnosti IDERA. Takže s tým dám kľúče Dr. Robinovi Bloorovi, ktorý ich odnesie.

Robin Bloor: Áno, ako Eric hovoril, čas, keď sme sa prvýkrát informovali o SAP HANA, bol už pred mnohými rokmi. Bolo však veľmi zaujímavé, že konkrétny čas bol veľmi zaujímavý. Stretli sme sa v jednej alebo dvoch spoločnostiach, ktoré tak či onak ponúkali technológiu v pamäti. Bolo celkom jasné, že príde in-memory. A naozaj to nebolo, kým sa SAP nevstúpil a náhle nespustil HANA. Myslím, že to bol šok, keď som videl, ako to robí SAP. Bolo to, akoby to bol šok, pretože som očakával, že príde odkiaľkoľvek. Čakal som, že to bude Microsoft, Oracle, IBM alebo niekto iný. Myšlienka, že to SAP robí, bola pre mňa skutočne veľmi prekvapujúca. Myslím, že by to nemalo byť, pretože SAP je jedným zo strategických dodávateľov a do značnej miery, viete, všetko veľké, čo sa v tomto odvetví deje, pochádza od jedného z nich.

Každopádne, celý bod o pamäti, myslím, uvedomili sme si, zvykli sme si o tom hovoriť, že akonáhle skutočne idete do pamäti - nejde o vkladanie údajov do pamäte, ide o zaviazanie sa k myšlienka, že pamäťová vrstva je systémovým záznamom - hneď ako migrujete systémový záznam do pamäte, disk sa stane handoff médiom jedného druhu a stane sa inou vecou. A myslel som si, že to bolo veľmi vzrušujúce, keď sa to začalo diať. Naozaj to je koniec pre rotujúci disk. Spinningový disk bude čoskoro existovať iba v múzeách. Nie som si istý, ako skoro to bude, ale disk SSD je teraz na Mooreovej zákonnej krivke, je už desaťkrát rýchlejší ako rotujúca hrdza, ako to teraz nazývajú, a čoskoro to bude ešte rýchlejšie a potom to znamená, že prípady použitia na disku sú čoraz menej.

A zvedavý fakt, tradičný DBMS, v skutočnosti bolo na pradenie disku postavených veľa tradičného softvéru, predpokladalo to pradenie disku. Mal všetky druhy fyzických úrovní, ktoré boli starostlivo naprogramované, aby sa využil spinning disk a čo najrýchlejšie sa načítalo dáta. A to všetko je odplavené. Len mizneš, vieš? A potom, samozrejme, existovalo veľmi - neviem, lukratívne, predpokladám, že to bude nakoniec - otvorenie databázy v pamäti, ktorá sa pokúsila obsadiť pozíciu veľkých databáz Oracle a Microsoft, SQL Server a IBM DB2, zaberali miesto v pamäti a bolo veľmi zaujímavé sledovať, ako kráčajú vpred a robia to.

Poďme hovoriť o pamäťovej kaskáde; stojí za zmienku. Je to tiež dôvod na to, aby som to spomenul, a dôvod, prečo som to hodil, bol len preto, aby som všetkým dal vedieť, keď hovorím o pamäti, všetky tieto vrstvy, o ktorých hovorím, sú v skutočnosti pamäťou. Zrazu si však uvedomíte, keď sa na to pozriete, je to hierarchický obchod, nie je to len pamäť. Preto platí takmer všetko, čo sme sa dozvedeli dávno a dávno o hierarchickom obchode. A to tiež znamená, že akákoľvek in-memory databáza musí prechádzať týmto spôsobom, niektorí ju jednoducho prechádzajú po RAM, viete. A to sa len zväčšuje, zväčšuje a zväčšuje a teraz sa meria v megabajtoch. Máte však vyrovnávaciu pamäť L1, ktorá je stokrát rýchlejšia ako pamäť, vyrovnávacia pamäť L2 je trikrát rýchlejšia ako pamäť a vyrovnávacia pamäť L3 približne desaťkrát rýchlejšia ako pamäť. Takže viete, existuje veľa technológií - nuž, slušné množstvo technológií - prijalo stratégiu použitia týchto vyrovnávacích pamätí ako druhu úložného priestoru na ceste k vykonaniu vecí, najmä databázovej technológie. Takže, viete, to je jeden vplyv.

Potom vznikli 3D XPoint a IBM PCM. A to je takmer rýchlosť RAM, v podstate to, čo sa títo predajcovia pýšia. Prípady použitia sú pravdepodobne odlišné. Skoré experimentovanie s tým sa ešte musí ukončiť. Nevieme, ako to ovplyvní použitie pamäte RAM a technológie databázy v pamäti. Potom máte RAM verzus SSD. RAM je v súčasnosti asi 300-krát rýchlejšia, ale samozrejme, že viacnásobný počet klesá. A SSD verzus disk, ktorý je asi desaťkrát rýchlejší, ak tomu rozumiem. Takže to je taká situácia, akú máte. Je to hierarchický obchod. Pri pohľade na to iným spôsobom, v pamäti, je samozrejme úplne iný. Horný diagram teda zobrazuje dve aplikácie, z ktorých obidve možno pristupujú k databáze, ale určite pristupujú k údajom o pradení hrdze. A spôsob, akým v skutočnosti prechádzate sieťou, v závislosti od toho, aké závislosti sú v okolí, je ETL. To znamená, že viete, že údaje idú do pradenia hrdze a potom z pradenia odstúpia, aby sa dostali kamkoľvek, a aby sa dostali kamkoľvek, to sa vráti do pradenia hrdze, čo sú tri pohyby. Majte na pamäti, že pamäť môže byť stoktisíckrát rýchlejšia ako rotujúci disk a určite si uvedomujete, že keď vezmete údaje a uložíte ich do pamäte, bude to celé úplne odlišné.

Možno by ste si mysleli, čo by sa stalo, na tom, čo je na obrazovke tu, možno by ste si mysleli, že tak či onak, ETL by v skutočnosti len prešiel z dát na dáta v pamäti. Ale v skutočnosti to nemusí urobiť; v skutočnosti by ste tu mohli mať situáciu, keď dve aplikácie môžu skutočne spustiť rovnakú pamäť. Túto databázu vám určite môže poskytnúť in-memory database, ak máte uzamykanie a všetko ostatné okolo neho organizované. To teda nemení iba rýchlosť vecí, mení to, ako v skutočnosti konfigurujete aplikácie a celé dátové toky.

Je to obrovský vplyv. Takže pamäť je rušivá, však? Mali by sme to získať z toho, čo som povedal. Spracovanie v pamäti v súčasnosti urýchľovač, ale stane sa normou. Bude sa používať, aplikované podľa hodnoty aplikácie, a preto je veľmi, veľmi zaujímavé, že SAP skutočne príde s verziou svojho softvéru ERP, ktorý je v pamäti. Vylepšenia latencie sú možné až o tri rády, a to v skutočnosti ešte viac, ako je to možné. Dostávate sa teda do pamäti obrovské zlepšenie rýchlosti. A výsledok, SAP HANA S / 4 - ktorý vydali, myslím si, že ľudia hovoria, že je stále vydávaný, ale určite bol prepustený minulý rok - je to zmena hry vzhľadom na zákaznícku základňu SAP. Myslím, že tam je 10 000 spoločností, ktoré používajú ERP spoločnosti SAP a do značnej miery sú to všetky veľké spoločnosti. Takže myšlienka, že všetci majú motiváciu ísť do pamäte a využívať svoje základné, pretože ERP takmer vždy sú základné aplikácie, ktoré podniky prevádzkujú, je to len obrovský menič hier a bude to veľmi zaujímavé. Ale samozrejme, že všetko znie veľmi dobre, ale musí byť nakonfigurované inteligentne a musí byť dobre monitorované. Nie je to také jednoduché, ako to znie.

Po tom, čo som povedal, si myslím, že dám loptu ďalej, komu je tento chlap? Och, austrálsky chlap, Dez Blanchfield.

Dez Blanchfield: Veľmi vtipné. Robin Bloor, vždy tvrdý zákon. Ďakujem, že si ma dnes dostal. Takže veľká téma, ale vzrušujúca. Vybral som si obrázok, ktorý často vymýšľam, keď premýšľam o moderných dátových skladoch a podnikových dátových skladoch a mojich malých drahokamoch údajov. Takže tu mám toto krásne jazero obklopené horami a vlnami, ktoré vystupujú, a tieto vlny padajú cez tieto kamene. Takýmto spôsobom si dnes psychicky predstavujem, ako to vyzerá vo veľkom dátovom jazere. Vlny sú dávkové úlohy a analytika v reálnom čase je vrhaná na dáta, sú to horniny. A keď o tom premýšľam ako o fyzickom jazere, tak mi to prinesie budenie, že viete, rozsah dátových skladov, ktoré teraz budujeme, dôvod, prečo sme prišli s týmto razením mincí a termín dátové jazero je také veľké, že sú veľmi hlboké a občas v nich môžu byť búrky. A keď to urobíme, vždy musíte vyriešiť, čo vytvára búrku.

Takže v téme tejto veci sa mi zdá, že toto volanie sirény počítačom v pamäti je skutočne veľmi silné az dobrého dôvodu. Prináša toľko významných obchodných a technických výhod. To je diskusia na pár hodín v iný deň. Ale všeobecný posun k výpočtovým technológiám v pamäti, najprv chcem pokryť, ako sme sa sem dostali a čo to umožňuje, pretože to, podobne, vytvára základy toho, v čom spočívajú niektoré z výziev ako prvé a čo si musíme byť vedomí. a myslieť na to, že v našom svete, odkiaľ odídeme od tradičných starých spinningových diskov, ktoré držia dáta a sú stránkované na a mimo disku a do pamäte a z pamäte a do CPU, zatiaľ len odstraňujeme takmer jednu z týchto celých vrstiev, je točiaci sa disk. Pretože nezabudnite, že v počiatkoch výpočtovej architektúry sme sa architektonicky dlho nepresťahovali z mainframe alebo stredného sveta toho, čo sme pôvodne považovali za jadrovú pamäť a úložisko bicích.

Ako povedal Dr. Robin Bloor, prístup, ktorý sme zvolili pri presúvaní údajov okolo počítačovej architektúry, sa po niekoľko desaťročí v skutočnosti dramaticky nezmenil. Ak si myslíte o skutočnosti, že viete, moderná počítačová technológia už bola okolo, ak odpustíte slovnú hračku, asi 60 rokov, viete, šesť desaťročí a viac a je to v tom zmysle, že môžete kúp si škatuľu, ako to bolo. Posun k novej architektúre sa skutočne prejavil v mojej mysli, keď sme sa presunuli z myslenia okolo mainframes a midrange a architektúr jadra pamäte a bicích úložísk, na odvážnych alebo superpočítačov, najmä na likes Seymour Cray, kde sa veci ako napr. sa stala záležitosťou. Namiesto toho, aby ste mali len jednu trasu na presun údajov cez základnú dosku alebo základnú dosku, ako sa to dnes hovorí. A inline pamäť, viete, v týchto dňoch ľudia naozaj nepremýšľajú o tom, čo to vlastne znamená, keď hovoria DIMM a SIMM. Ale SIMM je jedna inline pamäť a DIMM je duálna inline pamäť a my sme od tej doby zložitejšie. Existujú desiatky rôznych typov pamäte pre rôzne veci: niektoré pre video, iné len pre všeobecné aplikácie, iné zabudované do CPU.

Takže došlo k tomuto veľkému posunu k novému spôsobu ukladania a prístupu k údajom. Chystáme sa prejsť rovnakým posunom v inej celej generácii, ale nie toľko v samotnom hardvéri, ale v zavádzaní hardvéru do obchodnej logiky a vrstvy dátovej logiky, a je to ďalší veľký posun paradigmy v mojej mysli.,

Ale len stručne o tom, ako sme sa sem dostali. Hardvérová technológia sa zlepšila a dramaticky zlepšila. Prešli sme od CPU a myšlienka jadra bola pomerne moderná koncepcia. Teraz považujeme za samozrejmé, že naše telefóny majú dve alebo štyri jadrá a naše počítače majú dve alebo štyri alebo dokonca osem jadier na ploche a osem a dvanásť a viac jadrových 16 a 32 serverových platforiem., Ale v skutočnosti je to celkom moderná vec, že ​​jadrá sa stali schopnosťou vnútri CPU a že sme prešli z 32-bit na 64-bit. Stalo sa tu niekoľko veľkých vecí: na viacerých jadrách sme dosiahli vyššie rýchlosti hodín, takže sme mohli robiť veci paralelne a na každej z týchto jadier bolo možné spustiť viacero vlákien. Zrazu sme mohli naraz naraziť na veľa vecí na rovnakých údajoch. Šesťdesiatštyri bitové rozstupy adries nám poskytli až dva terabajty pamäte RAM, čo je fenomenálny koncept, ale teraz je to vec. Tieto viaccestné architektúry základnej dosky, viete, základné dosky, kedykoľvek ste mohli robiť veci iba jedným smerom: dozadu a dopredu. A rovnako ako v prípade dní s počítačom Cray a niektorými návrhmi superpočítačov tej doby, teraz v stolných počítačoch a bežných bežných počítačoch typu stolných počítačov typu rack, pretože v skutočnosti väčšina moderných počítačov Počítače teraz prešli obdobím mainframe, midrange, micro desktops a my sme ich zmenili späť na servery.

A veľa z týchto superpočítačových schopností, tento superpočítačový dizajn, sa dostalo do bežných bežných komponentov. Vieš, v dnešnej dobe ide o myšlienku vziať si veľmi lacné PC do stojanov a umiestniť ich do stojanov po stovkách, ak nie tisícoch, a spustiť na nich softvér s otvoreným zdrojovým kódom, ako je napríklad Linux, a nasadiť na nich aplikácie SAP HANA viem, že to často považujeme za samozrejmé. Ale to je veľmi nová vzrušujúca vec a prichádza s jej zložitosťou.

Zlepšil sa aj softvér, najmä správa pamäte a delenie dát. Nebudem o tom veľa podrobností, ale ak sa pozriete na veľký posun za posledných 15 rokov, alebo dokonca menej, ako sa spravuje pamäť, najmä údaje v pamäti RAM a ako sa údaje v pamäti RAM rozdelia, takže, ako už naznačil Dr. Robin Bloor, viete, veci sa môžu čítať a písať súčasne bez toho, aby sa navzájom ovplyvňovali, a nie aby sa počkali. Mnoho veľmi výkonných funkcií, ako je kompresia a šifrovanie na čipe. Šifrovanie sa stáva dôležitejšou vecou a nemusíme to nevyhnutne robiť v softvéri, v pamäti RAM, v priestore CPU, teraz, keď sa na čipe natívne stáva. To dramaticky urýchli veci. A distribuované ukladanie a spracovanie údajov, opäť, veci, ktoré sme kedysi predpokladali, boli vecou superpočítačov a paralelného spracovania, teraz to berieme ako samozrejmosť v priestore ako SAP HANA a Hadoop a Spark atď.

To znamená, že tento vysokovýkonný počítačový systém, schopnosti HPC prišli do podniku, a teraz podnik využíva výhody, ktoré so sebou prináša zvýšenie výkonu a technologický priestor a technické výhody a obchodné výhody, pretože viete, skrátený čas na hodnotu sa dramaticky skracuje.

Ale používam tento obrázok príbehu, ktorý som čítal pred časom pána, ktorý postavil počítačový kufrík z Lega, pretože vždy sa mi napadne, keď premýšľam o niektorých z týchto vecí. A to je to, že to vyzerá ako skvelý nápad v čase, keď ho začnete stavať, a potom sa dostanete do jeho polovice a uvedomíte si, že je skutočne veľmi zložité dať dohromady všetky bity Lego a urobiť solídnu vec, dostatočne solídnu. vložiť základnú dosku a tak ďalej, postaví sa puzdro pre osobný počítač. A nakoniec si uvedomíte, že všetky malé kúsky nie sú zlepené správne a musíte byť trochu opatrní, o ktoré malé kúsky sa budete držať, aby bol pevný. A je to veľmi roztomilý nápad, ale je to prebudenie hovoru, keď sa prechádzate v polovici cesty a uvedomíte si: „Hmm, možno by som si mal kúpiť PC kufrík s 300 dolárov, ale teraz to dokončím a z toho sa niečo naučím.“

Pre mňa je to skvelá analógia toho, aké to je na stavaní týchto veľmi zložitých platforiem, pretože je všetko v poriadku a dobré je stavať a skončiť v prostredí, v ktorom máte smerovače a prepínače, servery a stojany. A máte spolu CPU a RAM a operačný systém. A na vrchol umiestnite niečo ako HANA pre distribuované spracovanie v pamäti, ukladanie a správu údajov. Okrem toho staviate zásobník SAP, získavate databázové schopnosti a potom načítate svoje údaje a svoju obchodnú logiku a začnete naň aplikovať niektoré čítania a zápisy a dotazy atď. Musíte sa držať na vrchole I / O a musíte naplánovať veci a riadiť pracovné zaťaženie a viacnásobnú prácu atď. Tento balík sa stáva veľmi zložitým, veľmi rýchlo. To je samo o sebe komplexný zásobník, ak je to len na jednom počítači. Vynásobte tým, že pri 16 alebo 32 strojoch sa stáva veľmi, veľmi netriviálnym. Keď vynásobíte až stovky a prípadne tisíce strojov, prejdete zo 100 terabajtov na petabajt, je to desivá koncepcia a toto sú skutočnosti, s ktorými sa teraz zaoberáme.

Takže nakoniec skončíte s niekoľkými vecami, ktoré tiež pomohli zmeniť tento svet, a to znamená, že miesto na disku sa stalo smiešne lacným. Viete, raz ste utratili 380 až 400 tisíc dolárov za gigabajt pevného disku, keď to bol masívny bubon veľkosti - niečo, čo si vyžadoval vysokozdvižný vozík. V súčasnosti je to jeden alebo dva centy na gigabajt voľného miesta na disku. A RAM urobil to isté. Tieto dve krivky J v oboch týchto grafoch sú mimochodom každé desaťročie, takže inými slovami sa pozeráme na dva bloky po 10 rokoch, čo je zníženie ceny o 20 rokov. Ale ja som ich rozdelil na dve krivky J, pretože nakoniec sa ten pravý stal len bodkovanou čiarou a vy ste nemohli vidieť detail, takže som to zmenil. Gigabajt RAM pred 20 rokmi bol niečo rádovo šesť a pol milióna dolárov. Ak v súčasnosti platíte viac ako tri alebo štyri doláre za gigabajt RAM za komoditný hardvér, ktorý vás okradol.

Toto výrazné zníženie cien za posledné dve desaťročia znamenalo, že teraz sa môžeme presunúť za miesto na disku a rovno do pamäte RAM, nielen na úrovni megabajtov, ale teraz na úrovni terabajtov a zaobchádzať s RAM ako s diskom. Výzvou však bolo, že RAM bola natívne pominuteľná - to znamená niečo, čo trvá krátku dobu - takže sme museli prísť s spôsobmi, ako zaistiť odolnosť v tomto priestore.

A tak tu chcem povedať, že výpočty v pamäti nie sú pre slabé srdce. Žonglovanie s týmito veľmi rozsiahlymi údajmi v pamäti a ich spracovanie je zaujímavou výzvou; ako som už naznačil, nejde o slabé srdce. Jedna vec, ktorú sme sa z tejto skúsenosti dozvedeli pri rozsiahlom a vysokohustotnom výpočte v pamäti, spočíva v tom, že zložitosť, ktorú staviame, spôsobuje riziko v mnohých oblastiach.

Pozrime sa na to však z hľadiska monitorovania a reakcie. Keď premýšľame o údajoch, začína to na disku, sedí v databázach na diskoch, tlačíme ich do pamäte. Akonáhle je v pamäti a distribuovaný a existujú jej kópie, môžeme použiť veľa jej kópií. Ak dôjde k nejakým zmenám, môže sa to odraziť na úrovni pamäte namiesto toho, aby bolo potrebné zapínať a vypínať a cez zadnú rovinu na dve rôzne úrovne, ide dovnútra a von z pamäte. Skončili sme s touto hardvérovou platformou hyperscale, ktorá nám to umožňuje teraz. Keď hovoríme o hyperskalovaní, je to ťažšie na smiešne hustých úrovniach a pamäti s veľmi vysokou hustotou, počte CPU a jadier a vlákien s veľmi vysokou hustotou. Teraz to máme veľmi komplexné patológie siete, ktoré to podporujú, pretože ak sa pôjde medzi uzlami a zoskupeniami, údaje sa musia v určitom okamihu pohybovať po sieti.

Nakoniec sme sa stali redundanciou porúch zariadení a musíme monitorovať zariadenia a ich časti. Do tejto platformy musíme zabudovať odolnú redundanciu dátových porúch a monitorovať ju. Musíme mať zabudovanú odolnosť voči distribuovanej databáze, takže musíme monitorovať databázovú platformu a zásobník vo vnútri. Musíme monitorovať rozvrhovanie distribuovaného spracovania, čo sa deje vo vnútri niektorých procesov, až po výzvu a dotaz a cestu, po ktorej sa dotaz nachádza, a ako sa štruktúruje a vykonáva dotaz. Ako to vyzerá, urobil niekto VYBRAŤ * na „bla“ alebo urobil skutočne veľmi inteligentný a dobre štruktúrovaný dotaz, ktorý im prinesie nominálne, minimálne množstvo údajov prichádzajúcich cez architektúru v základnej rovine? Máme viac pracovných úloh, viac používateľov a viac skupín, ktoré prevádzkujú rovnaké alebo viac pracovných úloh a dávkových úloh a plánovanie v reálnom čase. A máme túto zmes dávkového spracovania a spracovania v reálnom čase. Niektoré veci bežia pravidelne - hodinové, denné, týždenné alebo mesačné - iné sú na požiadanie. Niekto tam môže sedieť s tabletom, ktorý chce urobiť správu v reálnom čase.

A opäť sa dostávame k tomuto bodu, že zložitosť, ktorá sa v nich objavuje, nie je teraz len výzvou, je to dosť desivé. Túto realitu kontrolujeme, či jediný problém s výkonom, iba jeden výkonný problém, môže mať vplyv na celý ekosystém. A tak skončíme s touto veľmi zábavnou výzvou, aby sme zistili, aké sú vplyvy? A máme túto výzvu, sme reaktívni alebo proaktívni? Pozeráme sa na vec v reálnom čase a vidíme, že sa niečo „buchá“ a reaguje na to? Alebo sme videli nejakú formu trendu a uvedomili sme si, že s ňou musíme aktívne vstúpiť? Pretože kľúčom je, že každý chce niečo rýchle, lacné a ľahké. Končíme však týmito scenármi, na čo sa mi veľmi páči, a mojou obľúbenou líniou hádanky Donalda Rumsfelda, ktorá sa podľa môjho názoru vzťahuje na všetky tieto scenáre vysokej komplexnosti - a to je to, že sme to poznali, pretože to je niečo sme navrhli a postavili a beží podľa plánu. Známe neznáme v tom, že nevieme, kto, čo, kedy a kde, ak je to na požiadanie. A máme neznáme neznáme a to sú veci, ktoré musíme monitorovať a kontrolovať. Pretože realita je, všetci vieme, že nemôžete zvládnuť niečo, čo nemôžete zmerať.

Ak chcete mať správne nástroje a správnu schopnosť monitorovať naše plánovanie CPU, pozrite sa na čakacie časy a zistite, prečo veci čakajú vo frontách plánov v potrubí. Čo sa deje v pamäti, aký druh využitia sa vykonáva, aký výkon sa nám spomaľuje? Je materiál rozdelený správne, distribuuje sa, máme dostatok uzlov, ktoré ich držia, aby sa vysporiadali s pracovným zaťažením, ktoré sa naň hodí? Čo sa deje s vykonávaním procesov mimo procesov operačného systému? Samotné úlohy bežia, jednotlivé aplikácie a démoni ich podporujú? Čo sa deje vo vnútri týchto procesov, najmä štruktúrovanie dopytov a ako sa tieto dotazy vykonávajú a kompilujú? A zdravie týchto procesov celú cestu von v zásobníku? Znova viete, že počkajte, je to správne plánovanie, je to čakanie, kde to čaká, je to čakanie na čítanie z pamäte, I / O, CPU, I / O cez sieť ku koncovému užívateľovi ?

A potom späť k tomuto bodu, ktorý som práve spomenul krátko pred tým, ako som ho zabalil, a ako sa k týmto priblížime? Pozeráme sa v reálnom čase a reagujeme na veci, čo je najmenej ideálny scenár, ale aj tak je lepšie, keď to nevieme a zavolajte na linku technickej podpory a povedzme, že sa niečo pokazilo a musíme to sledovať. ? Alebo to robíme proaktívne a pozeráme sa na to, čo sa deje po línii? Inými slovami, vidíme, že máme nedostatok pamäte a je potrebné pridať ďalšie uzly? Robíme analýzu trendov, robíme plánovanie kapacít? Monitorujeme všetky historické časy realizácie a uvažujeme o plánovaní kapacít, alebo ich sledujeme v reálnom čase a aktívne preplánujeme a vyvažujeme záťaž? A sme si vedomí predovšetkým pracovného zaťaženia? Vieme, kto robí čo v našom zoskupení a prečo?

Výpočty v pamäti sú veľmi silné, ale s touto silou je to takmer jedna z tých vecí, ako je nabitá zbraň a hráte sa so živou muníciou. Ak nie ste opatrní, môžete sa nakoniec zastreliť do nohy. Táto sila výpočtu v pamäti teda znamená, že dokážeme bežať oveľa rýchlejšie a rýchlejšie vo veľmi distribuovaných a diskrétnych množinách údajov. Potom je však dopyt zo strany koncových používateľov vyšší. Na túto moc si zvyknú a chcú to. Už neočakávajú, že úlohy budú trvať týždne a správy sa objavia na obyčajnom starom papieri. A pod tým všetkým máme každodennú údržbu obkolesenú opravami, aktualizáciami a aktualizáciami. A ak uvažujete o spracovaní 24 hodín denne, 7 dní v týždni s výpočtom v pamäti, spravovaní týchto údajov, riadení pracovnej záťaže v celej pamäti, je to všetko v pamäti, technicky v efemérnej platforme, ak začneme s aplikáciou opráv a aktualizácií a inovácií v tam prichádza aj celý rad ďalších výziev v oblasti riadenia a monitorovania. Potrebujeme vedieť, čo môžeme urobiť offline, kedy ho môžeme inovovať a kedy ho uvedieme späť online. A to ma privádza k svojmu poslednému bodu a to znamená, že keď v týchto systémoch získame čoraz zložitejšiu stránku, nie je to nič, čo by človek mohol urobiť len tak, že sa mu palec a zatiahne za ucho. Už neexistujú žiadne, akési prístupy črevných pocitov. Na správu a poskytovanie tejto vysokej úrovne výkonnosti v oblasti výpočtov a správy údajov skutočne potrebujeme vhodné nástroje.

S týmto vedomím odovzdám nášmu kamarátovi z IDERA a počujem, ako sa k tejto výzve dostali.

Bill Ellis: Ďakujem veľmi pekne. Zdieľam svoju obrazovku a tu ideme. Preto je skutočne ponižujúce uvažovať o všetkých technológiách a o ľuďoch, ktorí prišli pred nami, aby sme sprístupnili tieto informácie dostupné v roku 2017. Budeme hovoriť o analýze pracovnej záťaže pre SAP HANA - v podstate riešenie na monitorovanie databázy: komplexné, bez agentov, poskytuje v reálnom čase a zostavuje históriu, takže môžete vidieť, čo sa stalo v minulosti. SAP S / 4 HANA ponúka potenciál lepšej, rýchlejšej a lacnejšej. Nehovorím, že je to lacné, len hovorím, že je to lacnejšie. Tradične sa stalo, že by ste mali hlavnú produkčnú inštanciu - pravdepodobne bežiacu na Oracle vo väčšom obchode, prípadne na SQL Servere - a potom by ste použili tento ETL proces a mali by ste viac rôznych druhov pravdy., A to je veľmi drahé, pretože ste platili za hardvér, operačný systém, licenciu Oracle pre každé z týchto jednotlivých prostredí. A potom by ste museli mať ľudí, aby zladili jednu verziu pravdy s ďalšou verziou pravdy. Toto spracovanie viacerých verzií ETL bolo teda pomalé a veľmi, veľmi ťažkopádne.

A tak HANA, v podstate jedna inštancia HANA, môže potenciálne nahradiť všetky ostatné prípady. Je to lacnejšie, pretože je to jedna hardvérová platforma, jeden operačný systém namiesto násobkov. A tak S / 4 HANA naozaj mení všetko a vy sa v podstate pozeráte na vývoj SAP z R / 2 na R / 3, rôzne vylepšovacie balíčky. Teraz je starý systém dostupný až do roku 2025, takže máte osem rokov, kým nebudete skutočne nútení migrovať. Aj keď vidíme ľudí, viete, dabbling ich prsty na nohách, pretože vedia, že to príde, a nakoniec, viete, ECC bude bežať na HANA, takže by ste na to naozaj mali byť pripravení a porozumieť technológii.

Jedna databáza, žiadne procesy ETL, žiadne kópie, ktoré sa musia zladiť. Takže znova, rýchlejšie, lepšie a lacnejšie. HANA je v pamäti. SAP dodáva softvér, dodávate hardvér. Neexistujú žiadne súhrnné tabuľky. Jedna z vecí, ktorú tak trochu navrhujú, keď o tom premýšľate, je to, že sa k tomu nechcete dostať, len si kúpime najväčší dostupný server. Naznačujú, že vy, druh a veľkosť vašej krajiny SAP v predstihu a v podstate sa hovorí, že nemigrujete údaje za 20 rokov. Myslím si, že archivácia je niečo, čo je v IT málo využívané, plošne, nielen v obchodoch SAP. Ďalšou vecou je, že spoločnosť SAP skutočne strávila veľa času prepísaním svojho natívneho kódu, aby nepoužíval SELECT *. SELECT * vracia všetky stĺpce z tabuľky a je to obzvlášť drahé v stĺpcovej databáze. A tak to nie je dobrý nápad pre SAP HANA. Takže v obchodoch, ktoré majú veľa úprav, veľa prehľadov, to budete hľadať a budete chcieť špecifikovať názvy stĺpcov, ako budete postupovať pri migrácii všetkého na HANA.

Radi by sme povedali, že HANA nie je všeliek. Rovnako ako všetky databázy, všetky technológie, je potrebné ich monitorovať, a ako už bolo uvedené, potrebujete čísla, aby ste mohli spravovať nadbytok, meranie meraním. A jednou z vecí, o ktorej hovorím v oblasti IDERA, je to, že každá obchodná transakcia interaguje so systémom záznamov av tomto prípade to bude HANA. A tak sa HANA stáva základom pre vykonávanie vašich transakcií SAP, zážitok koncového používateľa. A preto je dôležité, aby bol v prevádzke na najvyššiu rýchlosť. Stáva sa jediným bodom zlyhania a pri rozhovore s ľuďmi je to niečo, čo môže vyústiť do situácie, keď máte koncového používateľa a možno používa tieto údaje v reálnom čase a majú ad hoc dotaz, ktorý potenciálne nie je celkom správny. Možno sa nepripojia k tabuľkám a vytvorili vonkajší spoj, produkt partizána a v podstate spotrebúvajú veľa zdrojov. HANA to teraz uzná a zabije túto reláciu. A tak je tu rozhodujúca časť našej architektúry, ktorá vám umožní skutočne to zachytiť v histórii, takže môžete vidieť, čo sa stalo v minulosti, a spoznať tieto situácie.

Pozrime sa teda na analýzu pracovného za aženia SAP HANA. Toto je verzia 1, preto vás veľmi pozývame, aby ste sa k nám pripojili na ceste, a toto je produkt spoločnosti IDERA. Je komplexný, ale jednoduchý. Real-time s trendmi. Zdravie hostiteľa, napríklad zdravie. Sledujeme stavy čakania, dotazy SQL, spotrebitelia pamäte a služby. Takto vyzerá GUI a hneď vedľa netopiera môžete vidieť, že je web povolený. Vlastne som otvoril toto riešenie bežiace na mojom systéme. Existuje niekoľko zásadných vecí, na ktoré sa chcete pozrieť. Rozdelili sme sa na rôzne pracovné priestory. Najdôležitejšie z nich je to, čo sa deje na úrovni hostiteľa z využívania CPU a využitia pamäte. Určite sa nechcete dostať k výmene alebo zmätku. A potom sa v podstate prepracujete smerom k tomu, čo sa deje v trendoch, od času odozvy, používateľov, príkazov SQL, to je to, čo riadi aktivitu v systéme.

Jednou z vecí v spoločnosti IDERA je, že viete, nič sa nedeje v databáze, kým nedôjde k aktivite. A táto aktivita sú príkazy SQL, ktoré pochádzajú z aplikácie. Meranie príkazov SQL je preto absolútne nevyhnutné na to, aby bolo možné zistiť hlavnú príčinu. Takže, poďme na to a vŕtajte sa. Takže na úrovni hostiteľa sa môžeme skutočne pozrieť na pamäť, sledovať v priebehu času, využívať hostiteľské CPU. Krok späť, môžete sa pozrieť na výkazy COBSQL. Teraz je jednou z vecí, ktoré uvidíte na našej strane architektúry, že táto informácia je uložená mimo HANA, takže ak sa niečo stane HANA, v podstate zaznamenávame informácie až do nedostupnosti, Bohu, nedostupnosť, Môžeme tiež zachytiť všetko, čo sa v systéme deje, aby ste mali jasnú viditeľnosť. A jednou z vecí, ktorú urobíme, je, že predstavíme príkazy SQL vo váženom poradí. Zohľadní sa tým počet spustení, a preto ide o celkovú spotrebu zdrojov.

A tak sa tu môžete dostať do jednotlivých metrík - kedy sa tento príkaz SQL vykonal? A potom je spotreba zdrojov do značnej miery riadená realizačným plánom, a preto sme schopní to neustále zachytávať. HANA je v pamäti. Je to vysoko paralelné. Na každej tabuľke má primárne indexy, ktoré sa niektoré obchody rozhodnú vytvoriť sekundárny index na riešenie určitých problémov s výkonom. Preto je veľmi cenné vedieť, čo sa stalo s plánom vykonávania určitých príkazov SQL. Pozrime sa aj na služby, spotrebu pamäte, opäť zaznamenané v priebehu času. Architektúra: jedná sa o samostatné riešenie, ktoré si môžete stiahnuť z našej webovej stránky. Architektúra je taká, že je povolená na webe.

K určitej inštancii sa môže pripojiť viacero používateľov. Môžete monitorovať miestne výskyty SAP HANA. V našom úložisku uchovávame priebežnú štvortýždňovú históriu a je to samospráva. Na nasadenie je to dosť jednoduché. Potrebujete Windows Server. Musíte si ho stiahnuť. Väčšina serverov Windows bude mať vstavanú .NET framework a je dodávaná s licenciou. A tak by ste šli do sprievodcu inštaláciou, ktorý je poháňaný programom Setup.exe a skutočne by otvorila obrazovku, licenčnú zmluvu a tento obrys by ste jednoducho prepracovali kliknutím na tlačidlo „Ďalej“. A tak, kde by ste chceli, aby spoločnosť HANA byť nainštalovaný? Ďalej sú to vlastnosti databázy a toto bude vaše pripojenie k SAP HANA, takže toto je agentské monitorovanie inštancie HANA. A potom v podstate poskytneme ukážku, to je port, s ktorým v predvolenom nastavení komunikujeme. Kliknite na „Inštalovať“ a v podstate sa spustí HANA a začnete s budovaním histórie. Takže len kúsok informácií o rozmerovej tabuľke. Môžeme monitorovať až 45 inštancií HANA a budete ich chcieť použiť tak, aby ste určili počet jadier, pamäte a miesta na disku, ktoré budete potrebovať. A to predpokladá, že máte k dispozícii kompletnú štvortýždňovú históriu.

Rovnako ako rýchla rekapitulácia sa pozeráme na stav serverov, stav inštancií, využitie CPU / pamäte. Čo sú to spotrebitelia pamäte, aké sú činitele ovládania, aké sú služby? Príkazy SQL sú nevyhnutné - aké sú stavy vykonávania? Ukázať realizačné plány, kedy sa veci vykonali, poskytnúť trendy? Toto vám poskytne real-time a históriu toho, čo sa stalo. A ako som už spomenul, pretože naša história je oddelená od HANA, budeme zachytávať veci, ktoré vypršali a boli vyprázdnené z histórie HANA. Aby ste mohli vidieť skutočnú spotrebu zdrojov vo vašom systéme kvôli samostatnej histórii.

Ako som už spomenul, na webovej stránke spoločnosti IDERA v časti Products to môžete ľahko nájsť. Ak to chcete vyskúšať, určite vás vítame. Zistite, ako poskytuje informácie a na tomto webe nájdete ďalšie informácie. Všetky zúčastnené strany sú preto viac než šťastné. Teraz v portfóliových produktoch ponúkaných spoločnosťou IDERA existuje aj monitor transakcií SAP ECC, ktorý sa nazýva Precise for SAP. A čo to je - či už používate portál alebo len vyrovnávacie ECC - skutočne zachytí transakciu koncového používateľa od kliknutia na disk, až po príkaz SQL a ukáže vám, čo sa deje.

Teraz vám ukážem iba jednu súhrnnú obrazovku. Z tejto súhrnnej obrazovky chcem mať niekoľko jedál. Je to čas odozvy na osi Y, čas na osi X plus deň a v tomto zobrazení transakcií vám ukážeme čas klienta, čas zaradenia do frontu, čas kódu ABAP, čas databázy. Môžeme zachytiť ID koncových používateľov, T-kódy a môžete skutočne filtrovať a zobrazovať servery prostredníctvom konkrétnej transakcie, ktorú prešiel. Mnoho obchodov teda prevádzkuje front-end krajiny pod VMware, takže môžete skutočne zmerať, čo sa deje na každom zo serverov, a dostať sa do veľmi podrobnej analýzy. Toto zobrazenie transakcií je teda pre transakciu koncového používateľa cez celú krajinu SAP. A nájdete to na našej webovej stránke v časti Produkty APM Tools a toto by bolo riešenie SAP, ktoré máme. Inštalácia je o niečo zložitejšia, takže sa nejde len stiahnuť a vyskúšať, ako to máme pre HANA. To je niečo, v čom by sme spolu pracovali, aby sme navrhli a zrealizovali celkovú transakciu za vás.

Takže iba tretia rýchla rekapitulácia, analýza pracovnej záťaže pre SAP HANA, je komplexná, bez agentov, v reálnom čase, ponúka históriu. Ponúkame možnosť stiahnutia a vyskúšania pre vaše stránky.

Takže s týmto pôjdem čas späť na Eric, Deza a Dr. Bloora.

Eric Kavanagh: Áno, možno Robin, nejaké otázky od vás a potom Dez po Robinovi?

Robin Bloor: Dobre. Chcem tým povedať, prvá vec, ktorú by som chcel povedať, je, že sa mi naozaj páči pohľad na transakciu, pretože v tejto situácii by som presne chcel. Urobil som veľa práce - dobre, je to už dávno - robím monitorovanie výkonnosti a to bolo také niečo; v tom čase sme nemali grafiku, ale to bola vec, ktorú som chcel predovšetkým urobiť. Aby ste sa tak či onak mohli sami vpichnúť, kdekoľvek sa vyskytne problém.

Prvá otázka, ktorú mám, je, viete, väčšina ľudí implementuje S / 4 nejakým spôsobom alebo iným spôsobom, nie je z krabice. Keď sa zapojíte do nejakej danej implementácie S / 4, zistili ste, že je implementovaná dobre alebo skončíte, viete, objavujete veci, ktoré by mohli prinútiť zákazníka, aby sa znova nakonfiguroval? Ako na to všetko?

Bill Ellis: Každý obchod je trochu iný. A existujú rôzne spôsoby použitia, existujú rôzne správy. Pre webové stránky, ktoré majú hlásenia ad hoc, mám na mysli to, že to v skutočnosti znamená zástupný znak v systéme. Preto je jednou z najdôležitejších vecí začať s meraním a zistiť, aká je základná línia, čo je normálne pre konkrétne miesto, kde je to konkrétne miesto, na základe ich vzorcov použitia, zdôrazňovanie systému. Potom odtiaľ vykonajte úpravy. Optimalizácia monitorovania zvyčajne nie je jednorazová, je to skutočne bežná prax, pri ktorej monitorujete, vylaďujete, honujete, čím zlepšujete systém, aby komunita koncových používateľov mohla efektívnejšie slúžiť podniku.

Robin Bloor: Dobre, takže keď implementujete - tým myslím, viem, že na túto otázku je ťažké odpovedať, pretože sa bude líšiť v závislosti od veľkosti implementácie - ale koľko prostriedkov má monitorovacia schopnosť IDERA, koľko to spotrebuje ? Má to nejaký význam, alebo to jednoducho nezasahuje? Ako to funguje?

Bill Ellis: Áno, povedal by som, že režijné náklady sú približne 1–3 percenta. Mnoho obchodov je veľmi ochotných to obetovať, pretože to zrejme budete môcť kúpiť z hľadiska optimalizácie. Závisí to od vzorov použitia. Ak robíte celú krajinu, záleží to na jednotlivých monitorovaných technológiách. Tak, druh, počet najazdených kilometrov sa líši, ale ako sme hovorili, je určite lepšie stráviť trochu času, aby ste vedeli, čo sa deje, než len slepo. Obzvlášť by to bolo, viete, sme tu v januári a dostanete sa k spracovaniu ročných období a zhromažďujete údaje za 12 mesiacov. Viete, to robí výkon, získavanie správ regulačným organizáciám, bankám, akcionárom, je absolútne nevyhnutné pri kritickom výkone podniku.

Robin Bloor: Správne. A z vášho pohľadu je to rýchle, pretože si myslím, že ste tam zapojený do celého radu stránok SAP - aký veľký je pohyb medzi zákazníckou základňou SAP smerom k S / 4? Myslím, je to niečo, čo viete, že je tu nejaká lavína nadšených zákazníkov, alebo je to len ustavičný pramienok? Ako to vidíš?

Bill Ellis: Myslím, že pred pár rokmi by som povedal, že to bola špička. Teraz by som povedal, že ľudia sú tak trochu až po koleno. Myslím si, že viete, vzhľadom na časový plán budú ľudia v nasledujúcich rokoch skutočne ponorení do HANA. A tak monitorovanie, transformácia, viete, si myslím, že väčšina zákazníkov je tak trochu na krivke učenia. A tak si myslím, že nie sme úplne na lavíne, ako ste povedali, ale myslím si, že sme na vrchole hlavnej premeny na HANA.

Robin Bloor: Dobre, takže pokiaľ ide o weby, ktoré ste videli, ktoré prešli na tento účel, prispôsobujú tiež HANA pre iné aplikácie alebo sú nejakým spôsobom úplne spotrebované na ich výrobu. práca funguje? Aký je tam obraz?

Bill Ellis: Áno, ľudia často integrujú SAP s inými systémami, v závislosti od toho, aké moduly a tak ďalej, takže je tu trochu. Zatiaľ nevidím ľudí, ktorí nasadili iné aplikácie na HANA. To je určite možné. A tak je to viac okolo krajiny okolo infraštruktúry SAP.

Robin Bloor: Myslím, že by som vás mal radšej odovzdať Dezovi. Zabíjal som tvoj čas. Dez?

Dez Blanchfield: Ďakujem. Nie, to je všetko dobré. Dva veľmi rýchle, len aby sa pokúsili nastaviť tému. SAP HANA je už niekoľko rokov a ľudia to mali možnosť zvážiť. Ak by ste nám chceli dať hrubý odhad percenta ľudí, ktorí ho prevádzkujú - pretože to beží veľa ľudí - čo si myslíte, že percento trhu, o ktorom viete, je v súčasnosti také, ktoré už prešlo od tradičných implementácií SAP po SAP na HANA? Pozeráme na 50/50, 30/70? Aké, aké percento trhu vidíte ľudí, ktorí prešli a urobili krok teraz, oproti ľudu, ktorí sa len zdržiavajú a čakajú na veci, ktoré sa majú vylepšiť alebo vylepšiť alebo zmeniť, alebo v akomkoľvek prípade?

Bill Ellis: Áno, v skutočnosti by som dal, z môjho pohľadu, percento okolo 20 percent. SAP má tendenciu byť tradičnými podnikmi. Ľudia majú tendenciu byť veľmi konzervatívni, a tak ich ľudia budú ťahať nohami. Myslím, že to záleží aj na tom, či ste spustili SAP už dlhší čas, alebo ste od nejakého SMB, ktorý pravdepodobne nedávno nasadil SAP? A tak existuje niekoľko faktorov, ale celkovo si nemyslím, že percento je 50/50. Povedal by som, že 50 percent je aspoň fušujúcich a má HANA niekde v ich dátovom centre.

Dez Blanchfield: Zaujímavou cestou, ktorú ste nám dali skôr, bolo to, že je to v konečnom dôsledku hotový skutok a že hodiny fyzicky a doslova tikajú o čase prechodu. Myslíte si, že to v tomto procese ľudia robia? Aký je všeobecný zmysel ľudového chápania, že ide o prechodný posun v platforme, nie je to len možnosť, stáva sa to predvolená hodnota?

A z pohľadu spoločnosti SAP som si istý, že sa týmto smerom posúvajú, pretože vo výkone je výrazná konkurenčná výhoda, ale myslím si, že tiež zápasia s kontrolou späť z platformy namiesto toho, aby sa dostali na tretiu straníckej databázy, teraz ju prinášajú späť na svoju vlastnú platformu. Myslíte si, že spoločnosti dostali túto správu? Myslíte si, že tomu ľudia rozumejú a teraz sa na to chystáte? Alebo je to stále niečo ako nejasné, myslíte si, z trhu?

Bill Ellis: Nemyslím si, že SAP je hanebný o komunikácii a ľudia, ktorí išli do SAPPHIRE, videli HANA všade. Takže si myslím, že ľudia sú si dobre vedomí, ale ľudská prirodzenosť je taká, aká je, viete, niektorí ľudia trochu tak trochu ťahajú za nohy.

Dez Blanchfield: Pretože si myslím, že dôvodom, prečo som sa na túto otázku pýtal, musíte mi odpustiť, ale súhlasím. Myslím, že sa nehanbili o komunikácii. Myslím, že signál vyšiel mnohými spôsobmi. A súhlasím s vami - ešte neviem, že všetci skočili. Viete, tradičný podnik, veľmi veľké podniky, ktoré to riadia, stále mnohými spôsobmi nie len ťahajú za nohy, ale len sa snažia vyrovnať so zložitosťou zmeny. Pretože si myslím, že jedna vec, ktorú vyzdvihol váš nástroj a určite vaša dnešná demonštrácia, a pre mňa jedna kľúčová oblasť so sebou by som rada, keby si každý dnes vypočul a naladil, aby sa posadil a venoval pozornosť reflexii, je nástroj, ktorý je podľa môjho názoru tento proces zjednodušený. Myslím, že je pod nimi veľa nervóznych riaditeľov IT a ich tímov, ktorí uvažujú: „Ako urobím prechod od tradičných systémov RDBMS, systémov pre správu relačných databáz, ktoré sme poznali po celé desaťročia, k úplne novému vzorcu výpočtov a správu úložiska v priestore, ktorý je stále pomerne statočný? “ Ale v mnohých ohľadoch je to neznámym javom a len veľmi málo ľudí urobilo tento posun v iných oblastiach, že to nie je tak, že majú inú časť podnikania, ktorá už prešla na výpočet v pamäti. Takže, je to všetko, alebo nič, pohybovať sa v ich mysli.

Takže jedna z vecí, ktorú som z toho viac ako čokoľvek vzal - je to, že ťa za chvíľu zaútočím na otázku - je ten strach, ktorý je podľa mňa v mnohých ohľadoch zmiernený a že pred dneškom, Keby som počúval CIO, tak by som si pomyslel: „No, ako urobím tento prechod? Ako sa chystám zaručiť rovnakú schopnosť, akú máme na platforme pre správu relačných databáz a dlhoročné skúsenosti s databázami DBA, na novú platformu, v ktorej momentálne nemáme zručnosti? “, myslíte si, že ľudia pochopili, že nástroje sú teraz k dispozícii tým, čo ponúkate, a že môžu, druh, zhlboka sa nadýchnuť a úľavu, že prechod nie je taký strašidelný, ako by to mohlo byť predtým. k dispozícii tento nástroj? Myslíte si, že ľudia pochopili, že je to stále niečo také, o čom len zápasia s prechodom na výpočtové a pamäťové úložisko v porovnaní so starými kombináciami NVMe, flash a diskov?

Bill Ellis: Áno, takže je nepochybne veľa technológií a nástrojov, ktoré to dokážu graficky znázorniť, čo sa deje a je veľmi ľahké určiť špičkových spotrebiteľov zdrojov. Chcem tým povedať, že to zjednodušuje veci a pomáha technologickému personálu skutočne dobre zvládnuť. Hej, budú vedieť, čo sa deje, a budú schopní pochopiť všetku zložitosť. Nástroje na trhu sú teda určite užitočné a preto ponúkame analýzu pracovnej záťaže pre SAP HANA.

Dez Blanchfield: Áno, myslím si, že na tom, čo ste nám dnes ukázali, je skvelé, že pri monitorovaní hardvéru, súčasti operačného systému, a dokonca aj sledovaní určitej pracovnej záťaže pohybujúcej sa, ako ste povedali, myslím tým nástroje boli tam už nejaký čas. Trochu pre mňa, najmä vo vnútri rád HANA, je to, že sme nemuseli mať nutnosť dostať lupu a nahliadnuť do nej a priamo vidieť, čo váš nástroj robí s tým, čo sa deje s otázkami a ako sú byť štruktúrovaný a kde je toto zaťaženie.

Vďaka nasadeniam, ktoré ste doteraz videli, ste vzhľadom na to, že ste doslova najviac autoritatívni v tomto priestore na svojej platforme na svete, niektoré z rýchlych výhier, ktoré ste videli - získali nejaké neoficiálne vedomosti, s ktorými môžete zdieľať nás okolo niektorých Eureka momentov, aha momentov, keď ľudia nasadili súpravu nástrojov IDERA, našli veci, o ktorých jednoducho nevedeli, boli na ich platformách a predstaveniach, ktoré mali. Máte nejaké skvelé neoficiálne príklady toho, kde to ľudia práve nasadili, ani neviem, čo majú a zrazu odišli: „Páni, vlastne sme nevedeli, že to tam je?“

Bill Ellis: Áno, takže veľké obmedzenie pôvodných nástrojov spočíva v tom, že ak sa utečený dotaz zruší, prepláchne informácie, takže v podstate nemáte históriu. Ak ukladáme históriu offline, ako runaway dotaz, budete mať históriu, budete vedieť, čo sa stalo, budete mať možnosť vidieť plán vykonávania atď. A tak vám to umožní, napríklad, pomôcť komunite koncových používateľov v podstate lepšie fungovať, lepšie písať správy, atď. A tak je história niečo, čo je naozaj milé. Jedna z vecí, ktoré som chcel ukázať, je to, že sa môžete pozrieť v reálnom čase až do štyroch týždňov, a potom si môžete ľahko priblížiť akýkoľvek požadovaný časový rámec a potom môžete odhaliť základnú jazdnú aktivitu. Len to, že viditeľnosť, je niečo, čo je veľmi užitočné vedieť, aké úzke miesta sa objavili.

Dez Blanchfield: Spomenuli ste, že je už nasadený pre viacerých používateľov, a bol som ohromený skutočnosťou, že v mnohých ohľadoch je to bez agentov a skutočne nulového dotyku. Je bežné, že jediné nasadenie vášho nástroja bude potom k dispozícii každému z centra sieťových operácií v NOC a bude sledovať základnú infraštruktúru podporujúcu klaster až po aplikačný a vývojový tím? Je to normálna záležitosť a nasadíte ju raz a oni by ju zdieľali, alebo očakávate, že by ľudia mohli mať inštancie modelu pozerajúce sa na rôzne časti balíka? Ako to vyzerá?

Bill Ellis: Takže základný tím bude mať zvyčajne veľmi silný záujem o technologické základy toho, čo sa deje v SAP. Je zrejmé, že existuje viacero tímov, ktoré budú podporovať celú krajinu. HANA kus je práve zameraný na to. Prejdem na základný tím SAP ako primárnych spotrebiteľov informácií.

Dez Blanchfield: Správne. Napadá ma však, že ak mám vývojový tím alebo nie iba na úrovni kódu, ale ak mám tím vedcov údajov alebo analytikov, ktorí tam vykonávajú analytické práce na súboroch údajov, najmä vzhľadom na to, že existuje výrazný tlak na to, aby sa veda o údajoch aplikovala na všetko vo vnútri organizácií teraz, podľa môjho názoru - a opravím ma, ak sa mýlim - sa mi zdá, že to bude tiež veľmi zaujímať, pretože v mnohých ohľadoch jeden o závažných veciach, ktoré môžete urobiť v prostredí dátového skladu, je rozpútanie dátového vedca a umožní mu začať robiť ad hoc otázky. Mali ste nejaké príklady toho, čo sa deje, keď vás obchody zavolali, a povedali: „Zhodili sme tím pre vedu údajov, je to skutočne bolestivé, čo pre nich môžeme urobiť v porovnaní s tým, čo práve robíme tradičné prevádzkové monitorovanie a riadenie? “Je to dokonca niečo?

Bill Ellis: No, áno, trochu by som to zmenil a moja odpoveď by bola taká, že pri pohľade na výkon, pri uvedomovaní si výkonnosti pri vývoji QA výroby, viete, čím skôr ukladáte, tým menšie problémy, menej prekvapenia máte. Takže absolútne.

Dez Blanchfield: V nadväznosti na to veľa nástrojov, s ktorými som mal skúsenosti - a som si istý, že s nimi bude Robin súhlasiť - veľa nástrojov tu, ak máš veľký RDBMS, potrebuješ naozaj vysoko - kvalifikovaní, hlboko oboznámení a skúsení DBA. Niektoré požiadavky na infraštruktúru a platformu, ktoré sa vyskytujú v systéme SAP HANA, pretože sú v súčasnosti podporované na konkrétnych distribúciách, ktoré sa prispôsobujú konkrétnemu hardvéru a podobne, podľa môjho najlepšieho vedomia. Viete, existujú ľudia s desaťročnými skúsenosťami, ktorí nie sú rovnakí. Vidím však, že to nie je nevyhnutne požiadavka tohto nástroja. Zdá sa mi, že môžete nasadiť svoj nástroj a dať ho niektorým celkom novým tváram a okamžite im dať právomoc nájsť veci, ktoré sa nedajú dobre vykonávať. Je to tak, že je tu dosť krátka krivka učenia, ktorá by s tým mala byť v čo najkratšom čase a aby sa jej nasadenie nejako vyplatilo? Vieš, môj všeobecný zmysel je, že nemusíte mať 20 rokov skúseností s riadením nástroja, aby ste okamžite videli hodnotu. Súhlasíte s tým, že tomu tak je?

Bill Ellis: Oh, absolútne a myslím si, že veľa úspechov nasadenia skutočne závisí od plánovania a architektúry prostredia SAP HANA. A potom je nepochybne veľa zložitosti, veľa technológie, na ktorej je postavená, ale potom to len príde na sledovanie spôsobov používania toho, čo sa deje. Takže, aj keď je to zložitejšie, je to trochu zabalené a trochu zjednodušené. To je veľmi zlé.

Dez Blanchfield: Áno, takže predtým, ako sa vrátim Ericovi, pretože viem, že má pár otázok, najmä od otázok, ktoré prešli otázkami a odpoveďami, ktoré vyzerali zaujímavo, a ja by som rád počul odpoveď. Tradičná cesta pre niekoho - už ste spomenuli, že ju môžete získať, môžete si ju stiahnuť a vyskúšať. Môžete to jednoducho rekapitulovať pre ľudové počúvanie dnes alebo pre ľudí, ktorí by to mohli neskôr prehrať? Aké sú rýchle dva alebo tri kroky, aby ste si dali ruky na kópiu a nasadili ju a vyskúšali vo svojom prostredí predtým, ako si ju kúpia? Ako to vyzerá? Aké sú kroky na to?

Bill Ellis: Áno. Takže, IDERA.com a choďte na Produkty a uvidíte analýzu pracovného zaťaženia pre SAP HANA. K dispozícii je stránka na stiahnutie. Myslím, že vás požiadajú o nejaké kontaktné informácie a produkt je iba zabalený s licenčným kľúčom, takže si ho môžete nainštalovať pomocou programu Setup.exe a jednoducho sa rozbehnúť, myslím, veľmi rýchlo.

Dez Blanchfield: Takže môžu ísť na váš web, môžu si ho stiahnuť. Spomínam si, keď som sa na to pozrel pred časom a včera večer som sa dvakrát skontroloval, môžete si vyžiadať demo, z pamäte, kam ťa niekto z tvojho tímu prejde? Môžete si ho však stiahnuť zadarmo a nasadiť lokálne vo svojom vlastnom prostredí, vo svojom vlastnom čase, však?

Bill Ellis: Áno.

Dez Blanchfield: Výborne. Myslím si, že viac ako čokoľvek, pravdepodobne by som osobne odporučil ľudu, aby si urobil kópiu webovej stránky, nejakú dokumentáciu, pretože viem, že je tu veľa dobrého obsahu, aby sa to dalo urobiť, a skús to. Dajte to do svojho prostredia a uvidíte, čo nájdete. Mám podozrenie, že akonáhle sa v prostredí SAP HANA pozriete pomocou nástroja IDERA, nájdete tam veci, o ktorých ste si neboli vedomí.

Pozri, ďakujem ti veľmi pekne za to a ďakujem za čas iba za otázky a odpovede s Robinom a I. Ericom, pôjdem späť k vám, pretože viem, že niektoré otázky a odpovede prešli aj od našich účastníkov.

Eric Kavanagh: Áno, tu naozaj rýchly. Jeden z účastníkov tu teda urobí veľmi dobrý komentár a hovorí len o tom, ako sa veci menia. V minulosti sa spomaľovala pamäť, spomaľovala sa častým vyhľadávaním, v súčasnosti CPU udusuje príliš veľa údajov v pamäti. Viete, existujú problémy so sieťou. Vždy to bude pohyblivý cieľ, však? Čo vidíte v týchto dňoch ako trajektóriu, pokiaľ ide o to, kde budú prekážky a kde sa budete musieť sústrediť na svoju pozornosť?

Bill Ellis: Áno. Pokiaľ nemeriate, je ťažké to vedieť. Jednou z vecí príkazov SQL je, že sa stanú hnacími silami spotreby zdrojov. A tak za okolností, že ste mali, napríklad, veľkú spotrebu pamäte alebo spotrebu CPU, budete schopní zistiť, aká aktivita spôsobila túto spotrebu zdrojov. Teraz by ste to nemuseli nevyhnutne zabíjať, ale chceli by ste si toho byť vedomí a o tom, čo sa deje, ako často sa to stáva, atď. Sme tak trochu nový, pokiaľ ide o riešenie celého súboru alebo kuchárku odpovedí na rôzne okolnosti. A tak je to veľká otázka a čas ukáže. Postupom času budeme mať viac informácií.

Eric Kavanagh: To je všetko. Vy ste vo veľmi zaujímavom priestore. Myslím si, že v nadchádzajúcich mesiacoch a nasledujúcich rokoch uvidíte veľa aktivít, pretože viem, že spoločnosť SAP, ako ste navrhli v našom telefonickom rozhovore pre obsah, poskytla ľuďom peknú dlhú rampu na prechod. HANA. Táto rampa má však koniec a v určitom okamihu budú musieť ľudia urobiť nejaké vážne rozhodnutia, takže čím skôr, tým lepšie, že?

Bill Ellis: Určite.

Eric Kavanagh: Dobre ľudia, zhoreli sme tu ďalšiu hodinu v Hot Technologies. Nájdete informácie online, insideanalysis.com, tiež techopedia.com. Zamerajte sa na tento web, kde nájdete veľa zaujímavých informácií, vrátane zoznamu všetkých našich archívov týchto predchádzajúcich vysielaní. Ale ľudia, veľké ďakujem vám všetkým tam, našim priateľom v IDERA, Robinovi a samozrejme Dezovi. A budeme vás kontaktovať budúci týždeň, ľudia. Ešte raz vám ďakujem za váš čas a pozornosť. Dávaj pozor. Zbohom.

Do budúcnosti: rampa pre výpočty v pamäti