Elvitel: Eric Kavanagh házigazda megbeszélést folytat a memória beépítéséről és az SAP HANA-ról a vendégekkel, Dr. Robin Bloor, Dez Blanchfield és az IDERA Bill Ellis segítségével.
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ázigazda a mai beszélgetés során.
És az emberek, ma néhány jó cuccró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, valószínűleg engem megüt, @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 lenyűgöző 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 tesznek, ami igazán nagyon jó. 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 egy kicsit arról, hogy mindezek a dolgok hogyan fognak működni, és mi is szól a rámpán, őszintén szólva. Tehát, Dr. Robin Bloor-tól, a saját fő elemzőinktől, a The Bloor Group-tól fogunk hallani; 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ő, amikor először az SAP HANA tájékoztatást kapott, most sok évvel ezelőtt jött vissza. De nagyon érdekes volt, az adott idő nagyon érdekes. Bekerültünk egy vagy két vállalatba, amelyek így vagy úgy, a memóriában beépített 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, minden nagy, 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 érdemes. Ez is az oka annak megemlítésére, az oka annak, hogy beledobtam, az az volt, hogy mindenki tudomást szerezzen róla, mikor itt 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 csupán az emlék. É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 egyre nagyobb és nagyobb, és most megabájtban van megmé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, elég 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 az egyik befolyás.
Aztán megjelent a 3D XPoint és az IBM PCM. És ez 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 miként fogja befolyásolni 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 áruház. 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 felismeri, hogy az adatok átvétele és a memóriába helyezése az egészet valóban meglehetősen másképp változtatja.
Tehát azt gondolhatta, hogy mi történik a képernyőn megjelenő képernyőn, akkor azt is gondolhatta, hogy egy vagy úgy 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 a 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 adatfolyamok tényleges konfigurálásának módját is.
Tehát hatalmas fajta hatás. Tehát a memória zavaró, igaz? És ki kell szereznünk azt, 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 az ERP szoftver verziójával jelenik meg, amely a memóriában van. É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, ha memóriába megy. És a felvétel, 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ó, az SAP ügyfélkörének megfelelően. Úgy értem, 10 000 vállalat van odakinn az SAP ERP-jét használva, és tudod, hogy nagyjából mindegyik nagyvállalat. Tehát az a gondolat, hogy mindegyikük ösztönözze a memóriába való beilleszkedést és az alapvető lehetőségek használatá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.
Ezt mondta, 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. Ezért 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 ezt megtesszük, mindig el kell döntened, 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. Olyan 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 mondta, az a megközelítés, amelyet az adatok számítógép-architektúrán történő mozgatására alkalmaztunk, valójában egy ideje, néhány évtizeden keresztül, valójában nem változott drámaian. 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 véleményem, hogy a nagygépek és a középszintű, valamint a 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 a dolgok, mint a keresztirányú hátterek lett egy dolog. Ahelyett, hogy csak egy útvonal lenne az adatok átviteléhez a hátlapon vagy az alaplapon, amint manapság ezt 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á váltunk, mivel 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 változottunk. 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 komplexitásaival 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 kell feltétlenül tennü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ó darab nem ragaszkodik egymáshoz, és egy kicsit óvatosnak kell lenned attól, hogy melyik apró darabot ragasztod össze, hogy szilárd legyen. És ez egy nagyon aranyos ötlet, de ébresztőóra, amikor félúton érkezik és rájössz: „Hmm, talán csak 300 dolláros PC-t kellett volna megvásárolnom, de most befejezem és tanulok belőle valamit.”
Számomra ez nagyszerű analógia annak, amit szeretne építeni ezeket a nagyon bonyolult platformokat, mert mindenképp 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 össze 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 be az I / O tetejét, és ütemeznie kell a dolgokat, kezelnie kell a munkaterhelést és a többfeladatot é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, 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 foglalkozunk 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 egy idő alatt 380–400 ezer dollárt költöttek egy gigabájt merevlemezre, amikor egy hatalmas dob volt, olyasmi, amire villástargoncának volt szüksége a felvételéhez. Manapság ez egy vagy két cent gigabájt árupéldányra esik. É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, tízéves, 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 pont szaggatott 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 vagy 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 jelentkezik - ez azt jelenti, hogy egy rövid ideig tart -, tehát ki kellett találnunk azokat a módszereket, amelyekkel rugalmasságot lehet nyújtani ebben 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 azt korábban már jeleztem, nem a gyenge szívűeknek szól. 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 általunk felépített összetettsé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. Ezzel a hiper skála hardver platformon végződöttünk, amely lehetővé teszi számunkra, hogy ezt most megtegyük. Ha a hiperskalibrációról beszélünk, akkor nevetségesen sűrű szinten és a nagyon nagy sűrűségű memóriában, a CPU-k, a magok és a szálak nagyon nagy sűrűségű számában nehezebb. Most nagyon bonyolult hálózati patológiákat kaptunk ennek támogatására, mivel az adatoknak valamikor át kell haladniuk a hálózaton, ha csomópontok és klaszterek között haladnak.
Tehát végül az eszközhiba-redundancia problémává válik, és meg kell figyelnünk az eszközöket és azok részeit. Be kell építenünk a rugalmas adathibák redundanciáját a platformon, és figyelnünk kell azt. Be kell építenünk az elosztott adatbázis rugalmasságát, így figyelnünk kell az adatbázis-platformot, és bele kell raknunk. Figyelemmel kell kísérnünk az elosztott feldolgozási ütemezést, hogy mi történik néhány folyamat belsejében 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 a névleges, minimális mennyiségű adatot fogja kapni a hátlap architektúráján? Multitenancy munkaterhelés, több felhasználó és több csoport működik ugyanazon vagy több munkaterheléssel, kötegelt jobokkal és valós idejű ütemezéssel. És megvan a szakaszos és a 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ő komplexitás nem csupán 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 ismeretlen ismeretekkel 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 olyat, 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 teljesítményt kapunk 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, azaz 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 azon gondolkodunk, hogy 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áadnunk? 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, hogy ki mit csinál a klaszterünkben é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 majdnem az egyik ilyen dolog, például egy betöltött pisztoly, é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, 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-nál lévő barátomnak, és meghallom, hogyan fogadták el ezt a kihívást.
Bill Ellis: Nagyon szépen köszönjük. 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 előttünk álló embereket, hogy elérhetővé tegyük ezt a 2017-ben elérhető anyagot. A SAP HANA munkaterhelés-elemzéséről fogunk beszélni - alapvetően egy adatbázis-figyelő 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, mivel az 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, hogy belekapaszkodnak ehhez a lábujjukba, mert tudják, hogy ez 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. Nincsenek összesített táblák. Az egyik dolog, amire ők utalnak, amikor erre gondolsz: nem akarod belejutni ebbe a helyzetbe, 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 az informatika területén, mint az egész, nem csak 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 és sok jelentéssel rendelkező üzleteknél ezt meg kell keresni, és meg kell határoznia az oszlopneveket, miközben 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 nyilvántartási 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. És tehát elengedhetetlen, hogy továbbra is legnagyobb sebességgel haladjon. 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 az internetet engedélyezte. Valójában ezt a megoldást nyitottam meg a rendszeren élőben. Van néhány kulcsfontosságú dolog, amelyet át kell nézni. Felosztottuk a különböző munkaterületekre. 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. Biztosan nem akarja eljutni a cserélő vagy csúszó szempontokhoz. És akkor alapvetően azon dolgozik, amely a tendenciák kialakulásakor alakul, a válaszidőtől a felhasználóktól, az SQL utasításoktól, azaz attól, hogy mi vezérli a tevékenységet a rendszeren.
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 át. Tehát a host szintjén valójában átnézhetjük a memóriát, nyomon követhetjük az időt és 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 ez 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 ezt saját kezűleg kezeljük. 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 előnézetet 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 egyfajta csúszó skálán szeretné használni, hogy meghatározza a szükséges magok, memória és lemezterület mennyiségé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 kihaszná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 kiürültek a HANA történetéből. 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 webhelyén, a Termékek alatt könnyen megtalálhatod ezt. Ha kipróbálni szeretné, 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 ezen 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ófigyelő 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, bármilyen kérdése tőled, 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 pontosan ezt szeretném ebben a helyzetben. Nagyon sok munkát végeztem - nos, ez régen régen volt - teljesítményfigyelést végeztem, és ez volt az a fajta; akkoriban nem volt a 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. Az eseti jelentést készítő webhelyeknél úgy értem, hogy ez valójában egy ilyen 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 az alappálya, mi egy adott webhelyre jellemző, hol van az adott webhely, felhasználási mintázataik 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, ahol figyeli, hangolja, csiszolja és javítja a rendszert a végfelhasználói közösség számára, hogy az üzleti vállalkozás hatékonyabban szolgálhasson.
Dr. Robin Bloor: Oké, tehát amikor végrehajtja - úgy értem, tudom, hogy ezt egy nehéz kérdést kell megválaszolni, mert az a megvalósítás méretétől függően változik - de mekkora erőforrást igényel az IDERA megfigyelő képessége, mekkora forrást igényel? Valamit megváltoztat, vagy az, csak nem zavar? Hogyan működik?
Bill Ellis: Igen, azt mondanám, hogy a többlet körülbelül 1–3 százalék. Sok üzlet nagyon hajlandó ezt feláldozni, mivel potenciálisan ezt meg tudod majd vásárolni az optimalizálás szempontjából. 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 tényleg változó, de amint arról beszéltünk, határozottan jobb, ha egy kicsit költenek a dolgokra, hogy megismerjék, mi folyik, mint hogy vakon futhassanak. Különösen az lenne, ha tudod, itt vagyunk januárban, és elkezdjük az évek feldolgozását, és összeszedjük a 12 hónapos adatokat. Tudod, hogy a kritikus üzleti teljesítmény szempontjából elengedhetetlen az, hogy teljesítményt végezzen, és jelentéseket kapjon a szabályozó szervezeteknek, a bankoknak, a részvényeseknek.
Dr. Robin Bloor: Jobb. És az Ön szempontjából egy gyors - mivel azt hiszem, egész SAP-oldalakkal foglalkozik - mekkora az SAP-ügyfélkör mozgása az S / 4 felé? Úgy értem, hogy valami olyasmi, amit tudsz, hogy van egyfajta lavina lelkes ügyfelek számára, 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 szempontjából a HANA-t más alkalmazásokhoz is adaptálják, vagy valamilyen módon teljesen emésztik ezeket a dolgokat? 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 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örnyékén fekvő táj.
Dr. Robin Bloor: Azt hiszem, jobb, ha átadlak téged 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, valójában azt láttam, hogy a nézőpontom szerint a százalékot 20 százalék körülire helyezem. 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? Szóval 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 vett tény teljesítése, é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 csupán 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 ezt megszerezték? 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átjá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, az az oka, hogy feltettem ezt a kérdést, és meg kell bocsátania nekem, de az az, hogy egyetértek. Azt hiszem, nem féltek félbeszakítani róla. Úgy gondolom, hogy a jel sok szempontból eltűnt. És egyetértek veled - nem tudom, hogy még mindenki ugrott fel. 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 ma bemutatott demonstráció, kiemelte, és számomra az egyik kulcsfontosságú elvihetés 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 üzletág, amely már átment a memóriában lévő számításhoz. Tehát ez minden vagy semmi lépés az elméjü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 már vannak az általuk kínált eszközökkel, é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, olyasmit, amiben csak küzdenek az átállás a memóriában lévő számításra és a memóriába történő tárolásra, szemben az NVMe, a flash és a lemez régi iskolai kombinációival?
Bill Ellis: Igen, tehát kétségtelenül sok olyan technológia és eszköz létezik, amely grafikusan ábrázolja 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é, tudni fogják, hogy mi történik, és megértik 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 hiszem, az a nagy dolog, amit ma megmutattál nekünk, az, hogy a hardverdarab, az operációs rendszerdarab megfigyelésekor, akár a munkaterhelés egy részének figyelése is, amint azt mondtad, úgy értem, az eszközök ott voltak egy ideig. 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 eszköz milyen hatással van a lekérdezésekre, és hogy vannak 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 vagy ezen a téren a platformon a világon, néhány gyors győzelem, amit 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élda arra, hogy az emberek éppen most telepítették, nem igazán tudva, 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 elmenekült lekérdezést törölnek, akkor az kiüríti az információt, és így alapvetően nincs meg az előzményei. Azáltal, hogy az előzményeket offline módon tároljuk, mint egy elmenekült lekérdezés, akkor rendelkezünk előzményekkel, 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, ha tudjuk, mi szűk keresztmetszet merült fel.
Dez Blanchfield: Ön megemlítette, hogy többfelhasználó, miután telepítették, és nagyon lenyűgözött az a tény, hogy ügynöke é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 rendkívül 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 alapcsoportját fogom alapul venni, mint az információ elsődleges fogyasztóját.
Dez Blanchfield: Jobb. 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és van. . Szóval, abszolút.
Dez Blanchfield: Ezt követően sok eszköz, amivel tapasztalatot szereztem - és biztos vagyok benne, hogy Robin egyetért - sok eszköz itt található, ha van egy nagy RDBMS, igazán magas szintű képzettségűre van szüksége, mélyen ismeretes, tapasztalt DBA-k. Az SAP HANA-val kapcsolatos néhány infrastrukturális és platformkövetelmény, mivel jelenleg az adott disztribúciókkal támogatott, bizonyos tudásom szerint az egyes hardverekből és így tovább igazítva. Tudod, vannak olyan emberek évtizedes tapasztalattal, akik nem azonosak. Amit azonban látok, az nem feltétlenül követelmény ehhez az eszközhöz. Úgy tűnik számomra, hogy telepítheti eszközét, és megadhatja azt néhány meglehetősen új arcnak, és azonnal hatalmat adhat nekik arra, 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 felgyorsuljanak ezzel, és érdemeljenek ki bevezetést? 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 tervezésétől és építkezésétől. És akkor kétségtelenül nagyon sok a bonyolultság, sok a beépített technológia, de akkor csak arra kell figyelnie, hogy figyelemmel kísérje a zajló eseményeket. Tehát, bár bonyolultabb, bizonyos szempontból csomagolva és kissé egyszerűsítve. Nagyon rossz.
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 az érdeklődésre számot tartó kérdések és válaszok során jöttek létre, és nagyon 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. Úgy gondolom, hogy kérnek tőled bizonyos elérhetőségeket, é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ójában ingyenesen letöltheti, és helyben 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 miután megtekintette a motorháztető alá az SAP HANA környezetét az IDERA eszközzel, olyan dolgokat fog találni, amelyek valójában nem voltak tudatában ott.
Nézd, köszönöm szépen ezt, és köszönöm az időt csak azért, hogy válaszolj Robin és I. Eric kérdéseire és válaszaira, visszaadom neked, mert tudom, hogy egyes kérdések és válaszok a résztvevőktől is származnak.
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 újok vagyunk abban, hogy a különböző körülményekre adott válaszok teljes készletét vagy szakácskönyveit címezzük. Tehát nagyszerű kérdés, és az idő fog megmutatni. Az idő múlásával bővebb információnk lesz.
Eric Kavanagh: Ez az. 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 oldalán. 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.