A Techopedia munkatársai, 2017. január 25
Elvihető: Eric Kavanagh a házigazda megbeszélést folytat a memória beépítéséről és az SAP HANA-ról Dr. Robin Bloor, Dez Blanchfield és az IDERA Bill Ellis vendégeivel.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Oké, hölgyeim és uraim. Üdvözlet és üdvözlöm még egyszer. Szerdán négy óra a keleti idő, az elmúlt pár év pedig azt jelenti, hogy itt az ideje a Hot Technologies számára is. Igen, valóban, nevem Eric Kavanagh, én leszek a házigazdám a mai beszélgetéshez.
És az emberek, ma néhány jó dologról fogunk beszélni. A memória világába merülünk, a pontos cím: „Into the Future: On-Ramp a memóriában lévő számítástechnika számára.” Manapság egész düh és jó okkal, főleg azért, mert a memória sokkal gyorsabb, mint a forgólemezekre támaszkodni. A kihívás azonban az, hogy sok szoftvert kell átírni. Mivel a manapság a legtöbb szoftvert a lemezt szem előtt tartva készítették, és ez valóban megváltoztatja az alkalmazás architektúráját. Ha azt tervezi, hogy az alkalmazás megvárja a forgó lemezt, akkor csak a dolgok másképp történnek, mint ha a memóriában lévő összes technológia megvan.
Van egy hely a tiédről, találj a Twitteren, @eric_kavanagh. Mindig próbálok visszaváltani, és retweetelni is, amikor valaki megemlít.
Mint mondtam, ma a memóriában, és különösen az SAP HANA-ról beszélünk. Tisztelettel töltötte az elmúlt évet az SAP közösség nagyon jó megismerésével, és azt kell mondanom, hogy ez egy izgalmas környezet. Kalap azoknak, akik ezt a műveletet hajtják végre és a frontvonalon vannak, mert az SAP hihetetlenül jó művelet. Amit üzletben csinálnak igazán nagyon jók. Természetesen nagyszerűek a technológiában is, és valóban komoly befektetéseket tettek a HANA-ba. Valójában emlékszem - valószínűleg körülbelül hat vagy hét évvel ezelőtt -, hogy valójában valami munkát végeztünk az Egyesült Államok légierőinek, és kaptuk meg az SAP-ból valakit, hogy jöjjön be, és korai pillantást vegyen a HANA és mi volt a tervek. És nem utolsósorban, az SAP Labs emberei sok időt és erőfeszítést tettek annak megértéséért, hogy miként építhetik fel ezt az architektúrát, amely ismét teljesen különbözik a hagyományos környezetektől, mivel minden van a memóriájában. Tehát beszélnek arról, hogy tranzakciós és analitikus műveleteket végeznek ugyanazon adatokkal a memóriában, ellentétben a hagyományos módszerrel, melyet kihúznak, kockaba helyezik, például elemzik, ott elemzik, szemben a tranzakciós, nagyon más módon történik.
Ez egy érdekes hely, és valójában egy másik gyártótól, az IDERA-tól kiderítjük, kicsit arról, hogy mindezek a dolgok működni fognak, és mi szól a rámpán, őszintén szólva. Szóval, Dr. Robin Bloor-tól, a saját fő elemzőinktől, a The Bloor Group-nál fogunk meghallgatni; Dez Blanchfield, adattudósunk, majd jó barátja, Bill Ellis az IDERA-ból. Szóval ezzel átadom a kulcsot Dr. Robin Bloornak, aki elveszi.
Dr. Robin Bloor: Igen, ahogy Eric mondta, az az idő, amelyet először SAP HANA-nál tájékoztattunk, most sok évvel ezelőtt jött vissza. De nagyon érdekes volt, az adott idő nagyon érdekes. Egy vagy két olyan társaságba kerültünk, amelyek így vagy úgy, memória-technológiát kínáltak. Teljesen egyértelmű volt, hogy a memória jön. És valójában csak az SAP felemelkedett és hirtelen elindította a HANA-t. Úgy értem, sokk volt, amikor láttam, hogy az SAP ezt csinálja. Tehát sokk volt, mert számítottam arra, hogy másutt érkezik. Arra számítottam, hogy a Microsoft, az Oracle vagy az IBM, vagy valaki hasonló. Az a gondolat, hogy az SAP ezt csinálja, valóban nagyon meglepő volt számomra. Azt hiszem, nem kellett volna, mert az SAP az egyik stratégiai szállító, és tudod, nagyon sok minden, ami az iparban történik, ezek egyikéből származik.
Mindenesetre, a memóriában szereplő lényeg, úgy értettem, rájöttünk, hogy beszéltünk róla, hogy amint ténylegesen bemegy a memóriába - ez nem az adatok memóriába helyezéséről szól, hanem arról, hogy elkötelezzük magunkat a az a gondolat, hogy a memória réteg a rendszerrekord - mihelyt áthelyezi a rendszerrekordot a memóriába, a lemez egyfajta átadási közeggé válik, és másképp válik. És azt gondoltam, hogy ez nagyon izgalmas, amikor ez megtörtént. Tehát tényleg vége van a tárcsa forgatásának. A forgótárcsa hamarosan csak a múzeumokban létezik. Nem vagyok biztos benne, hogy mennyi időn belül hamarosan ez a helyzet, de alapvetően a szilárdtestalapú lemez most a Moore törvény görbéjén van, már tízszer gyorsabb, mint a rozsda fonása, amint azt most hívják, és hamarosan még gyorsabb lesz, és akkor ez azt jelenti, hogy a lemezekhez használt esetek száma egyre kevesebb.
És az a furcsa tény, hogy a hagyományos DBMS, valójában sok hagyományos szoftver épült a tárcsa forgatására, feltételezve, hogy forgó lemez. Mindenféle fizikai szintű képességgel rendelkezik, amelyekbe gondosan beprogramozták a forgó lemezt, hogy az adatgyűjtés a lehető leggyorsabban megtörténjen. És mindez elmosódik. Csak eltűnik, tudod? És akkor nyilvánvalóan nagyon - nem tudom, jövedelmező, gondolom, hogy végül is lesz - megnyílik egy memóriában lévő adatbázis, amely megpróbálta elfoglalni azt a helyzetet, hogy a nagy adatbázisok, az Oracle és a Microsoft, az SQL Szerver és az IBM DB2, az elfoglalt a memóriaterületen, és nagyon érdekes volt látni, hogy miként haladnak előre, és megteszik.
Beszéljünk a memória kaszkádról; csak említésre méltó. Ez is az oka ennek megemlítésére, az oka annak, hogy bedobtam, valójában az volt, hogy mindenki tudomást szerezzen róla, amikor itt az emlékről beszélek, ezek a rétegek, amelyekről beszélek, valójában memóriák. De hirtelen rájössz, amikor ezt megnézed, ez egy hierarchikus áruház, nem csak a memória. És tehát nagyjából minden, amit régen-régen megtanultunk a hierarchikus üzletről, szintén érvényes. Ez azt is jelenti, hogy minden memórián belüli adatbázisnak végig kell haladnia rajta, néhányan csak átmennek a RAM-on, tudod. És most egyre nagyobb és nagyobb, és most megabájtban mérve. De megvan az L1 gyorsítótár, amely százszor gyorsabb, mint a memória, az L2 gyorsítótár 30-szor gyorsabb, mint a memória, és az L3-gyorsítótár kb. 10-szer gyorsabb, mint a memória. Tehát, tudod, nagyon sok a technológia - nos, meglehetősen nagy mennyiségű technológia - elfogadta azt a stratégiát, hogy ezeket a gyorsítótárakat tárolóhelyként használja a dolgok végrehajtása felé, különös tekintettel az adatbázis-technológiára. Szóval, tudod, ez egy befolyás.
Aztán megjelent a 3D XPoint és az IBM PCM. És szinte a RAM sebessége, alapvetően ez az, amellyel mindkét eladó dicsekedhet. A felhasználási esetek valószínűleg különbözőek. A korai kísérlet még nem fejeződik be. Nem tudjuk, hogy ez hogyan befolyásolja a RAM használatát és a memóriában lévő adatbázis technológiáját. Ezután RAM van az SSD-hez képest. Jelenleg a RAM mintegy 300-szor gyorsabb, de természetesen ez a többszörös csökken. És az SSD és a lemez, amely körülbelül 10-szer gyorsabb, ha értem. Szóval, ilyen a helyzet. Ez hierarchikus üzlet. Másképpen nézve a memóriában természetesen teljesen más. Tehát a felső diagram két alkalmazást mutat, amelyek mindegyike valószínűleg egy adatbázishoz fér hozzá, de minden bizonnyal hozzáfér a rozsdás spinning adatokhoz. És ahogyan valójában a dolgokat a hálózaton keresztül áramlik, attól függően, hogy milyen függőségek vannak körül, az ETL-e van. Tehát, ez azt jelenti, hogy tudod, az adatok a rozsdás rozsdara kerülnek, majd a rozsda forog azért, hogy bárhová menjenek, és bárhová eljuthassanak, a forgó rozsda felé fordulnak, amely három lépés. És ne feledje, hogy a memória százezerszer gyorsabb lehet, mint a forgó lemez, és minden bizonnyal rájössz, hogy az adatok átvétele és a memóriába helyezése az egészet valóban meglehetősen másképp teszi.
Tehát azt gondolhatta, hogy mi történik a képernyőn megjelenő képernyőn, akkor azt is gondolhatta, hogy egy vagy más módon az ETL valójában csak az adatokról a memóriába kerül. Valójában valószínűleg nem ezt teszi; Valójában itt jobbra lehet a helyzet, ahol két alkalmazás valóban ugyanazt a memóriát ki tudja kapcsolni. Természetesen egy memóriában lévő adatbázis megadhatja ezt a képességet, mindaddig, amíg megvan a zár és minden más, amit körülötte rendeztek. Tehát ez nem csak a dolgok sebességét változtatja meg, ez megváltoztatja az alkalmazások és a teljes adatáramlás tényleges konfigurálásának módját is.
Szóval, ez egy hatalmas fajta hatás. Tehát a memória zavaró, igaz? És ki kell szereznünk mindazt, amit mondtam. A memóriában történő feldolgozás jelenleg gyorsító, de ez normává válik. Ezt fogják használni, az alkalmazás értékének megfelelően alkalmazva, és ez nagyon-nagyon érdekes, hogy az SAP valójában a memóriában lévő ERP szoftver verziójával jelenik meg. És a késés javítása akár három nagyságrendig is teljes mértékben lehetséges, és valójában még ennél is több, attól függően, hogyan csinálja. Tehát hatalmas javulást ér el a sebességben azáltal, hogy bemegy a memóriába. És az eredmény, az SAP HANA S / 4 - amelyet már kiadtak, azt hiszem, nos, az emberek azt mondják, hogy még mindig megjelent, de minden bizonnyal tavaly megjelent - ez egy játékváltó, figyelembe véve az SAP ügyfélkörét. Úgy értem, 10 000 cég van odakinn az SAP ERP-jét használva, és nagyjából mindegyik nagyvállalat, tudod. Tehát az a gondolat, hogy mindannyian ösztönözzék a memóriába való beilleszkedést és az alapvető tudásuk felhasználását, mivel az ERP szinte mindig alapvető alkalmazások, amelyeket a vállalkozások működtetnek, ez csak egy hatalmas játékváltó, és nagyon érdekes lesz. De természetesen ez mind nagyon jól hangzik, de intelligensen kell konfigurálni, és gondosan ellenőrizni kell. Nem olyan egyszerű, mint amilyennek hangzik.
Miután ezt mondtam, azt hiszem továbbadom a labdát, ki ez a fickó? Ó, ausztrál srác, Dez Blanchfield.
Dez Blanchfield: Nagyon vicces. Mindig kemény cselekedet követi, Dr. Robin Bloor. Köszönöm, hogy ma találtam. Szóval, nagy téma, de izgalmas. Tehát olyan képet választottam, amelyet gyakran felidézek, amikor a modern adat-tóra és a vállalati adattárházakra, valamint a kis adataimra gondolok. Tehát itt van ez a gyönyörű tó, amelyet hegyek és hullámok vesznek körül, és a hullámok összeomlanak ezen a sziklán. Ez egyfajta, ahogyan elképzeltem, hogyan néz ki manapság egy nagy adattó belsejében. A hullámok kötegelt feladatok, és a valós idejű elemzők adatot dobnak, ami sziklák. És amikor arra gondolok, mint egy fizikai tóra, ez egyfajta ébresztést hív fel nekem, hogy, tudod, az éppen építendő adattárházak méretét, az oka annak, hogy felbukkantunk ezzel az érmékkel és a egy adattó az, hogy nagyon nagyok és nagyon mélyek, és alkalmanként viharok is lehetnek bennük. És amikor megtesszük, mindig el kell döntenünk, mi okozza a viharot.
Tehát a dolog témájában számomra úgy tűnik, hogy ez a sziréna hívás a memória-számításba valóban nagyon erős és jó okból. Nagyon sok jelentős kereskedelmi és műszaki haszonnal jár. Ez egy pár órán át tartó vita egy másik napon. De az általános elmozdulás a memóriába épített számítástechnikához, először csak azt szeretném lefedni, hogy hogyan jutottunk ide, és mi teszi ezt lehetővé, mert ez valamilyen módon megalapozza azt a helyet, ahol egyes kihívások lehetnek elsődlegesek, és hogy mit kell tudnunk. és gondolkodásmódunkról, amikor elmozdulunk a hagyományos régi forgólemezektől, amelyek tárolják az adatokat, és a lemezen és a lemezen, valamint a memóriában és a memóriában, valamint a CPU-kba lapozzunk, mostantól csak az egész réteg egy részét eltávolítjuk, a forgó korong. Mert emlékezzen arra, hogy a számítástechnika nagyon korai napjaiban építészetileg hosszú ideig nem mozdultunk el a nagygéptől vagy a középtávú világtól, amit eredetileg magmemóriának és dobtárolónak gondoltak, tudod.
Mint Dr. Robin Bloor elmondta, az a megközelítés, amelyet az adatok számítógépes architektúrán történő mozgatására alkalmaztunk, valójában egy ideje, néhány évtized alatt, drámai módon nem változott. Ha gondolkodik azon a tényen, hogy tudod, a modern számítástechnika technikailag már körülbelül akkor létezik, ha megbocsátja a büntetést, kb. 60 páratlan évig, tudod, legalább hat évtizeddel, és abban az értelemben, hogy vesz egy dobozt a polcról, ahogy volt. Az új építészet felé való elmozdulás valóban az a gondolatomban jött létre, amikor a nagygépek és a középszintű, valamint a központi memória és a dobtároló architektúrák körüli gondolkodásból a bátor vagy a szuperszámítógép felé fordultunk, különösképpen a Seymour Cray kedveltéhez, ahol olyan dolgok voltak, mint a keresztirányú háttérképek. lett egy dolog. Ahelyett, hogy csak egy útvonal lenne az adatok átviteléhez a hátlapon vagy az alaplapon, amint manapság hívják. És az inline memória, tudod, manapság az emberek nem igazán gondolkodnak azon, hogy mit jelent valójában, amikor DIMM-et és SIMM-et mondnak. De a SIMM egyetlen inline memória, a DIMM pedig kettős inline memória, és ennél bonyolultabb is vagyunk. Azóta több tucat különböző típusú memória létezik különféle dolgokra: némelyik video, mások csak általános alkalmazásokhoz, mások beépített processzorokba.
Tehát ez a nagy váltás történt az adatok tárolásának és elérésének új módjára. Ugyanezt a váltást fogjuk átélni egy másik egész generációban, de nem annyira magában a hardverben, hanem a hardvernek az üzleti logikában és az adatlogikai rétegben történő átvételében, és ez egy újabb nagy paradigmaváltás az elmémben. .
De csak röviden, hogyan jutottunk ide. Úgy értem, a hardver technológia javult és drámaian javult. A CPU-k elhagyásától mentek, és a mag elképzelése meglehetősen modern koncepció volt. Most magától értetődőnek tekintjük, hogy telefonjaink két vagy négy magot tartalmaznak, és számítógépünknek kettő vagy négy, vagy akár nyolc magja van az asztalon, és nyolc, illetve 12 és annál többet, tudod, a 16-os és 32-ös még a szerverplatformon is . De valójában meglehetősen modern dolog, hogy a magok képessé váltak a CPU-kban, és hogy 32-bitesről 64-bitesre mentünk. Néhány nagy dolog történt ott: magasabb órasebességet kaptunk több magon, így párhuzamosan végeztünk dolgokat, és mindegyik mag több szálat futtathatott. Hirtelen sok mindent futtathatunk ugyanarra az adatra egyidejűleg. A hatvannégy bites címtávolság két terabájt RAM-ot adott nekünk, ami fenomenális fogalom, de most ez a helyzet. Ezek a többutas útvonalakkal rendelkező architektúrák, tudod, az alaplapok, egyszer csak egyszerre tudtak dolgokat tenni: hátra és előre. És mint a Cray számítástechnika és az akkori szuperszámítógép néhány kivitelének napjain, és az asztali számítógépekben és a szokásos üzlethelyiségben is, valamilyen asztali minőségű, állványra szerelt számítógépeken, mert valójában a legtöbb modern A PC-k most átmentek a mainframe, a középszintű, a mikroasztalok korszakán, és újra kiszolgálókká alakítottuk őket.
És a szuperszámítógép képességeinek nagy részét, az a szuperszámítógép-minőségű kivitelét a szokásos, elkülönített alkatrészekbe helyezték. Tudod, manapság az a gondolat, hogy nagyon olcsó rack-beilleszthető számítógépeket készítenek, és több száz, ha nem több ezer állványra rakják őket, és nyílt forráskódú szoftvereket futtatnak rájuk, mint a Linux, és telepítik az SAP HANA-hoz hasonló szerepet, te tudod, ezt gyakran magától értetődőnek tekintjük. De ez egy nagyon új, izgalmas dolog, és bonyolultságával jár.
A szoftver is jobb lett, különösen a memóriakezelés és az adatok particionálása. Ezzel nem foglalkozom sok részlettel, de ha megnézzük az elmúlt 15 vagy annál nagyobb, vagy annál kevésbé nagy változást, hogyan kezeljük a memóriát, különös tekintettel az adatokra a RAM-ban és az adatok particionálására a RAM-ban, úgy, ahogyan Dr. Robin Bloor korábban jelezte, vagy arra utalt, tudod, hogy a dolgok egyszerre tudnak olvasni és írni, anélkül, hogy egymásra hatással lennének, ahelyett, hogy várakozási idők lennének. Sok nagyon hatékony szolgáltatás, például a tömörítés és a titkosítás on-chip. A titkosítás egyre fontosabb dolog, és ezt nem feltétlenül kell megtennünk a szoftverben, a RAM-ban, a CPU-térben, most, hogy ez valójában a chipen történik natív módon. Ez drámaian felgyorsítja a dolgokat. És az elosztott adattárolás és -feldolgozás, ismét olyan dolgok, amelyekről korábban feltételeztük, hogy a szuperszámítógépek és a párhuzamos feldolgozás dolgai, ezt most már magától értetődőnek tekintjük az SAP HANA, a Hadoop és a Spark kedvelőinek tereiben és így tovább.
Tehát ennek lényege, hogy ez a nagy teljesítményű számítástechnika, a HPC képességei elérték a vállalkozást, és most a vállalkozás élvezi az előnyeit, amelyek azzal járnak, mint a teljesítménynövekedés és a technológiai tér, valamint a műszaki és a kereskedelmi előnyök, mert tudod, hogy az érték csökkentésére fordított idő drámaian csökken.
De ezt a képet egy olyan történetről használom, amelyet egy ideje olvastam egy úriembertől, aki Lego-ból épített egy PC-t, mert mindig eszembe jut, amikor ezekre a dolgokra gondolok. És ez az, hogy nagyszerű ötletnek tűnik akkor, amikor elkezdi építeni, majd félúton átjut, és rájössz, hogy valóban nagyon bonyolult összerakni az összes Lego-bitet, és egy szilárd, elég szilárd dolgot elkészíteni. az alaplap behelyezése és így tovább, ez felépítheti a számítógépes tokot. És végül rájössz, hogy az összes apró bit nem ragaszkodik egymáshoz, és egy kicsit óvatosnak kell lenned attól, hogy melyik kis bittel ragaszkodsz össze, hogy szilárd legyen. És ez egy nagyon aranyos ötlet, de egy ébresztőóra, amikor félúton érkezik és rájössz: “Hmm, talán csak 300 dolláros PC-t kellett volna vásárolnom, de most befejezem és megtanulok tőle valamit.”
Számomra ez nagyszerű analógia ehhez a nagyon összetett platformok felépítéséhez, mert nagyon jó és jó azt felépíteni, és olyan környezetbe kerülni, ahol útválasztók és kapcsolók, valamint szerverek és állványok vannak. És a CPU-k, a RAM és az operációs rendszer együtt vannak csoportosítva. És te is tetted a HANA-hoz hasonlót az elosztott memória-feldolgozáshoz, az adatok tárolásához és az adatkezeléshez. Ehhez felépíti az SAP veremét, megkapja az adatbázis képességeit, majd betölti az adatokat és az üzleti logikát, és elkezdi alkalmazni néhány olvasást, írást és lekérdezést stb. Tartsa fenn az I / O tetejét, és ütemeznie kell a dolgokat, kezelnie kell a munkaterhelést és a többéves munkát és így tovább. Ez a köteg nagyon összetetté válik, nagyon gyorsan. Ez önmagában egy összetett verem, ha csak egy gépen van. Szorozzuk meg úgy, hogy 16 vagy 32 géppel nagyon, nagyon nem triviális lesz. Ha százszor és végül több ezer gépet szaporít fel, és 100 terabyte-ról petabájtméretre halad, félelmetes koncepció, és ezekkel a valóságokkal dolgozunk most.
Tehát néhány olyan dologgal ér véget, amelyek szintén hozzájárultak ennek a világnak a megváltoztatásához, azaz a lemezterület nevetségesen olcsó lett. Tudod, egyszer csak 380–400 ezer dollárt költöttek egy gigabájt merevlemezre, amikor egy hatalmas dob volt, olyasvalami, amihez targoncára volt szükség. Manapság ez egy vagy két cent gigabájt árufuvarozási helyig terjed. És a RAM ugyanezt tette. Ez a két J-görbe mindkét gráfban, egyébként, egy-egy évtized, tehát más szavakkal, a tízéves, a 20 éves árcsökkentés két blokkjára nézünk. De két J-görbére bontottam őket, mert végül a jobb oldalon csak pontozott vonal lett, és nem láttad a részleteket, ezért átméreteztem. Egy gigabájt RAM 20 évvel ezelőtt körülbelül hat és fél millió dollár volt. Manapság, ha három-négy dollárnál többet fizet egy gigabájt RAM-ért az áru hardverért, amelyet kirabolták.
Az elmúlt két évtized jelentős csökkenése az árcsökkenés azt jelentette, hogy most már nemcsak a megabájt, hanem a terabyte szint mellett is áthelyezhetjük a lemezterületet és egyenesen a RAM-ba, és a RAM-ot úgy kezeljük, mint a lemezét. A kihívás ezzel szemben az volt, hogy a RAM natív időnként változik - ez azt jelenti, hogy egy rövid ideig tart -, tehát ki kellett találnunk az ellenálló képesség biztosításának módjait abban a térben.
Tehát itt az a véleményem, hogy a memóriában történő számítás nem a gyenge szívű emberek számára szól. Érdekes kihívás e nagyon nagy léptékű memória-adatok zsonglőrje és a körülötte történő feldolgozás; amint már korábban jeleztem, ez nem a gyenge szívű emberek számára. Tehát egy dolog, amit a nagyszabású és nagy sűrűségű memória-számítástechnika tapasztalatából megtanultunk, az, hogy az összetett bonyolultság számos területen kockázatot jelent.
De nézzük csak megfigyelési és reagálási szempontból. Amikor az adatokra gondolunk, akkor a lemezterületen indulnak, a lemezekben található adatbázisokban elhelyezésre kerülnek, és a memóriába nyomjuk. Amint a memóriába kerül és eloszlik, és vannak másolatai, sok másolatot használhatunk, és ha bármilyen változás megtörténik, a memória szintjén visszatükröződik, ahelyett, hogy tovább kellene mennünk és ki kellene mennünk a hátlapon két különböző szint, be- és kikapcsol a memóriából. Végül megkaptuk ezt a hiper skála hardverplatformot, amely lehetővé teszi számunkra, hogy ezt megtehessük. A hiperskalibrációról beszélve nevetségesen sűrű szinteknél és a nagyon nagy sűrűségű memóriánál a CPU-k, a magok és a szálak nagyon nagy sűrűségű száma nagyon nehéz. Most nagyon bonyolult hálózati patológiáink vannak ennek támogatására, mivel az adatoknak valamikor át kell haladniuk a hálózaton, ha csomópontok és fürtök között haladnak.
Tehát a végén az eszközhiba-redundancia problémává válik, és meg kell figyelnünk az eszközöket és azok részeit. Rendszerint be kell építenünk egy rugalmas adathiba redundanciát a platformon, és figyelnünk kell azt. Be kell építeni az elosztott adatbázis rugalmasságát, így figyelemmel kell kísérnünk az adatbázis-platformot, és be kell raknunk. Figyelemmel kell kísérnünk az elosztott feldolgozási ütemezést, az egyes folyamatokban zajló eseményeket egészen a lekérdezésig és a lekérdezésig, valamint a lekérdezés útját, valamint a lekérdezés felépítésének és végrehajtásának módját. Hogyan néz ki, ha valaki SELECT * -et végzett a „blah-on”, vagy valóban nagyon okos és jól felépített lekérdezést hajtott végre, amely alapján megkapja a névleges, minimális mennyiségű adatot, amely a hátlap architektúráján átjut? Van többmunkás munkaterhelés, több felhasználó és több csoport fut ugyanazon vagy több munkaterheléssel, kötegelt jobokkal és valós idejű ütemezéssel. És megvan a szakaszos és valós idejű feldolgozás keveréke. Egyes dolgok csak rendszeresen futnak - óránként, napi, hetente vagy havonta -, más dolgokra van szükség. Lehet, hogy valaki ült egy tablettával, és valós idejű jelentést szeretne készíteni.
És ismét arra a következtetésre jutunk, hogy az ezekben felmerülő összetettség nem csak kihívás, hanem nagyon félelmetes. És ezt a valóság-ellenőrzést elvégezzük, hogy egyetlen teljesítménnyel kapcsolatos kérdés, csak egy teljesítménnyel kapcsolatos kérdés önmagában befolyásolja az egész ökoszisztémát. És tehát ez a nagyon szórakoztató kihívás érkezik: megtudjuk, hol vannak a hatások? És megvan ez a kihívás: reaktív vagy proaktív vagyunk? Valós időben figyeljük a dolgot, látva, hogy valami „felrobban”, és reagálunk rá? Vagy láttunk valamiféle tendenciát és rájöttünk, hogy proaktívan be kell lépnünk vele? Mivel a kulcs az, hogy mindenki gyors, olcsó és könnyű dolgot akar. De végül ezekkel a forgatókönyvekkel végzünk szerepet, amelyekre utalok, és a kedvenc Donald Rumsfeld-összecsapásomat - amely véleményem szerint alkalmazható a nagy komplexitású forgatókönyvek mindegyikénél - és ez az, hogy ismertek ismertünk, mert ez valami terveztük és építettük, és a tervek szerint fut. Ismert ismeretlenekkel rendelkezünk abban, hogy nem tudjuk, ki futtatja mit, mikor és hol, ha igény van. És vannak ismeretlen ismeretlen személyek, és ezeket kell ellenőriznünk és ellenőriznünk. Mivel a valóság az, hogy mindannyian tudjuk, nem tudsz kezelni valamit, amit nem tudsz mérni.
Tehát ahhoz, hogy a CPU ütemezésének ellenőrzéséhez a megfelelő eszközök és a megfelelő képességek rendelkezzenek, keresse meg a várakozási időket, és megtudja, miért kell a dolgoknak a csővezetékek ütemezett sorában várni. Mi történik a memóriában, milyen felhasználást hajtanak végre, milyen előadást kapunk ki a memóriából? A cuccokat helyesen particionálják, szét vannak-e osztva, van-e olyan csomópontok, amelyek másolatot tartalmaznak ahhoz, hogy megbirkózzanak a rá dobott munkaterheléssel? Mi történik a folyamat végrehajtásával az operációs rendszer folyamataitól távol? Maguk a futó munkahelyek, az egyes alkalmazások és az őket támogató démonok? Mi történik ezekben a folyamatokban, különösen a lekérdezések felépítése, és hogyan hajtják végre és lefordítják ezeket a lekérdezéseket? És ezeknek a folyamatoknak az egészsége egészen a halmozott állapotban van? Ismét tudja, hogy a várakozási időkhöz igazodik-e a helyes ütemezés, kell-e várnia, hol vár, vajon memória olvasásra vár, I / O, CPU, I / O a hálózaton keresztül a végfelhasználónak ?
És visszatérve arra a pontra, amelyet éppen csak megemlítettem, mielőtt összefoglaltam, vagyis hogyan közelítjük meg a kérdések megoldási és válaszadási idejét ezekre? Valós időben figyeljük és reagálunk a dolgokra, ami a legkevésbé ideális forgatókönyv, de még akkor is jobb, ha ezt megtesszük, mint hogy nem tudjuk, és hívjuk az ügyfélszolgálatot, és mondjuk, hogy valami rosszra fordult, és meg kell nyomon követnünk. ? Vagy proaktívan csináljuk, és arra gondolunk, mi jön a sorban? Tehát más szavakkal látjuk, hogy hiányzik a memória, és további csomópontokat kell hozzáadni? Trend elemzést végezünk, kapacitástervezést végezzünk? És mindezt követve nyomon követjük a történelmi végrehajtási időket és gondolkodunk a kapacitástervezésen, vagy valós időben figyeljük, proaktív módon ütemezzük az ütemezést és hajtjuk végre a terheléselosztást? És tisztában vagyunk-e a munkaterheléssel, amely elsősorban fut? Tudjuk, ki csinál mit és miért?
A memóriában lévő számítások nagyon nagy teljesítményűek, de ezzel a képességgel ez szinte az egyik, például egy betöltött fegyver, és élő lőszerrel játszol. Végül lábbal is lőhet, ha nem vigyázol. Tehát, a memóriában lévő számításnak ez a nagysága azt jelenti, hogy sokkal gyorsabban tudunk futtatni a nagyon elosztott és diszkrét adatkészleteken. De aztán ekkor nagyobb igény mutatkozik a végfelhasználóktól. Megszokják ezt a hatalmat, és azt akarják. Már nem számítanak arra, hogy a munkák heteket vesznek igénybe, és a jelentések egyszerű, régi papírban jelennek meg. És aztán mindezek alatt a mindennapi karbantartást körülvettük a javítások, frissítések és frissítések körül. És ha gondolkodik a 24 órás, a memóriában levő számításokkal történő feldolgozásról, az adatok kezeléséről, az egész munkaterhelés kezeléséről, az mind memóriában van, technikailag az ideiglenes platformon, ha javításokat, frissítéseket és frissítéseket akarunk alkalmazni a ott számos más irányítási és felügyeleti kihívással is jár. Tudnunk kell, hogy mit tehetünk offline módban, mikor frissíthetjük és mikor hozhatjuk vissza online. És ez vezeti a végső ponthoz, vagyis az, hogy mivel egyre összetettebbé válunk ezekben a rendszerekben, az nem valami olyan, amit az ember megtehet, csak hogy hüvelykujját szopja és fülét húzza. Nincs már valamiféle bélérzés. Valóban szükségünk van a megfelelő eszközökre a számítástechnika és az adatkezelés magas szintű teljesítményének kezeléséhez és biztosításához.
És ezt szem előtt tartva átadom az IDERA barátainknak, és meghallgatom, hogy miként fogadták el ezt a kihívást.
Bill Ellis: Nagyon köszönöm. Odaadom a képernyőm, és itt megyünk. Tehát nagyon megalázó, ha figyelembe vesszük az összes technológiát és az összes embert, aki előttünk jött, hogy elérhetővé tegyük ezt a 2017-ben elérhető cuccot. A SAP HANA munkaterhelés-elemzéséről fogunk beszélni - alapvetően egy adatbázis-megfigyelő megoldás: átfogó, ügynökök nélküli, valósidejű, előzményeket épít fel, és így láthatja, hogy mi történt a múltban. Az SAP S / 4 HANA jobb, gyorsabb és olcsóbb lehetőségeket kínál. Nem azt mondom, hogy olcsó, csak azt mondom, hogy olcsóbb. Az a fajta, hogy hagyományosan az történt, hogy lesz egy fő termelési példánya - valószínűleg az Oracle-en fut egy nagyobb üzletben, potenciálisan SQL Server -, és akkor ezt az ETL-folyamatot fogja használni, és az igazság többféle fajtájú verziója lesz. . És ez nagyon drága, mert a hardverért, az operációs rendszerért és az Oracle licencért fizettek az egyes környezetek mindegyikéért. És emellett szüksége lesz emberekre, hogy összehangolják az igazság egyik verzióját az igazság következő verziójával. Tehát ez a több változatú ETL feldolgozása csak lassú volt és nagyon-nagyon nehézkes.
Tehát a HANA, alapvetően egy HANA példány, helyettesítheti az összes többi példányt. Tehát olcsóbb, mert egy hardverplatform, egy operációs rendszer, a többszörösek helyett. Tehát az S / 4 HANA valóban mindent megváltoztat, és alapvetően az SAP fejlődését nézi az R / 2-ről R / 3-ra, a különféle fejlesztőcsomagokra. A régi rendszer 2025-ig áll rendelkezésre, tehát nyolc év van hátra, amíg valóban a migrációra kényszerülsz. Bár látjuk az embereket, tudod, belefűzik a lábujjaikat ebbe, mert tudják, hogy jön, és végül, tudod, az ECC a HANA-n fog futni, így valóban fel kell készülni erre és meg kell értenie a technológiát.
Tehát egy adatbázis, nincs ETL folyamat, nincs másolat, amelyet össze kell egyeztetni. Tehát ismét gyorsabb, jobb és olcsóbb. A HANA a memóriában van. Az SAP biztosítja a szoftvert, Ön pedig a hardvert. Nincs összesített táblázat. Az egyik dolog, amire ők utalnak, amikor erre gondolkodnak, hogy nem akarnak belemenni ebbe a helybe, csak a lehető legnagyobb szervert vásároljuk meg. Azt sugallják, hogy Ön, valamiféle, megfelelő méretű legyen az SAP-tájkép idő előtt, és alapvetően azt mondják, hogy ne válasszanak 20 éves adatot. Úgy gondolom, hogy az archiválást oly módon használják ki, amelyet az IT-ben általában használnak, nemcsak az SAP üzletekben. És tehát a következő dolog az, hogy az SAP valójában sok időt töltött át natív kódjának átírásával, hogy ne használja a SELECT * -t. A SELECT * az összes oszlopot adja vissza a táblázatból, és ez különösen drága egy oszlopos adatbázisban. És tehát ez nem jó ötlet az SAP HANA számára. Tehát a sok testreszabással, sok jelentéssel bíró üzleteknél ezt meg kell keresni, és meg kell határoznia az oszlopneveket, amikor mindent áttesz a HANA-ba.
Szeretnénk mondani, hogy a HANA nem csodaszer. Mint minden adatbázis, minden technológia, ezt is figyelemmel kell kísérni, és amint azt korábban említettem, számokra van szüksége a többlet kezeléséhez, méréssel méréssel. Az egyik dolog, amiről az IDERA területén beszélek, az az, hogy minden üzleti tranzakció kölcsönhatásba lép a rekord rendszerrel, és ebben az esetben a HANA lesz. Így a HANA az SAP tranzakciók végrehajtásának, a végfelhasználói élménynek az alapjává válik. Szóval elengedhetetlen, hogy folyamatosan futtassa a legnagyobb sebességet. Ez valószínűleg egyetlen kudarcpontmá válik, és az emberekkel való beszélgetés során ez felbukkanhat ott, ahol van egy végfelhasználó, és valószínűleg használja ezt a valósidejű adatot, és van egy ad hoc lekérdezésük, amely potenciálisan nem egészen jobb. Lehet, hogy nem csatlakoznak az asztalokhoz, és létrehoztak egy külső csatlakozást, egy partizán terméket, és alapvetően sok erőforrást fogyasztanak. A HANA ezt végül felismeri, és megöli az ülést. Tehát ott van az építészet kritikus része, amely lehetővé teszi, hogy ezt ténylegesen rögzítse a történelemben, így láthatja, hogy mi történt a múltban, és felismerheti ezeket a helyzeteket.
Vessen egy pillantást az SAP HANA munkaterhelésének elemzésére. Ez az 1. verzió, tehát nagyon felhívjuk Önt, hogy csatlakozzon hozzánk az utazáshoz, és ez az IDERA terméke. Ez átfogó, mégis egyszerű. Valós idejű trenddel. Gazdaszervezet, például egészség. Követjük a várakozási állapotokat, az SQL lekérdezéseket, a memóriafelhasználókat és a szolgáltatásokat. Szóval, a GUI így néz ki, és már a denevérről láthatja, hogy webes. Valójában megnyitottam ezt a megoldást, amely élőben fut a rendszeren. Van néhány kulcsfontosságú dolog, amelyet át akar vetni. Valamint felosztottuk a különféle munkaterületeket. A legfontosabb az, hogy mi történik a host szinten a CPU kihasználtsága és a memória kihasználása alapján. Határozottan nem akarja eljutni cserélő vagy csúszó szempontra. És akkor alapvetően azon dolgozik, amely a trend kialakításában zajlik, a válaszidőtől, a felhasználóktól, az SQL utasításoktól, azaz attól, hogy mi vezérli a rendszeren végzett tevékenységeket.
Az IDERA egyik dolga az, hogy tudod, az adatbázisban semmi sem történik, amíg nincs tevékenység. És ez a tevékenység SQL utasítások, amelyek az alkalmazásból származnak. Tehát az SQL utasítások mérése alapvető fontosságú a gyökér ok felderítéséhez. Tehát menjünk tovább és fúrjuk be. Tehát a host szintjén valójában átnézhetjük a memóriát, nyomon követhetjük az időt, a host CPU kihasználtságát. Lépjen hátra, és megnézheti a COBSQL utasításokat. Az egyik dolog, amit látni fog az építészet oldalán, az, hogy ezt az információt a HANA-n kívül tárolják, tehát ha valami történne a HANA-val, alapvetően az információkat fogjuk felvenni, Isten tiltása nélkül, egy elérhetetlen helyzethez. . Azt is rögzíthetünk mindent, ami a rendszeren történik, hogy tiszta láthatóságot biztosítson. És az egyik dolog, amit megteszünk, az, hogy az SQL utasításokat súlyozott sorrendben mutatjuk be. Tehát, figyelembe veszi a végrehajtások számát, és ez az összesített erőforrás-felhasználás.
Így itt bejuthat az egyes mutatókba - mikor hajtotta végre az SQL utasítás? És akkor az erőforrás-felhasználást nagyrészt a végrehajtási terv vezérli, és így ezt folyamatosan tudjuk rögzíteni. A HANA a memóriában van. Nagyon párhuzamos. Minden asztalon vannak elsődleges indexei, amelyeket egyes üzletek úgy döntnek, hogy másodlagos indexet építenek bizonyos teljesítményproblémák megoldására. És tehát nagyon értékes lehet annak ismerete, hogy mi történt az egyes SQL utasítások végrehajtási tervével. Megvizsgáljuk a szolgáltatásokat és a memóriafelhasználást is, idővel ábrázolva. Az architektúra: tehát ez egy önálló megoldás, amelyet letölthet a weboldalunkról, és az architektúra az, hogy webes.
Több felhasználó csatlakozhat egy adott példányhoz. Figyelemmel kísérheti az SAP HANA helyi példányait. És négy hetes gördülő történetet tartunk a tárolónkban, és ez az önkezelés. Ennek telepítése meglehetősen egyszerű. Szüksége van egy Windows Server-re. Töltse le. A legtöbb Windows-kiszolgáló beépített .NET-keretrendszerrel lesz ellátva, és licenchez tartozik. Ezért elmenne a telepítővarázslóhoz, amelyet a Setup.exe hajt végre, és ez valójában megnyit egy képernyőt, licencszerződést, és egyszerűen le fogja dolgozni ezt a körvonalat a „Next” gombra kattintva. És így, hova szeretné a HANA telepíteni kell? Következő az adatbázis tulajdonságai, és ez lesz a kapcsolat az SAP HANA-val, tehát ez a HANA példány ügyetlen figyelése. És akkor alapvetően áttekintést adunk, ez a port, amelyen alapértelmezés szerint kommunikálunk. Kattintson az „Install” gombra, és alapvetõen elindul a HANA, és elkezdi az elõzmények elkészítését. Szóval, csak egy kevés információt a mérettáblázatról. Legfeljebb 45 HANA példányt figyelhetünk, és ezt csúszó méretben szeretné használni, hogy meghatározza a szükséges magok számát, memóriáját és lemezterületét. És ez feltételezi, hogy teljes négyhetes gördülési előzményei vannak bejáratva.
Tehát, csak egy gyors áttekintésként, a szerver állapotát, a példányok állapotát, a CPU / memória felhasználását vizsgáljuk. Melyek a memóriafogyasztók, mi a tevékenységet előmozdító tényezők, milyen szolgáltatások? Az SQL utasítások létfontosságúak - mik a végrehajtási állapotok? Mutassa meg a végrehajtási terveket, mikor hajtották végre a dolgok trendjét? Ez valós idejű és a történelem történetét nyújtja Önnek. És amint említettem, mivel történelemünk különbözik a HANA-tól, olyan tárgyakat fogunk elfogni, amelyek elévültek és a HANA történetéből kitörtek. Annak érdekében, hogy a különálló előzmények miatt láthassa a rendszer valódi erőforrás-felhasználását.
Tehát, amint már említettem, az IDERA honlapján, a Termékek alatt könnyen megtalálhatod ezt. Ha szeretné kipróbálni, akkor szívesen látja. Nézze meg, hogyan nyújt információt az Ön számára, és további információkat talál a weboldalon. Tehát az érdekelt felek több mint örömmel veszik figyelembe ezt. Az IDERA által kínált portfóliótermékekben megtalálható egy SAP ECC tranzakciós monitor is, amelyet Precise for SAP-nak hívnak. És amit csinál - akár portált használ, akár csak egyenes ECC-t használ - az valójában rögzíti a végfelhasználó tranzakcióit kattintásról lemezre egészen az SQL utasításig, és megmutatja, mi történik.
Most csak egy összefoglaló képernyőt mutatok neked. Van néhány elvitel, amelyet szeretnék, ha szerezne ezen az összefoglaló képernyőn. Ez az Y tengely válaszideje, az X tengely ideje plusz a nap, és ebben a tranzakció nézetben megmutatjuk az ügyfél idejét, a sorba állítási időt, az ABAP kód idejét, az adatbázis idejét. Rögzíthetjük a végfelhasználói azonosítókat, a T-kódokat, és valójában kiszűrheti és megmutathatja a kiszolgálókat egy áthaladott tranzakción keresztül. Szóval sok üzlet a táj előtagját futtatja a VMware alatt, így valójában meg tudja mérni, hogy mi történik az egyes kiszolgálókon, és nagyon részletes elemzésbe kerülhet. Tehát ez a tranzakció nézet a végfelhasználó tranzakcióira vonatkozik a teljes SAP tájban. Ezt megtalálhatja weboldalunkon a Termékek APM eszközök alatt, és ez lenne az a SAP megoldás, amely van. A telepítés ehhez kissé bonyolultabb, tehát nem csak töltse le és próbálja ki, mint a HANA esetében. Ez egy olyan dolog, ahol együtt dolgozhatnánk azért, hogy megtervezzük és kivitelezzük a teljes tranzakciót az Ön számára.
Tehát, csak egy harmadik gyors áttekintés, az SAP HANA munkaterhelésének elemzése, átfogó, ügynökök nélküli, valós idejű, előzményeket kínál. Lehetőséget kínálunk letöltésére és kipróbálására az Ön webhelyén.
Tehát ezzel átadom az időt Ericnek, Deznek és Dr. Bloornak.
Eric Kavanagh: Igen, talán Robin, van tőled valami kérdés, majd Dez Robin után?
Dr. Robin Bloor: Oké. Úgy értem, az első dolog, amit szeretnék mondani, nagyon szeretem a tranzakciós nézetet, mert pontosan ezt akarom ebben a helyzetben. Nagyon sok munkát végeztem - jó, régen ez már régen - teljesítményfigyelést végeztem, és ez volt az a fajta; akkoriban nem volt grafika, de ezt a legjobban szerettem volna csinálni. Annak érdekében, hogy így vagy úgy befecskendezze magát, bárhol is van a probléma.
Az első kérdésem az, hogy tudod, a legtöbb ember valamilyen módon vagy más módon végrehajtja az S / 4-et. Amikor részt vesz az S / 4 adott megvalósításában, felfedezte, hogy azt jól hajtották végre, vagy végül is tud valami olyan dolgot, amely miatt az ügyfél újrakonfigurálni szeretne? Úgy értem, hogy megy mindez?
Bill Ellis: Nos, minden üzlet kicsit más. És vannak különböző felhasználási minták, vannak különböző jelentések. Azok a webhelyek, amelyek eseti jelentést készítenek, úgy értem, hogy ez valójában egyfajta helyettesítő karakter a rendszerben. Tehát az egyik kulcsfontosságú dolog a mérés megkezdése és annak kiderítése, hogy mi a kiindulási helyzet, mi az a normál egy adott helyszínen, hol van az adott hely, felhasználási mintáik alapján, hangsúlyozva a rendszert. És akkor végezzen onnan módosításokat. A monitorozás optimalizálása általában nem egyszeri, hanem egy folyamatban lévő gyakorlat, mellyel figyeli, hangolja, megcsiszolja és javítja a rendszert a végfelhasználói közösség számára, hogy az üzlet hatékonyabban szolgálhasson.
Dr. Robin Bloor: Rendben, tehát amikor végrehajtja - úgy értem, tudom, hogy ezt egy nehéz kérdést kell megválaszolni, mert a megvalósítás méretétől függően változik -, de mennyi erőforrást igényel az IDERA megfigyelési képessége, mekkora forrást igényel ? Valamit megváltoztat, vagy az, csak nem zavarja? Hogyan működik?
Bill Ellis: Igen, azt mondanám, hogy a felső rész körülbelül 1–3 százalék. Sok üzlet nagyon hajlandó ezt feláldozni, mivel potenciálisan ezt optimalizálás céljából megvásárolhatja. A felhasználási szokásoktól függ. Ha teljes képet készít, akkor az függ a megfigyelt egyedi technológiáktól. Tehát a futásteljesítmény fajtája változó, de amint arról beszéltünk, határozottan jobb, ha egy kicsit költenek tudni, mi folyik, mint hogy vakon futjunk. Különösen az lenne, ha tudod, itt vagyunk januárban, amikor belekezdenek az évek feldolgozásába, és összeszedik a 12 hónapos adatokat. Tudod, ez a teljesítmény, a jelentések eljuttatása a szabályozó szervezeteknek, a bankoknak és a részvényeseknek elengedhetetlen a kritikus üzleti teljesítmény szempontjából.
Dr. Robin Bloor: Igaz. És nagyon gyors, a szempontjából - mivel azt hiszem, ott vagy az SAP-oldalak egész sorával. - Mennyire halad az SAP-ügyfélkör az S / 4 felé? Úgy értem, hogy valami, amit tudsz, létezik egyfajta lelkes ügyfelek lavinaja, vagy csak egy állandó csepegés? Hogy látod ezt?
Bill Ellis: Azt hiszem, néhány évvel ezelőtt azt mondanám, hogy lábujj volt. Most azt mondanám, hogy az emberek valamilyen módon térdig vannak. Azt hiszem, hogy tudod, figyelembe véve az idővonalat, amellyel az emberek a következő néhány évben valóban elmerülnek a HANA-ban. Tehát a megfigyelés, az átalakulás, tudod, azt hiszem, hogy az ügyfelek többsége valamilyen módon együtt van a tanulási görbén. És úgy gondolom, hogy nem vagyunk egészen a lavinánál, amint azt állította, de szerintem a HANA-ra való átalakulás csúcsán vagyunk.
Dr. Robin Bloor: Rendben, tehát a már látott webhelyek vonatkozásában a HANA-t más alkalmazásokhoz is adaptálják, vagy valamilyen módon teljesen felhasználják ezt a készítést cucc dolgozik? Mi a kép ott?
Bill Ellis: Igen, gyakran az emberek integrálják az SAP-t más rendszerekkel, attól függően, hogy milyen modulokat és így tovább, tehát van egy kicsit. Még nem igazán látom, hogy az emberek más alkalmazásokat telepítenek a HANA-n. Ez minden bizonnyal megtehető. Tehát inkább az SAP infrastruktúra körüli tájon fekszik.
Dr. Robin Bloor: Azt hiszem, jobb, ha átadlak Deznek. Megdöbbent az ideje. Dez?
Dez Blanchfield: Köszönöm. Nem, ez mind jó. Két nagyon gyors, csak a téma beállításához. Az SAP HANA már néhány éve működik, és az embereknek lehetősége volt megfontolni ezt. Ha durván becsülné meg a rajta futó népek százalékos arányát - mivel nagyon sok ember működteti ezt a cuccot -, mit gondol, mi az a piaci százalék, amelyről tudod, hogy jelenleg ismeri a piacot, a hagyományos SAP megvalósításoktól a HANA SAP-ig? Az 50/50, 30/70 pontokat nézzük meg? Milyen típusú piaci részesedését látja azok az emberek, akik átalakultak és megmozdultak a népekkel szemben, akik csak hátráltatnak, és arra várnak, hogy a dolgok javuljanak, javuljanak, megváltozzanak, vagy akármi is legyen?
Bill Ellis: Igen, a szempontból valóban azt tennék, hogy a százalékot 20 százalék körülire tegyem. Az SAP általában hagyományos vállalkozás. Az emberek általában nagyon konzervatívak, és így az emberek húzzák a lábát. Azt hiszem, attól is függ, tudod, hogy régóta üzemelteti az SAP-t, vagy olyan SMB-k, amelyek esetleg nemrégiben telepítették az SAP-t? Tehát számos tényező létezik, de összességében nem hiszem, hogy a százalékos arány 50/50. Azt mondanám, hogy 50 százalék legalább gömbölyödik, és a HANA fut valahol az adatközpontjában.
Dez Blanchfield: Az az érdekes elvitel, amelyet korábban adtál nekünk, az volt, hogy ez bizonyos értelemben véve végrehajtott tény, és hogy az óra fizikailag és szó szerint ketyeg az átmenet idején. Szerintetek ezt gondolják-e az emberek ennek során? Mi az a népi megértés, hogy ez egy átmeneti periódus a platformon, ez nem csak egy lehetőség, hanem alapértelmezetté válik?
És az SAP szempontjából biztos vagyok benne, hogy így mozognak, mivel jelentős teljesítménybeli versenyelőnyök vannak, de azt hiszem, az is, azt hiszem, a platform hátralévő irányítását harcolják ahelyett, hogy egy harmadik- párt adatbázis, most visszahozják saját platformjukra. Gondolod, hogy a vállalatok valóban megkapták ezt az üzenetet? Gondolod, hogy az emberek ezt megértik, és most ehhez készülnek? Vagy még mindig egyfajta egyértelmű dolog, gondolod, ki a piacról?
Bill Ellis: Nem hiszem, hogy az SAP félénk a kommunikációt illetően, és az emberek, akik a SAPPHIRE-ba mentek, mindenütt láthatták a HANA-t. Tehát, azt hiszem, az emberek jól tudják, de az emberi természet, mi az, mi az, tudod, néhány ember valamiféle húzza a lábát egy kicsit.
Dez Blanchfield: Mert azt hiszem, hogy miért tettem fel ezt a kérdést, és meg kell bocsátania nekem, de azért egyetértek. Azt hiszem, nem féltek félbeszakítani. Úgy gondolom, hogy a jel sok szempontból eltűnt. És egyetértek veled - nem tudom, hogy még mindenki ugrott. Tudod, a tradicionális vállalkozás, a nagyon nagyvállalatok, amelyek ezt irányítják, sok szempontból még mindig nem éppen a lábát húzzák, hanem csak megpróbálják megbirkózni a műszak összetettségével. Mert azt hiszem, hogy az egyetlen dolog, amelyet az eszköz, és természetesen a mai demonstráció kiemelte, és számomra az egyik kulcsfontosságú elvitel, azt szeretném, ha mindenki hallgatna és hangolna be ma, hogy üljön fel és figyelmesen figyeljen rá, az, hogy eszköz, amely a fejemben egyszerűsíti ezt a folyamatot. Azt hiszem, van egy csomó nagyon ideges CIO és azok csapata, akik gondolkodnak: Hogyan lehet átmenni a hagyományos RDBMS-től, relációs adatbázis-kezelő rendszerektől, amelyeket évtizedek óta ismertünk, egy teljesen új paradigmára a számítás és tárolási menedzsment olyan térben, amely még mindig viszonylag bátor? ” De ez sok szempontból ismeretlen, és nagyon kevés ember hajtotta végre ezt a változást más területeken, hogy nem olyan, mintha van egy másik üzletáguk, amely már a memória-számításhoz költözött. Szóval, ez egy minden vagy semmi lépés a fejükben.
Tehát az egyik dolog, amit tőle teljesebben el is távolítottam - egy perc alatt felteszek egy kérdést -, hogy a félelem most azt hiszem, sok szempontból eloszlatott, és ez a mai nap előtt ha CIO hallgatnék, úgy gondolnék: „Nos, hogyan fogom megtenni ezt az átmenetet? Hogyan fogom garantálni ugyanazt a képességet, mint amit a relációs adatbázis-kezelési platformon és a sok éves tapasztalattal rendelkezünk a DBA-k számára, egy új platformon, amelyben jelenleg nincs készségünk? ”Szóval, az én kérdésem ezzel:, gondolja-e az emberek, hogy megértették, hogy az eszközök most ott vannak, amit kínálnak, és hogy valamilyen módon mély lélegzetet és megkönnyebbülést sóhajthatnak, hogy az átmenet nem olyan félelmetes, mint amilyen korábban lehetett volna hogy ez az eszköz elérhető legyen? Gondolod, hogy az emberek megértették, vagy még mindig ilyen, olyasmi, amit csak küzdenek a memóriában lévő számításra és a memóriában tárolásra való áttéréssel szemben az NVMe, a flash és a lemez old school kombinációival?
Bill Ellis: Igen, tehát kétségtelenül sok olyan technológia és eszköz létezik, amely grafikusan képes megjeleníteni ezt, mi történik, és nagyon egyszerűvé teszi a legfontosabb erőforrás-fogyasztók meghatározását. Úgy értem, hogy elősegíti a dolgok egyszerűsítését, és elősegíti a technológiai személyzet számára, hogy valóban jó kezelést kapjon. Hé, képesek lesznek megtudni, mi folyik, és képesek lesznek megérteni az összes bonyolultságot. Tehát abszolút, a piacon található eszközök határozottan hasznosak, ezért felajánljuk az SAP HANA munkaterhelésének elemzését.
Dez Blanchfield: Igen, azt gondolom, hogy az a nagy dolog, amit ma megmutattál nekünk, az a, hogy a hardver darab, az operációs rendszer darabjának megfigyelésekor, akár a munkaterhelés egy részének figyelése is, amint azt mondtad, az eszközökön keresztül gondoltam már egy ideje ott vannak. Kicsit számomra, különösen a HANA-ban, az, hogy nem feltétlenül voltunk képesek nagyítóval lekérni, belepillantani és látni, hogy az Ön szerszámai mi történik a lekérdezésekkel és hogyan felépítése és hol van ez a terhelés.
Az eddig látott telepítésekkel, tekintettel arra, hogy szó szerint szó szerint a leghatalmasabb ezen a helyen a platformon a világon, néhány gyors győzelem közül néhányat látott - van-e anekdotikus tudása, amelyet megoszthat? Néhány eureka-pillanat körül, az aha-pillanatok körül, ahol az emberek telepítették az IDERA eszközkészletet, olyan platformokat és előadásaikat találtak olyan dolgokról, amelyekről csak nem tudtak. Van valami nagyszerű anekdotikus példája arról, hogy az emberek éppen most telepítették, nem igazán tudják, mi volt, és hirtelen elmentek: „Hú, valójában nem tudtuk, hogy ott van?”
Bill Ellis: Igen, a natív eszközök nagy korlátozása az, hogy ha egy kiszabadult lekérdezés törlésre kerül, akkor az kitölti az információkat, és így alapvetően nincs meg az előzményei. Ha az előzményeket offline módon tároljuk, mint egy elmenekült lekérdezés, akkor előzményeket fogunk kapni, tudni fogjuk, mi történt, láthatjuk a végrehajtási tervet és így tovább. Így tehát ez lehetővé teszi a végfelhasználói közösség alapvetõ jobb mûködését, jobb jelentések készítését, stb. És tehát a történelem nagyon kedvező. És az egyik dolog, amit meg akartam mutatni, az, hogy akár négy hétig is valós időben tekintheti meg a képet, majd könnyedén nagyíthat bármilyen érdeklődésre számot tartó időkeretre, és felfedheti a mögöttes vezetési tevékenységet. A láthatóság megteremtése nagyon hasznos annak ismeretében, hogy milyen szűk keresztmetszet merült fel.
Dez Blanchfield: Megemlítette, hogy többfelhasználó, miután telepítették, és nagyon lenyűgözött az a tény, hogy ügynökötlen és sok szempontból ténylegesen nulla érintés. Normális-e, ha az eszköz egyetlen telepítése mindenki számára elérhető a NOC hálózati operációs központjától, és figyelje a fürt alapját képező alapinfrastruktúrát egészen az alkalmazás- és fejlesztői csapatig? Ez a norma, és egyszer telepít, és megosztják ezt, vagy arra számít, hogy az emberek esetleg modellpéldányokat néznek a verem különböző részeire? Hogyan néz ki ez?
Bill Ellis: Tehát az alapcsoportnak általában nagyon nagy érdeklődése van az SAP-ban zajló események technológiai alapjai iránt. Nyilvánvaló, hogy több csapat támogatja az egész tájat. A HANA darab csak erre összpontosít. Csak alapértelmezésként az SAP alapcsoportot választom, mint az információ elsődleges fogyasztóit.
Dez Blanchfield: Igaz. Azonban meglepő, hogy ha van fejlesztői csoportom, vagy nem csak kódszinten, hanem ha van egy adattudósok vagy elemzők csoportja, akik elemző munkát végeznek az ott található adatkészletekkel kapcsolatban, különös tekintettel arra, hogy az adatok tudományának jelentős nyomást gyakorol a szervezeten belüli mindenre, gondolkodásomban - és helyesbítsen, ha tévedek - számomra úgy tűnik, hogy ez számukra is nagy érdeklődésre számít, mert sok szempontból egy Az adattárház-környezetben elvégzendő súlyos dolgok közül az engedi szabadon az adattudósokat, és lehetővé teszi, hogy csak ad hoc kérdéseket tegyenek meg. Van-e valamilyen példája annak, hogy ilyen dolgok történnek, amikor az üzletek megszólaltak és azt mondták: „Egy adattudományi csoportot dobtunk a dologba, ez tényleg fáj, mit tehetünk értük szemben, szemben azzal, amit csak csinálunk hagyományos működési ellenőrzés és irányítás? ”Ez még valami dolog?
Bill Ellis: Nos, igen, kissé megfordítanám és megvágnám a választ, hogy ha a teljesítményre nézzünk, és tudatában vagyunk a minőségbiztosítási produkció fejlesztésének, akkor tudod, hogy minél előbb tárolod, annál kevesebb a probléma, annál kevesebb meglepetésed vannak. Szóval, abszolút.
Dez Blanchfield: Ezt követően sok eszköz, amivel tapasztalatot szereztem - és biztos vagyok benne, hogy Robin egyetért azzal - sok itt található eszköz, ha van egy nagy RDBMS, igazán magas szintűre van szüksége - képzett, mély ismeretekkel rendelkező, tapasztalt DBA-k. Az SAP HANA-val járó néhány infrastrukturális és platformkövetelmény, mivel jelenleg bizonyos terjesztések támogatják, amelyek a legjobb tudásom szerint igazodnak az egyes hardverekhez és így tovább. Tudod, vannak olyan emberek évtizedes tapasztalattal, akik nem azonosak. Azt látom azonban, hogy ez nem feltétlenül szükséges ehhez az eszközhöz. Úgy tűnik számomra, hogy telepítheti szerszámát, és megadhatja azt néhány meglehetősen új arcnak, és azonnal hatalmat adhat nekik, hogy olyan dolgokat találjanak, amelyek nem teljesítenek jól. Előfordul-e, hogy van egy nagyon rövid tanulási görbe, hogy ezzel felgyorsuljanak, és kihasználhassanak bizonyos értéket a telepítéséből? Tudod, az én általános értelmem, hogy nem kell 20 éves tapasztalattal rendelkeznie egy szerszám vezetésében, hogy azonnal láthassa az értéket. Elfogadná, hogy ez a helyzet?
Bill Ellis: Ó, abszolút, és ön véleményére gondolom, hogy egy telepítés sikere nagyban függ az SAP HANA környezet megtervezésétől és felépítésétől. És akkor kétségtelenül sok bonyolultság, sok technológia van, amelyre épül, de aztán csak arra kell figyelnie, hogy megfigyeljék a felhasználási mintákat. Tehát, bár bonyolultabb, bizonyos értelemben csomagolva és kissé egyszerűsítve. Nagyon szegény.
Dez Blanchfield: Igen, tehát mielőtt visszaadom Ericnek, mert tudom, hogy van néhány kérdése, különösen néhány olyan kérdése van, amelyek érdekesnek tűntek a kérdések és válaszok során, és szívesen hallom a választ. Hagyományos utazás valaki felé - korábban már említette, hogy megszerezheti, letöltheti és kipróbálhatja. Tudna gyorsan visszatérni a népi meghallgatáshoz, vagy olyan népi meghallgatáshoz, aki később megismételheti? Melyek a gyors két vagy három lépés ahhoz, hogy megszerezzék a másolatot, telepítsék és kipróbálják a környezetükben, mielőtt megvásárolnák? Hogyan néz ki ez? Milyen lépéseket teszünk ehhez?
Bill Ellis: Igen. Tehát, az IDERA.com, nyissa meg a Termékeket, és látni fogja az SAP HANA munkaterhelésének elemzését. Van egy letöltő oldal. Azt hiszem, megkérnek tőled néhány elérhetőséget, és a terméket csak egy licenckulcs csomagolja, így telepítheti a Setup.exe fájlba, és szerintem nagyon gyorsan elindul.
Dez Blanchfield: Tehát eljuthatnak a webhelyére, letölthetik azt. Emlékszem, nézegettem egy ideje, és tegnap este is ellenőriztem, kérhet egy bemutatót a memóriából, ahol valaki a csapatodban valamilyen módon végigvezet rajta? De valóban letöltheti és ingyen telepítheti saját környezetében, a saját idejében, nem igaz?
Bill Ellis: Igen.
Dez Blanchfield: Kiváló. Nos, azt hiszem, valószínűleg ennél sokkal inkább az, amit személyesen javasolnék a népeknek, az, hogy megragad egy másolatot a weboldalról, megragadom az ott található dokumentációt, mert tudom, hogy nagyon sok jó tartalom van ehhez, és csak próbáld ki. Tegye a környezetbe, és nézze meg, mit talál. Azt gyanítom, hogy ha egyszer megnézi a motorháztető alá az SAP HANA környezetét az IDERA eszközzel, olyan dolgokat talál, amelyek valójában nem voltak tudatában.
Nézd, köszönöm szépen ezt, és köszönöm az időt, csak a kérdéseket és válaszokat Robin és I. Eric mellett, visszaadom neked, mert tudom, hogy egyes kérdések és válaszok a résztvevőinkkel is átjutnak.
Eric Kavanagh: Igen, csak egy nagyon gyors itt. Tehát az egyik résztvevő nagyon jó megjegyzést fűz itt, csak arról beszél, hogy a dolgok hogyan változnak. A múltban elmondható, hogy a memória fulladásnak indult, és a gyakori lapozás lelassult, jelenleg a CPU túl sok memória-adatban van. Tudod, vannak hálózati problémák. Mindig mozgó célpont lesz, igaz? Milyennek látszik manapság a pályavonal annak szempontjából, hogy hol lesznek a szűk keresztmetszetek, és hol kell összpontosítania a figyelmét?
Bill Ellis: Igen. Amíg meg nem mérjük, nehéz tudni. Az SQL utasítások egyik dolga az, hogy ők lesznek az erőforrás-fogyasztás mozgatórugói. És tehát abban a körülményben, hogy nagy memória-fogyasztás vagy CPU-fogyasztás volt szüksége, akkor kitalálhatja, hogy milyen tevékenység okozta az erőforrás-fogyasztást. Most nem feltétlenül akarja megölni, de tudatában kell lennie annak is, és valamilyen módon, mi történik, milyen gyakran történik, stb. Még mindig újak vagyunk abban a tekintetben, hogy a válaszok teljes készletére vagy szakácskönyvére különféle körülmények között reagálunk. Tehát ez egy nagyszerű kérdés, amelyet az idő fog mutatni. Több információ lesz az idő múlásával.
Eric Kavanagh: Ennyi. Nos, srácok, nagyon érdekes helyen vagytok. Azt hiszem, nagyon sok tevékenységet fog látni az elkövetkező hónapokban és az elkövetkező néhány évben, mert tudom, hogy az SAP, amint azt a tartalmi felhívásunkban javasolták, szép hosszú rámpát adott az emberek számára az átmenet végrehajtásához a HANA-hoz. Ennek ellenére ennek a rámpának van vége és egy bizonyos ponton az embereknek komoly döntéseket kell hozniuk, tehát minél előbb, annál jobb, igaz?
Bill Ellis: Teljesen.
Eric Kavanagh: Jól van, emberek, még egy órát égettünk itt a Hot Technologies oldalon. Információkat találhat online, a insideanalysis.com, valamint a techopedia.com weboldalon. Összpontosítson arra a webhelyre, ahol rengeteg érdekes információ található, beleértve a korábbi internetes közvetítések összes archívumának listáját. De az emberek, nagy köszönet mindenkinek odakint, az IDERA barátainak, Robinnak és természetesen Deznek. És a jövő héten felvesszük Önt, emberek. Köszönöm újra időt és figyelmet. Vigyázz magadra. Viszlát.
