От персонала на Техопедия, 25 януари 2017 г.
Отнемане: Домакинът Ерик Кавана обсъжда изчисленията в паметта и SAP HANA с гостите д-р Робин Блур, Дез Бланчфийлд и Бил Елис на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, госпожи и господа. Здравейте и добре дошли отново. Това е четири часа източно време в сряда, а последните няколко години това означава, че отново е време за горещи технологии. Да, наистина, казвам се Ерик Кавана, ще бъда ваш домакин за днешния разговор.
И хора, днес ще говорим за някои готини неща. Ще се потопим в света на паметта, точното заглавие е „Into the Future: On-Ramp for In-Memory Computing.“ Това е яростта в наши дни и с основателна причина, най-вече защото паметта е толкова по-бърза, отколкото да разчитаме на въртящи се дискове. Предизвикателството обаче е, че трябва да пренапишете много софтуер. Защото софтуерът на днешния ден, по-голямата част от него, е написан с предвид и това наистина променя архитектурата на приложението. Ако проектирате приложението да изчаква въртящ се диск, просто правите нещата по различен начин, отколкото ако имате цялата сила на технологията в паметта.
Има място за вашето наистина, ударете ме в Twitter, @eric_kavanagh. Винаги се опитвам да следя назад, а също и да ретуирам по всяко време, когато някой ме спомене.
Както казах, днес говорим за памет и по-конкретно за SAP HANA. Вашият наистина прекара последната година, опознавайки наистина добре SAP общността и това е завладяваща среда, трябва да кажа. Шапки към хората, които изпълняват тази операция и са на първите линии, защото SAP е изключително добра операция. Това, в което наистина са много добри, е да правят бизнес. Те също са страхотни в технологиите, и наистина вложиха сериозна инвестиция в HANA. Всъщност мога да си спомня - вероятно беше преди около шест или седем години - че ние вършехме някаква работа за ВВС на САЩ всъщност, и накарахме някой от SAP да влезе и да ни даде ранен поглед върху света на HANA и това, което беше планирано. И най-малкото, хората от SAP Labs бяха вложили много време и усилия, за да разберат как да се изгради тази архитектура, която е напълно различна, за пореден път, от традиционните среди, защото имате всичко в паметта. Така че, те говорят за правене както на транзакционни, така и на аналитични данни в една и съща информация в паметта, за разлика от традиционния начин, който го изваждате, поставяте в куб, например, анализирате го там, срещу транзакционния, който се случва по много различен начин.
Това е интересно пространство и всъщност ще разберем от друг доставчик, IDERA, малко за това как ще работят всички тези неща и за какво е откровено рампата. И така, ще се чуем от д-р Робин Блур, наш главен анализатор от групата The Bloor; Дез Бланчфийлд, нашият учен по данни и след това добрият приятел Бил Елис от IDERA. Така че, с това, аз ще връча ключовете на д-р Робин Блур, който ще го отнеме.
Д-р Робин Блур: Да, както казваше Ерик, времето, което за първи път ни запознаха от SAP HANA, се върна преди много години. Но беше много интересно, точно това време беше много интересно. Бихме се сблъскали с една или две компании, които по един или друг начин предлагаха технология в паметта. Беше съвсем ясно, че в паметта ще дойде. И наистина не беше, докато SAP се изправи и изведнъж пусна HANA. Искам да кажа, че беше шок, когато видях SAP да прави това. Беше шок, защото очаквах да дойде от другаде. Очаквах, че ще бъде, Microsoft, Oracle или IBM, или някой подобен. Идеята, че SAP го прави, наистина много ме изненадва. Предполагам, че не би трябвало да е така, защото SAP е един от стратегическите доставчици и почти всичко, което се случва в индустрията, идва от един от тях.
Както и да е, целият смисъл на паметта, искам да кажа, разбрахме, че говорихме за това, че щом всъщност влезете в паметта - не става въпрос за въвеждане на данни в паметта, а за ангажиране с идея, че слоят памет е системният запис - веднага щом мигрирате системния запис в паметта, дискът започва да се превръща в среда за предаване от един вид и става нещо различно. И мислех, че това е много вълнуващо, когато това започна да се случва. Така че, наистина, всичко приключи за въртене на диск. Спининг дискът скоро ще съществува само в музеите. Не съм сигурен колко скоро това е, но в общи линии, солидният диск вече е на кривата на закона на Мур, той вече е десет пъти по-бърз от въртящия се ръжда, както сега го наричат, и доста скоро ще бъде по-бърз все още и тогава това означава, че използването на случаи за диск става все по-малко и по-малко.
И любопитният факт, традиционната СУБД, всъщност е създаден много традиционен софтуер за въртящ се диск, той предполагаше въртящ се диск. Имаше всевъзможни физически възможности, които бяха старателно програмирани, за да се използва въртящ се диск, правейки извличането на данни възможно най-бързо. И всичко това се отмива. Просто изчезваш, знаеш ли? И тогава, очевидно имаше много - не знам, доходоносен, предполагам, това ще бъде в крайна сметка - отваряне за база данни в паметта, която се опита да заеме позицията, че големите бази данни, Oracle и Microsoft, SQL Сървър и DB2 на DB2, той заема в пространството на паметта и беше много интересно да наблюдаваме как идват и вървят напред.
Нека да поговорим за каскадата на паметта; просто си струва да се спомене. Освен това, причината да спомена това, причината, в която го хвърлих, беше просто да уведомя всички, когато говоря за памет тук, всички тези слоеве, за които говоря, са всъщност памет. Но изведнъж осъзнаваш, когато погледнеш това, това е йерархичен магазин, това не е само памет. И следователно, важи почти всичко, което научихме много отдавна за йерархичен магазин. И това също означава, че всяка база данни в паметта трябва да се ориентира през това, някои просто минават през нея по самата RAM памет. И просто ставаше все по-голям и по-голям и по-голям и сега се измерва в мегабайти. Но имате кеш L1, който е сто пъти по-бърз от паметта, L2 кеш 30 пъти по-бърз от паметта и L3 кеш на около 10 пъти по-бърз от паметта. Знаете, знаете, че има много технологии - е, доста голяма технология - прие стратегията за използване на тези кешове като вид, пространство за съхранение по пътя за изпълнение на нещата, по-специално технологията за бази данни. Значи, знаете, това е едно влияние.
Тогава имаме появата на 3D XPoint и PCM на IBM. И това е почти скоростта на RAM, всъщност е това, с което се хвалят и двамата. Случаите на употреба вероятно са различни. Ранното експериментиране с това тепърва ще приключи. Не знаем как ще повлияе на използването на RAM и технологията на базата данни в паметта. След това имате RAM спрямо SSD. В момента RAM паметта е около 300 пъти по-бърза, но, разбира се, тази кратност намалява. И SSD срещу диск, който е около 10 пъти по-бърз, ако го разбирам. Така че, такава е ситуацията. Това е йерархичен магазин. Ако го погледнем по друг начин, в паметта, разбира се, е съвсем различно. И така, горната диаграма показва две приложения, като и двете може би имат достъп до база данни, но със сигурност имат достъп до данни за въртяща се ръжда. И начинът, по който действително карате нещата да се движат през мрежата, в зависимост от това какви зависимости са наоколо, имате ли ETL. Така че, това означава, че, знаете ли, данните преминават към въртяща се ръжда и след това излиза от въртяща се ръжда, за да отидете навсякъде и за да стигнете до където и да е, тя се връща обратно към въртяща се ръжда, което е три движения. И имайте предвид, че паметта може да бъде сто хиляди пъти по-бърза от въртящия се диск и вие със сигурност осъзнавате, че вземането на данни и поставянето им в паметта прави това цяло нещо съвсем различно.
Така че, може би сте си помислили, че ще се случи това, което е на екрана точно тук, може би сте мислили, че по един или друг начин ETL всъщност просто ще премине от данни към данни в паметта. Но всъщност това не може да направи това; всъщност може да имате ситуацията вдясно тук, където две приложения всъщност могат да изстрелят една и съща памет. Със сигурност база данни в паметта може да ви даде тази възможност, стига да имате заключването и всичко останало, организирано около него. Така че това не просто променя скоростта на нещата, това променя как всъщност конфигурирате приложения и цели потоци данни.
И така, това е огромен вид въздействие. Така че, паметта е разрушителна, нали? И това трябва да получим от казаното от мен. Понастоящем обработката на паметта е ускорител, но това ще стане норма. Ще се използва, като се прилага според стойността на приложението и затова е много, много интересно, че SAP всъщност ще излезе с версия на техния ERP софтуер, който е в паметта. Подобрения в латентността до три порядъка са напълно възможни и всъщност дори повече от това е възможно, в зависимост от това как го правите. Така че, вие получавате огромни подобрения в скоростта, като влезете в паметта. И последният резултат, S / 4 на SAP HANA, който те пуснаха, мисля, добре, хората казват, че все още се пуска, но със сигурност беше пуснат миналата година - това е смяна на играта, като се има предвид клиентската база на SAP. Искам да кажа, че там има 10 000 компании, които използват ERP на SAP и почти всички те са големи компании. И така, идеята всички те да имат стимул да влязат в паметта и да използват своите основни, тъй като ERP почти винаги са основни приложения, които бизнесът управлява, това е просто огромен смяна на игри и ще бъде много интересно. Разбира се, всичко това звучи много добре, но трябва да бъде конфигурирано интелигентно и трябва да бъде добре наблюдавано. Не е толкова просто, колкото звучи.
Като каза това, мисля, че ще предам топката на, кой е този човек? О, австралийски човек, Дез Бланчфийлд.
Дез Бланчфийлд: Много смешно. Винаги труден акт, д-р Робин Блур. Благодаря, че ме прие днес. И така, голяма тема, но вълнуваща. И така, аз съм избрал изображение, което често си представям, когато мисля за модерното хранилище за данни на езерото и предприятията, както и за моите малки скъпоценни камъни. И така, тук имам това красиво езеро, заобиколено от планини и вълни, които излизат, а вълните се разбиват над тези скали. Това е нещо, как мислено визуализирам как изглежда в голямото езеро с данни в наши дни. Вълните са партидни задачи и анализи в реално време се хвърлят към данни, като скалите. И когато мисля за това като за физическо езеро, то някак ми връща буден призив към мен, че, знаете, мащаба на складовете с данни, които сега изграждаме, причината да измислим тази монета и срока на езеро с данни е, че те са много големи и са много дълбоки и понякога можете да имате бури в тях. И когато го правим, винаги трябва да разрешавате какво създава бурята.
Така че в темата на това нещо ми се струва, че този сиренен разговор в изчисленията в паметта наистина е много силен и с добра причина. Той носи толкова много значителни търговски и технически печалби. Това е дискусия за няколко часа в друг ден. Но общото преминаване към изчислението в паметта, първо искам само да разгледам как стигнахме до тук и какво прави това възможно, защото това, като нещо, поставя основата на това, къде първо могат да лежат някои от предизвикателствата и какво трябва да знаем и да мислим за това, че в нашия свят да се отдалечим от традиционните стари въртящи се дискове, съхраняващи данни, и да бъдат издавани на пауза на и изключен диск, в паметта и извън паметта и в процесорите, до сега ние просто премахваме почти един от тези цели слоеве, като въртящ се диск. Защото не забравяйте, че в ранните архитектурни дни, ние архитектурно не се отдалечихме дълго време от основната рамка или от средния диапазон на онова, което първоначално смятахме за основна памет и съхранение на барабани.
Както каза д-р Робин Блур, подходът, който предприехме за преместване на данни около компютърната архитектура, всъщност не се промени драстично за известно време, в продължение на няколко десетилетия. Ако се замислите върху факта, че, разбирате ли, в съвременните изчислителни технологии технически има наоколо, ако ще помилвате за каламбура в продължение на 60-странни години, знаете, шест десетилетия и повече и е в смисъл, че можете купи кутия от рафта, както беше. Преминаването към нова архитектура наистина ми дойде в съзнанието, когато се изместихме от мисленето около мейнфрейм и среден диапазон, и основна архитектура на паметта и барабаните за съхранение, към смелите или суперкомпютърните, по-специално подобни на Seymour Cray, където неща като кръстосани задни плоскости стана нещо. Вместо само да има един маршрут, за да премествате данни през основата или дънната платка, както се нарича в наши дни. И вградената памет, знаете ли, в наши дни хората всъщност не мислят какво всъщност означава, когато казват DIMM и SIMM. Но SIMM е единична вградена памет, а DIMM е двойна вградена памет и ние имаме по-сложна от това, тъй като има десетки различни типове памет за различни неща: някои за видео, други само за общи приложения, някои вградени в процесори.
И така, имаше това голямо изместване към нов начин, по който данните се съхраняват и имат достъп. Предстои да преминем през същата промяна в друго цяло поколение, но не толкова в самия хардуер, а в приемането на хардуера в бизнес логиката и в слоя на логиката на данните, и това е още една голяма промяна в парадигмата в съзнанието ми,
Но само накратко как стигнахме до тук. Искам да кажа, че хардуерната технология се подобри и подобри драстично. Тръгнахме от наличието на процесори и идеята за ядрото беше доста модерна концепция. Приемаме го за даденост сега, когато нашите телефони имат две или четири ядра, а компютрите ни имат две или четири, или дори осем, ядра на работния плот и осем и 12 и повече на, знаете, 16 и 32 дори в сървърната платформа, Но всъщност е доста модерно нещо, че ядрите се превръщат в способност вътре в процесорите и че преминаваме от 32-битови до 64-битови. Няколко големи неща се случиха там: ние имаме по-висока тактова скорост на множество ядра, така че можехме да правим неща паралелно и всяко от тези ядра можеше да изпълнява множество нишки. Изведнъж можехме да пуснем много неща по едни и същи данни едновременно. Шестдесет и четири битово разстояние между адреси ни даде до два терабайта RAM, което е феноменална концепция, но това е нещо сега. Тези архитектури на многопластови планове, знаете ли, дънни платки, навремето можехте да правите нещата само в една посока: назад и напред. И както в дните с изчисленията в Cray и някои от суперкомпютърните дизайни от онова време, и сега в настолни компютри и обикновени, извън рафта, нещо като настолни компютри, работещи на стелаж, защото наистина повечето от съвременните Сега компютрите преминаха през тази ера на мейнфрейм, среден диапазон, микро десктопи и ние ги превърнахме обратно в сървъри.
И много от тези възможности на суперкомпютъра, този дизайн на суперкомпютър, бяха влезли в общи компоненти, които са извън рафта. Знаеш ли, в наши дни идеята да се вземат много евтини компютри, монтирани на багажник, и да се поставят в стелажи от стотиците, ако не и хиляди, и да се пусне софтуер с отворен код върху тях като Linux и да се разположат харесванията на SAP HANA върху него, вие знайте, ние често приемаме това за даденост. Но това е съвсем ново вълнуващо нещо и то идва със своите сложности.
Софтуерът също се подобри, особено управлението на паметта и разделянето на данни. Няма да навлизам в много подробности по този въпрос, но ако погледнете голямата промяна в последните 15 години или дори по-малко, как се управлява паметта, по-специално данните в RAM и как данните се разделят в RAM, така че както посочи д-р Робин Блур по-рано или споменава, знаете, нещата могат да четат и пишат едновременно, без да се засягат взаимно, вместо да имат време за изчакване. Много много мощни функции като компресия и криптиране на чипа. Шифроването се превръща в по-важно нещо и не е задължително да правим това в софтуера, в RAM, в пространството на процесора, сега това всъщност се случва на чипа. Това ускорява драстично нещата. И разпределеното съхранение и обработка на данни, отново неща, които някога предполагахме, са неща от суперкомпютрите и паралелната обработка, сега приемаме това за даденост в пространството на харесванията на SAP HANA и Hadoop и Spark и т.н.
И така, целият смисъл в това е този високоефективен компютър, HPC възможностите стигнаха до предприятието и сега предприятието се радва на предимствата, които идват с това в печалбите от производителност и технологичното пространство и техническите ползи и търговските печалби, защото, знаете, намаленото време до стойност драстично отпада.
Но използвам този образ на история, която прочетох преди време на джентълмен, който построи корпус за компютър от Лего, защото винаги ми идва на ум, когато се замисля за някои от тези неща. И това е, че изглежда страхотна идея по времето, когато започнете да го изграждате, и след това преминавате на половината път през него и осъзнавате, че всъщност е наистина сложно да съберете всички бита на Lego и да направите солидно нещо, достатъчно солидно да поставите дънна платка и така нататък, това ще изгради случай за личен компютър. И в крайна сметка разбирате, че всички малки парченца не се слепват правилно и трябва да внимавате малко кои битове ще залепите заедно, за да станат твърди. И това е много сладка идея, но това е събуждане, когато преминете на половината път и осъзнаете: „Хм, може би просто трябваше да купя кутия за компютър за 300 долара, но ще го довърша сега и ще науча нещо от него.“
За мен това е чудесна аналогия за това какво е да се изграждат тези много сложни платформи, защото всичко е добре и добре да го изградиш и да свършиш със среда, в която имаш рутери и комутатори, сървъри и стелажи. Имате процесори и оперативна памет и операционна система, групирани заедно. И вие поставяте нещо като HANA отгоре за разпределената обработка в паметта и съхранението на данни и управлението на данни. Вие изграждате SAP стека на всичко отгоре, получавате възможностите на базата данни и след това зареждате вашите данни и вашата бизнес логика и започвате да прилагате някои четения и записи и заявки и т.н. Трябва да се поддържате над I / O и трябва да планирате нещата и да управлявате натоварванията и многостранността и т.н. Този стек става много сложен, много бързо. Това е сложен стек сам по себе си, ако е само на една машина. Умножете, че с 16 или 32 машини се получава много, много нетривиално. Когато умножите до стотици и в крайна сметка хиляди машини, за да преминете от 100 терабайта към петабайт мащаб, това е плашеща концепция и това са реалностите, с които се занимаваме сега.
Така че в крайна сметка ще получите няколко неща, които също са помогнали да промените този свят, а това е, че дисковото пространство стана нелепо евтино. Знаеш ли, някога щеше да харчиш 380 до 400 хиляди долара на гигабайт твърд диск, когато беше масивен барабан с размер на - нещо, което се нуждаеше от мотокар, за да го вземеш. Днес това е нещо като един или два цента на гигабайт стоково дисково пространство. И RAM направи същото. Между другото, тези две J-криви и в двете графики са десетилетие, така че с други думи разглеждаме два блока от 10 години, 20 години намаляване на цените. Но ги разбих на две J-криви, защото в крайна сметка тази вдясно просто се превърна в пунктирана линия и не можахте да видите детайла, затова я преосмислих. Гигабайт оперативна памет преди 20 години беше нещо от порядъка на шест и половина милиона долара. Тези дни, ако плащате повече от три или четири долара за гигабайт RAM за стоков хардуер, вие сте ограбени.
Това значително понижение на намаляването на цените през последните две десетилетия означаваше, че сега можем да преминем отвъд дисковото пространство и направо в RAM, не само на мегабайтното ниво, но сега и на терабайтното ниво и да третираме RAM като диска. Предизвикателството с това беше, че RAM е естествено ефемерна - това означава нещо, което трае за кратък период от време - така че трябваше да измислим начини да осигурим устойчивост в това пространство.
И така, моят смисъл тук е, че изчисленията в паметта не са за слабите. Жонглирането на тези много мащабни данни в паметта и обработката около тях е интересно предизвикателство; както посочих по-рано, не е за слабите. И така, едно нещо, което научихме от този опит с широкомащабни и с висока плътност в изчисленията в паметта, е, че сложността, която изграждаме, започва да рискува в редица области.
Но нека просто да го разгледаме от гледна точка на мониторинга и реагирането. Когато мислим за данните, тя започва в дисковото пространство, тя седи в базите данни на дискове, ние ги избутваме нагоре в паметта. След като е в паметта и разпределена и има нейни копия, можем да използваме много копия от нея и ако се направят някакви промени, тя може да бъде отразена на ниво памет, вместо да се налага да се включва и изключва и през задната повърхност на две различни нива, тя влиза и излиза от паметта. Завършихме с тази свръхскална хардуерна платформа, която ни позволява да правим това сега. Когато говорим за хиперскалиране, е по-трудно на нелепо плътни нива и много висока плътност на паметта, много висока плътност на броя на процесори и ядра и нишки. Вече имаме много сложни мрежови патологии, които да подкрепят това, тъй като в даден момент данните трябва да се движат по мрежата, ако ще преминат между възли и клъстери.
И така, приключваме с излишъка на повреда на устройството, който се превръща в проблем и трябва да наблюдаваме устройства и части от него. Трябва да имаме вградена издръжливост на излишък на данни в тази платформа и да я наблюдаваме. Трябва да имаме вградена устойчивост на разпределената база данни, така че трябва да следим платформата на базата данни и да се подреждаме вътре в нея. Трябва да наблюдаваме разпределеното планиране на обработката, какво се случва вътре в някои от процесите чак до анкетиране и запитване и пътя, който заявката предприема, и начина, по който заявката се структурира и изпълнява. Как изглежда, някой направи SELECT * на "blah" или всъщност направиха много интелигентна и добре структурирана заявка, която ще им даде номиналния, минимален обем от данни, идващи от архитектурата в задната повърхност? Имаме многонационални натоварвания, множество потребители и множество групи, които изпълняват едни и същи или множество работни натоварвания и партидни задачи и график в реално време. И ние имаме тази смес от партидна и обработка в реално време. Някои неща просто се изпълняват редовно - почасово, ежедневно, седмично или месечно - други неща са по поръчка. Някой може да седи там с таблет, който иска да направи отчет в реално време.
И отново стигаме до това, че сложността, която възниква при тях, не е просто предизвикателство сега, а доста плашещо. И ние проверяваме тази реалност, че един въпрос за ефективността, само един въпрос за изпълнението сам по себе си, може да засегне цялата екосистема. И така, завършваме с това много забавно предизвикателство да разберем, добре, къде са въздействията? И ние имаме това предизвикателство, реактивни ли сме или сме активни? Гледаме ли реалното време в реално време и виждаме, че нещо върви „гръм“ и реагираме на него? Или сме виждали някаква форма на тенденция и осъзнахме, че трябва да се активизираме активно с нея? Защото ключът е всеки да иска нещо бързо и евтино и лесно. Но завършваме с тези сценарии, това, което обичам да визирам, и любимата ми линия от главоблъсканицата на Доналд Рамсфелд - която според мен се прилага при всички тези сценарии с висока сложност - и това е, че ние знаем знания, защото това е нещо ние проектирахме и изградихме и тя работи по план. Известни неизвестни сме, че не знаем кой работи какво, кога и къде, ако е по поръчка. И ние имаме неизвестни неизвестни и това са нещата, които трябва да наблюдаваме и да проверяваме. Тъй като реалността е, всички знаем, че не можеш да управляваш нещо, което не можеш да измериш.
Така че, за да разполагате с правилните инструменти и подходящата способност да наблюдавате нашите графични процесори, потърсете време за изчакване и разберете защо нещата трябва да чакат в опашки по график в тръбопроводи. Какво се случва в паметта, какъв вид употреба се изпълнява, каква производителност извличаме от паметта? Правилно ли се разделят неща, разпространява ли се, имаме ли достатъчно възли, които държат копия от него, за да се справят с натоварванията, които се хвърлят върху него? Какво се случва с изпълнението на процеси извън процесите на операционната система? Самите работни места, които се изпълняват, отделните приложения и демоните, които ги поддържат? Какво се случва в тези процеси, по-специално структурирането на заявките и как се изпълняват и компилират тези заявки? А здравето на тези процеси докрай в купчина? Знаеш ли, отново, назад, за да чакаме време, правилно ли е планирането, дали трябва да се изчака, къде се чака, чака ли памет, чете, I / Os, процесора, I / O в мрежата до крайния потребител ?
И след това обратно към тази точка, която споменах само набързо, преди да приключа, и това е това, как подхождаме към разрешаването на проблема и времената за отговор на тях? Гледаме ли в реално време и реагираме ли на нещата, което е най-малко идеалният сценарий, но дори и тогава е по-добре да го направим, отколкото да не знаем и да се обадим в сервизната служба и да кажем, че нещо се е объркало и трябва да го открием ? Или го правим проактивно и гледаме какво идва от линията? С други думи, виждаме ли, че ни липсва памет и трябва да добавим още възли? Правим ли анализ на тенденциите, правим ли планиране на капацитета? И във всичко това наблюдаваме ли историческите времена на изпълнение и мислим ли за планиране на капацитет или го наблюдаваме в реално време и проактивно препрограмиране и правим балансиране на натоварването? А запознати ли сме с натовареността, която тече на първо място? Знаем ли кой прави какво в нашия клъстер и защо?
Изчисленията в паметта са много мощни, но с тази мощност това е почти едно от онези неща, например заредено пистолет и играете с боеприпаси. В крайна сметка можете да се стреляте в крака, ако не внимавате. Така че тази сила на изчислението в паметта просто означава, че можем да работим много повече и по-бързо в много разпределени и дискретни набори от данни. Но тогава това ще доведе до по-голямо търсене от крайните потребители. Те свикват с тази сила и те искат. Вече не очакват работата да отнеме седмици, а отчетите да се появят на обикновена стара хартия. И тогава, под всичко това, ежедневната поддръжка е обградена около кръпка, актуализации и надстройки. И ако мислите за 24/7 обработка с изчисление в паметта, управление на тези данни, управление на натоварванията през нея, всичко това е в паметта, технически в ефимерна платформа, ако ще започнем да прилагаме кръпки и актуализации и надстройки в там идва и с редица други предизвикателства пред управлението и мониторинга. Трябва да знаем какво можем да направим офлайн, кога можем да го надстроим и кога го върнем онлайн. И това ме довежда до последната ми точка и това е, че когато получаваме все повече и повече сложност в тези системи, човек не може да направи само като смуче палеца и дърпа ухото си вече. Вече няма някакви подходи за чувство на червата. Наистина се нуждаем от подходящи инструменти за управление и осигуряване на това високо ниво на ефективност в управлението на изчисленията и данните.
И като се има предвид това, ще предам на нашия приятел от IDERA и ще чуя как са се справили с това предизвикателство.
Бил Елис: Благодаря ви много. Споделям екрана си и ето. И така, наистина е смирено да разгледаме цялата технология и всички хора, дошли преди нас, да направим достъпни тези неща, които са на разположение през 2017 г. Ще говорим за анализ на работното натоварване за SAP HANA - основно решение за мониторинг на базата данни: цялостно, без агенти, осигурява в реално време и създава история, така че можете да видите какво се е случило в миналото. SAP S / 4 HANA предлага потенциала за по-добри, по-бързи и по-евтини. Не казвам, че е евтин, просто казвам, че е по-евтин. Всъщност, традиционно се случи, че ще имате основна производствена инстанция - вероятно работи на Oracle в по-голям магазин, потенциално SQL Server - и тогава ще използвате този процес на ETL и ще имате множество, вид версии на истината, И това е много скъпо, защото плащахте за хардуер, операционна система, лиценз Oracle за всяка от тези отделни среди. И тогава на всичкото отгоре ще трябва да имате хора, които да съгласуват една версия на истината със следващата версия на истината. И така, тази многоверсийна обработка на ETL беше просто бавна и много, много тромава.
И така, HANA, по същество един екземпляр HANA, може потенциално да замени всички тези други случаи. Така че, това е по-малко скъпо, защото е една хардуерна платформа, една операционна система, вместо множества. И така S / 4 HANA, наистина, това променя всичко и вие по принцип разглеждате еволюцията на SAP от R / 2 до R / 3, различните пакети за подобрения. Сега наследената система е налична до 2025 г., така че имате осем години, докато наистина не сте принудени да мигрирате. Въпреки че виждаме хора, да знаете, че пръстите им се впускат в това, защото те знаят, че идва и в крайна сметка, знаете, ECC ще работи на HANA и затова наистина ще трябва да сте подготвени за това и да разберете технологията.
И така, една база данни, няма ETL процеси, няма копия, които трябва да бъдат съгласувани. И така, отново, по-бързо, по-добро и по-евтино. HANA е в паметта. SAP доставя софтуера, вие доставяте хардуера. Няма обобщени таблици. Едно от нещата, които те подсказват, когато мислите за това е, че не искате да се захващате с това, ние просто ще купим най-големия наличен сървър. Те предполагат, че по някакъв начин правилния размер на вашия SAP пейзаж преди време и те по принцип казват, не мигрирайте данни от 20 години. Мисля, че архивирането е нещо, което е недостатъчно използвано в информационните технологии, като цяло, а не само в SAP магазините. И така следващото нещо е, че SAP всъщност е прекарал много време, пренаписвайки родния си код, за да не използва SELECT *. SELECT * връща всички колони от таблицата и е особено скъпо в колонна база данни. И така, не е добра идея за SAP HANA. Така че, за магазините, които имат много персонализиране, много отчети, това е нещо, което ще искате да търсите и ще искате да посочите имена на колони, докато напредвате към мигрирането на всичко към HANA.
Обичаме да казваме, че HANA не е панацея. Подобно на всички бази данни, всички технологии, тя трябва да бъде наблюдавана и както споменахме по-рано, имате нужда от числа, за да управлявате излишък, измерване чрез измерване. И едно от нещата, за които говоря в областта на IDERA е, че всяка бизнес транзакция взаимодейства със системата на запис и в този случай това ще бъде HANA. И така, HANA се превръща в основата за извършването на вашите SAP транзакции, като крайното потребителско изживяване. И така, жизненоважно е той да се поддържа с максимална скорост. Това се превръща в единична точка на провал и при разговори с хора това може да се появи, когато имате краен потребител и може би използва тези данни в реално време и те имат ad hoc заявка, която потенциално не е съвсем прав. Може би те не се присъединяват към таблици и са създали външно присъединяване, партизански продукт и всъщност консумират много ресурси. Сега, HANA ще признае това в крайна сметка и ще убие тази сесия. И така има съществената част от нашата архитектура, която ще ви позволи всъщност да заснемете това в историята, така че да можете да видите какво се е случило в миналото и да разпознаете тези ситуации.
Така че, нека да разгледаме анализа на натовареността за SAP HANA. Това е Версия 1, така че много ви каним да се присъедините към нас в пътуването, а това е продукт от IDERA. Той е изчерпателен, но същевременно прост. В реално време с тенденция. Здраве на домакина, например здраве. Проследяваме състоянията на чакане, SQL заявките, потребителите на паметта и услугите. Така изглежда графичният графичен интерфейс и можете да видите веднага прилепите, че е активиран в мрежата. Всъщност отворих това решение, работещо на живо в моята система. Има някои важни неща, които искате да разгледате. Ние, някак си, сме разделени на различни работни пространства. Най-важното е какво се случва на ниво хост от използване на процесор и използване на паметта. Определено не искате да стигнете до точка на размяна или разтърсване. И след това по принцип вие се ориентирате към случващото се в тенденция, от времето за реакция, потребителите, SQL изявленията, тоест това, което движи дейността в системата.
Едно от нещата с IDERA е, че знаете, нищо не се случва в база данни, докато няма активност. И тази дейност са SQL изявления, които идват от приложението. Така че измерването на SQL операторите е абсолютно жизненоважно за да можем да открием първопричината. Така че, нека да продължим напред и да проучим инча. Така че на ниво хост можем всъщност да разгледаме паметта, да проследяваме времето, използването на хост процесора. Отстъпете назад, можете да разгледате операторите COBSQL. Сега едно от нещата, които ще видите в нашата архитектурна страна, е тази информация да се съхранява извън HANA, така че ако нещо се случи с HANA, ние всъщност улавяме информация до, не дай Боже, ситуация с недостъпност., Ние също можем да заснемем всичко, което се случва в системата, така че да имате ясна видимост. И едно от нещата, които ще направим, е да представим SQL изявленията в претегления ред. Така че това ще вземе предвид броя на екзекуциите и това е сумираното потребление на ресурси.
И така можете да влезете в отделни показатели тук - кога се изпълни това SQL изявление? И тогава потреблението на ресурси до голяма степен се ръководи от плана за изпълнение и затова сме в състояние да го заснемем на текуща основа. HANA е в паметта. Той е силно успореден. Той има първични индекси на всяка таблица, които някои магазини избират да съставят вторичен индекс за справяне с определени проблеми с производителността. И така, нещо като знам какво се е случило с плана за изпълнение на някои SQL оператори може да бъде много ценно. Също така ще разгледаме услугите, потреблението на памет за пореден път, очертани във времето. Архитектурата: така, това е самостоятелно решение, което можете да изтеглите от нашия уебсайт, а архитектурата е, че е активирана в мрежата.
Можете да имате няколко потребители да се свързват с конкретен случай. Можете да наблюдавате местни случаи на SAP HANA. И ние съхраняваме подвижна четириседмична история в нашето хранилище и това се самоуправлява. За да разгърнете това, е доста просто. Имате нужда от Windows Server. Трябва да го изтеглите. Повечето Windows сървъри ще имат вградена .NET рамка и тя се предлага в комплект с лиценз. И така ще отидете на съветника за инсталиране, който се задвижва от Setup.exe и той всъщност ще отвори екран, лицензионно споразумение и просто ще работите по този контур, като щракнете върху „Напред“. И така, къде бихте искали HANA да да бъде инсталиран? Следва свойства на базата данни и това ще бъде вашата връзка с SAP HANA, така че това е без агентен мониторинг на HANA инстанцията. И тогава основно ще дадем визуализация, това е портът, с който комуникираме по подразбиране. Щракнете върху „Инсталиране“ и основно стартира HANA и започвате да изграждате историята. Така че, само малко от информацията за оразмеряване на диаграмата. Можем да наблюдаваме до 45 случая HANA и вие ще искате да използвате този вид в плъзгаща се скала, за да определите броя на ядрата, паметта, дисковото пространство, от което се нуждаете. Това предполага, че имате пълна история на четири седмици.
Така че, като бърз резюме, ние гледаме на здравето на сървъра, здравето на инстанциите, използването на процесора / паметта. Какви са потребителите на паметта, какви са драйверите за активност, какви са услугите? SQL изявленията са жизненоважни - какви са състоянията на изпълнение? Покажете ми плановете за изпълнение, кога нещата се изпълниха, осигуриха тенденция? Това ще ви даде в реално време и история на случилото се. И както споменах, тъй като историята ни е отделна от HANA, ние ще заснемем неща, които са изтекли и изчезнали от историята на HANA. За да можете да видите истинското потребление на ресурси във вашата система поради отделната история.
И така, както споменах, в уебсайта на IDERA под Продукти лесно можете да намерите това. Ако искате да изпробвате това, със сигурност сте добре дошли. Вижте как предоставя информация за вас и има ли допълнителна информация на този уебсайт. Така че всички заинтересовани страни са повече от щастливи да се заемат с това. Сега в портфолио продуктите, предлагани от IDERA, има и монитор за транзакции на SAP ECC и това се нарича Precision for SAP. И това, което прави, е - дали използвате портал или просто ECC с директен нагоре - всъщност ще заснеме транзакцията на крайния потребител от щракване към диск, чак до SQL оператора и ще ви покаже какво се случва.
Сега ви показвам само един обобщен екран. Има няколко начина, които искам да имате от този обобщен екран. Това е времето за отговор на оста Y, времето на оста X и деня и в този изглед на транзакция ще ви покажем клиентско време, време за опашка, време за ABAP код, време за база данни. Ние можем да заснемем идентификатори на крайни потребители, T-кодове и всъщност можете да филтрирате и показвате сървъри чрез определена транзитна транзакция. И така, много магазини изпълняват предния край на пейзажа под VMware, така че всъщност можете да измерите какво се случва на всеки от сървърите и да влезете в много подробен анализ. И така, този изглед на транзакция е за транзакция на крайния потребител през целия SAP пейзаж. И можете да намерите това на нашия уебсайт под Продукти APM Tools и това ще бъде SAP решението, което имаме. Инсталацията за това е малко по-сложна, така че не е само да изтеглите и да я опитате, както имаме за HANA. Това е нещо, където бихме работили заедно, за да направим, проектираме и реализираме цялостната транзакция за вас.
И така, само една трета бърза резюме, анализ на натоварването за SAP HANA, той е всеобхватен, без агенти, в реално време, предлага история. Ние предлагаме възможност за изтегляне и изпробване за вашия сайт.
Така че с това ще предам времето обратно на Ерик, Дез и д-р Блур.
Ерик Кавана: Да, може би Робин, някакви въпроси от теб, а после и Дез след Робин?
Д-р Робин Блур: Добре. Искам да кажа, първото нещо, което бих искал да кажа е, че наистина харесвам изгледа на транзакцията, защото е точно това, което бих искал в тази ситуация. Направих много работа - е, това е много отдавна в момента - правех мониторинг на ефективността и това беше видът; в онези дни не разполагахме с графиката, но това беше нещо, което особено исках да мога да правя. За да можете по един или друг начин да си инжектирате там, където се случва проблемът.
Първият въпрос, който имам е, знаете, повечето хора изпълняват S / 4 по някакъв или друг начин, разбирате. Когато се включите в някоя дадена реализация на S / 4, открихте ли, че тя е внедрена добре, или в крайна сметка откривате неща, които могат да накарат клиента да иска да пренастрои? Искам да кажа, как върви всичко това?
Бил Елис: Е, всеки магазин е малко по-различен. И има различни модели на използване, има различни отчети. За сайтове, които имат ad hoc отчитане, искам да кажа, че това всъщност е като подметка в системата. И така, едно от най-важните неща е да започнете измерването и да разберете каква е основната линия, какво е нормално за конкретен сайт, къде е този конкретен сайт, въз основа на моделите им на използване, подчертавайки системата. И след това направете корекции от там. Обикновено оптимизацията за мониторинг не е еднократна, а наистина продължаваща практика, при която наблюдавате, настройвате, настройвате, правите системата по-добра за общността на крайните потребители, за да може да обслужва бизнеса по-ефективно.
Д-р Робин Блур: Добре, така че когато внедрите - искам да кажа, знам, че на този въпрос е трудно да се отговори, защото ще варира в зависимост от размера на внедряването - но колко ресурс има способността за мониторинг на IDERA, колко консумира ? Има ли някаква разлика за нещо или е, просто не се намесва? Как става това?
Бил Елис: Да, бих казал, че режийните разходи са приблизително 1–3 процента. Много магазини са много готови да пожертват това, тъй като потенциално ще можете да го купите обратно по отношение на оптимизацията. Това зависи от моделите на използване. Ако правите пълен пейзаж, това зависи от отделните технологии, които се наблюдават. Така че, пробегът в различен вид варира, но както говорихме, определено е по-добре да отделите малко, за да знаете какво се случва, отколкото просто да слепите. Особено би било, знаете, ето ни тук през януари и вие влизате в обработка на други години и обобщавате данни от 12 месеца. Нали знаете, че постигането на ефективност, извличането на отчети пред регулаторните организации, банките, към акционерите, е абсолютно жизненоважно за критичните бизнес резултати.
Д-р Робин Блур: Точно така. И само бързо, от ваша гледна точка - защото предполагам, че сте там, участващи с цяла поредица от SAP сайтове - колко голямо е движението между клиентската база на SAP към S / 4? Искам да кажа, че нещо, което се създава, знаете ли, че има някаква лавина от ентусиазирани клиенти, които го правят, или това е просто постоянна струйка? Как виждате това?
Бил Елис: Мисля, че преди няколко години бих казал, че това е пръст. Сега бих казал, че хората са, донякъде, до коляното. Мисля, че, знаете, като се има предвид времевата линия, която хората ще бъдат наистина потопени в HANA през следващите няколко години. И така наблюдението, трансформацията, знаете ли, мисля, че по-голямата част от клиентите са, като цяло, на кривата на обучение заедно. И така мисля, че не сме съвсем на лавината, както казахте, но мисля, че сме на върха на основната трансформация към HANA.
Д-р Робин Блур: Добре, така че по отношение на сайтовете, които сте виждали, които са направили това, адаптират ли HANA и за други приложения или те по един или друг начин са напълно консумирани при направата на това неща работят? Каква е картината там?
Бил Елис: Да, често хората ще интегрират SAP с други системи, в зависимост от това какви модули и т.н., така че има малко. Наистина все още не виждам хора, които разгръщат други приложения на HANA. Това със сигурност е възможно да се направи. И така е повече около пейзажа около инфраструктурата на SAP.
Д-р Робин Блур: Предполагам, че е по-добре да ви предам Дез. Аз съм ви мърдал времето. Дез?
Дез Бланчфийлд: Благодаря. Не, всичко това е добре. Две много бързи, само да се опитате да зададете темата. SAP HANA съществува вече няколко години и хората имаха шанс да го обмислят. Ако трябваше да ни дадете груба оценка на процента на хората, които го изпълняват - тъй като има много хора, които управляват тези неща - какъв според вас процентът на пазара, който знаете, в момента е изчезнал от традиционните SAP реализации до SAP на HANA? Гледаме ли 50/50, 30/70? Какъв, какъв процент от пазара виждате на хора, които са преминали и направиха ход сега срещу фолк, които просто се сдържат и чакат нещата да се подобрят или да се подобрят или да се променят, или каквото и да е в случая?
Бил Елис: Да, всъщност бих казал, че от моя гледна точка бих сложил процента около 20 процента. SAP обикновено е традиционен бизнес. Хората са склонни да бъдат много консервативни и затова хората им ще влачат краката си. Мисля, че това също зависи от това, знаете ли, управлявате ли SAP отдавна или сте вид SMB, който може би е имал по-скоро внедрен SAP? И така, има редица фактори, но като цяло не мисля, че процентът е 50/50. Бих казал, че 50 процента са най-малко умопомрачителни и имат HANA да работи някъде в техния център за данни.
Дез Бланчфийлд: Интересното предприемане, което ни дадохте по-рано, беше, че това е факт в известен смисъл и че часовникът физически и буквално тече на времето за преход. В процеса на това, мислите ли, че хората са разгледали това? Какъв е общият смисъл на народното разбиране, че това е преходна промяна в платформата, не е просто опция, а се превръща в стандартната настройка?
И от гледна точка на SAP, аз съм сигурен, че те се стремят по този начин, защото има значително конкурентно предимство в производителността, но също така, предполагам, те се борят контролно отзад на платформата, вместо да отидат на трета - партийна база данни, сега я връщат към собствената си платформа. Мислите ли, че компаниите всъщност са получили това съобщение? Мислите ли, че хората разбират това и сега го предават? Или все още е нещо като неясно, според вас, на пазара?
Бил Елис: Не мисля, че SAP е срамежлива в общуването и хората, които са ходили на SAPPHIRE, са виждали HANA навсякъде. Така че, мисля, че хората са добре запознати, но човешката природа е това, което е, знаете, някои хора са, някак си, влачат краката си малко.
Дез Бланчфийлд: Защото мисля, че причината, която задавах този въпрос, ще трябва да ми простиш, но аз съм съгласна. Мисля, че не са се срамували да го съобщават. Мисля, че сигналът е изчезнал по много начини. И аз съм съгласен с теб - не знам, че всички все още са скочили. Нали знаете, традиционните предприятия, много големи предприятия, които управляват това, все още са по много начини, не много влачат краката си, а просто се опитват да се справят със сложността на смяната. Защото мисля, че единственото нещо, което вашият инструмент, и със сигурност вашата демонстрация днес, подчерта, и за мен, едно ключово извличане, бих искал всички, слушащи и настроени днес, да седнат и да обърнат внимание на това, е, имате инструмент сега е опростен този процес в съзнанието ми. Мисля, че има куп много нервни CIO и техните екипи под тях, които си мислят: „Как да направя прехода от традиционните RDBMS, релационни системи за управление на бази данни, които познаваме от десетилетия, към изцяло нова парадигма на изчисленията и управление на съхранението в пространство, което все още е сравнително смело? ”в съзнанието ми. Но това е непознато в много отношения и много малко хора са направили тази промяна в други области, че не е като да имат друг раздел от бизнеса, който вече е преминал към изчисляване на паметта. Значи, това е движение или почти нищо в ума им.
И така, едно от нещата, които съм отнел от това повече от всичко - ще ви ударя с въпрос след минута - е, че сега страхът, според мен, е облекчен по много начини и това преди днес, ако бях слушател на CIO, щях да си помисля „Е, как ще направя този преход? Как ще гарантирам същата способност, която имаме в платформата за управление на релационни бази данни и дългогодишен опит на DBA, до нова платформа, в която в момента нямаме умения? “И така, въпросът ми с това е:, смятате ли, че хората са разбрали, че инструментите са налице сега с това, което предлагате, и че могат, като вид, да си поемат дълбоко дъх и да въздъхнат от облекчение, че преходът не е толкова страшен, колкото би могъл да бъде преди този инструмент да е наличен? Мислите ли, че хората са разбрали това или все още е нещо, което просто се бори с прехода към изчисляване в паметта и съхранение в паметта спрямо старите училищни комбинации от NVMe, флаш и диск?
Бил Елис: Да, така че несъмнено има много технологии и инструменти, които могат графично да покажат това, какво се случва и да улеснят определянето на най-добрите потребители на ресурси. Искам да кажа, че наистина помага да се опростят нещата и наистина помага на технологичния персонал наистина да се справи добре. Ей, те ще могат да знаят какво се случва и ще могат да разберат цялата сложност. Така че, абсолютно, инструментите на пазара определено са полезни и затова предлагаме анализ на натоварването за SAP HANA.
Дез Бланчфийлд: Да, мисля, че страхотното в това, което ни показахте днес, е, че при наблюдение на хардуерното парче, частта на операционната система, дори и наблюдение на част от натоварването, което се движи, както казахте, искам да кажа, инструментите са там от известно време. Битът за мен, особено в харесването на HANA, е, че не е задължително да имаме способността да вземем лупа и да надникнем в нея и да видим веднага какво прави вашият инструмент със случващото се със заявките и как са се структурира и къде е това натоварване.
С разгръщанията, които сте виждали досега, като се има предвид, че вие сте буквално най-авторитетните в това пространство във вашата платформа в света, някои от бързите победи, които сте виждали - имате ли някакви анекдотични знания, с които можете да споделите нас около някои от моментите на eureka, аха моментите, където хората са разположили инструменталния набор IDERA, те са открили неща, които просто не са били наясно, в техните платформи и изпълнения, които са имали. Имате ли страхотни анекдотични примери за това, където хората току-що са го разположили, всъщност не знаят какво са имали и изведнъж са изчезнали: "Леле, всъщност не знаехме, че е там?"
Бил Елис: Да, толкова голямо ограничение на родните инструменти е, че ако една заявка за бягство бъде отменена, тя измива информацията и така по принцип нямате история. При нас съхраняването на историята офлайн, като бягство от заявка, ще имате история, ще знаете какво се е случило, ще можете да видите план за изпълнение и така нататък. И така, това ви позволява да помогнете на общността на крайния потребител да работи по-добре, да пише по-добре доклади и т.н. И така, историята е нещо, което наистина е хубаво да има. И едно от нещата, които имах намерение да покажа, е, че можете да разгледате в реално време до четири седмици и след това можете лесно да увеличите мащаба на всеки интересен период от време и след това можете да разкриете основните дейности в шофирането. Просто наличието на тази видимост е нещо, което е много полезно да се знае какво е възникнало тясно място.
Дез Бланчфийлд: Споменахте, че е мулти-потребител, след като бъде внедрен, и бях много впечатлен от факта, че е без агент и ефективно нулево докосване по много начини. Нормално ли е едно разгръщане на вашия инструмент след това да е достъпно за всички от центъра за мрежови операции в NOC, които наблюдават основната инфраструктура, която подкрепя клъстера, до екипа за приложения и разработки? Нормално ли е и да го разгърнете веднъж и те биха споделили това, или предполагате, че хората може да имат екземпляри на модели, гледащи различни части на стека? Как изглежда това?
Бил Елис: Така че базовият екип обикновено ще има много силен интерес към технологичните основи на случващото се в SAP. Очевидно има множество екипи, които ще поддържат цели пейзажи. Парчето HANA е просто фокусирано върху това. Тъкмо отивам по подразбиране към основния екип на SAP като основни потребители на информацията.
Дез Бланчфийлд: Точно така. Впечатлява ме обаче, че ако имам екип за разработка или дори не просто на ниво код, но ако имам екип от учени за данни или анализатори, които извършват аналитична работа върху наборите от данни там, особено като се има предвид, че има значителен тласък към науката за данни, която се прилага за всичко вътре в организациите сега, според мен - и поправете ме, ако греша - струва ми се, че това ще бъде от голямо значение и за тях, защото в много отношения един от сериозните неща, които можете да направите в среда за съхранение на данни, е да разгърнете учен с данни и да му позволите просто да започне да прави ad hoc заявки. Имали ли сте примери за подобно нещо, което се случва там, където магазините са ви звъннали и са казали: „Ние сме хвърлили екип за научни данни, наистина боли, какво можем да направим за тях спрямо това, което правим традиционен оперативен мониторинг и управление? “Това нещо ли е дори?
Бил Елис: Е, да, бих искал да обърна това малко и да отрежа отговора ми ще бъде, че като гледам производителността, осъзнаването на производителността в развитието на QA продукцията, знаете, колкото по-рано се съхранявате, толкова по-малко проблеми, по-малко изненади, които имате. Така че, абсолютно.
Дез Бланчфийлд: Следвайки това, много от инструментите, с които съм имал опит - и съм сигурен, че Робин ще се съгласи - много от инструментите тук, ако имате голям RDBMS, имате нужда от наистина високо ниво - квалифицирани, дълбоко познати, опитни DBA. Някои от изискванията за инфраструктура и платформа, които се срещат със SAP HANA, тъй като в момента той се поддържа в конкретни дистрибуции, съобразени от определен хардуер и така нататък, доколкото ми е известно. Знаеш ли, има хора с десетилетия опит, които не са еднакви. Това, което виждам обаче, е, че това не е задължително изискването с този инструмент. Струва ми се, че можете да разгърнете инструмента си и да го дадете на някои сравнително нови лица и да им дадете силата веднага да намерят неща, които не се представят добре. Случва ли се, че има доста кратка крива на обучение, за да се ускори с това и да получите някаква стойност от неговото внедряване? Знаеш ли, моят общ смисъл е, че не е нужно да имате 20 години опит в управлението на инструмент, за да видите стойността веднага. Бихте ли се съгласили, че това е така?
Бил Елис: О, абсолютно, и до вас, мисля, че много от успеха на внедряването наистина зависи от планирането и архитектурата на средата SAP HANA. И тогава несъмнено има много сложност, много технология, върху която е изградена, но след това просто се свежда до наблюдение на моделите на използване на случващото се. Така че, въпреки че е по-сложен, по някакъв начин е пакетиран и донякъде опростен. Това е много бедно.
Дез Бланчфийлд: Да, така че преди да се върна на Ерик, защото знам, че той има няколко въпроса, особено от някои, които са влезли в Q&A, които изглеждаха интересни, и аз искам да чуя отговора. Традиционно пътуване за някого - споменахте по-рано, че можете да го получите, можете да го изтеглите и да го опитате. Можете ли просто да припомните това бързо за слушане на хора или днес, или фолк, който може да го възпроизведе по-късно? Какви са бързите две или три стъпки, за да стигнат до копие и да го разгърнат и да го изпробват в средата си, преди да го купят? Как изглежда това? Какви са стъпките за това?
Бил Елис: Да. И така, IDERA.com и просто отидете на Продукти и ще видите Анализ на натоварването за SAP HANA. Има страница за изтегляне. Мисля, че ще ви помолят за информация за контакт и продуктът е просто опакован с лицензен ключ, така че можете да го инсталирате с Setup.exe и просто да се търкаля, мисля, много бързо.
Дез Бланчфийлд: Така че, те могат да отидат на вашия уебсайт, могат да го изтеглят. Спомням си, че го гледах преди време и аз проверих снощи и снощи, можете да поискате демонстрация от паметта, където някой от вашия екип ще ви преведе през него? Но всъщност можете да го изтеглите безплатно и да го разгърнете локално в собствената си среда, по ваше време, нали?
Бил Елис: Да.
Дез Бланчфийлд: Отлично. Ами мисля, че повече от всичко това вероятно е нещото, което лично бих посъветвал фолк да е да вземете копие от уебсайта, да вземете част от документацията там, защото знам, че има много добро съдържание там, за да се направи това, и просто опитайте. Поставете го във вашата среда и вижте какво ще намерите. Подозирам, че след като погледнете под капака с вашите среди SAP HANA с инструмента IDERA, ще намерите неща, които всъщност не сте били наясно, че са били там.
Вижте, много ви благодаря за това и благодаря за отделеното време само за въпросите и отговорите с Робин и И. Ерик, ще се върна към вас, защото знам, че някои въпроси и отговори идват от нашите участници.
Ерик Кавана: Да, просто истински бърз тук. Така че, един от присъстващите прави наистина добър коментар тук, просто говори за това как нещата се променят. Казвайки в миналото, паметта се задушаваше, забавяше се от чести пейджинг, в момента CPU се задушава с твърде много данни в паметта. Знаеш ли, има проблеми с мрежата. Винаги ще бъде движеща се цел, нали? Какво виждате като траектория в наши дни по отношение на това къде ще бъдат задръстванията и къде ще се наложи да фокусирате вниманието си?
Бил Елис: Да. Докато не мерите, е трудно да се знае. Едно от нещата за SQL изявленията е, че те ще бъдат двигателите на потреблението на ресурси. И така при обстоятелството, че трябва да имате, например, голямо потребление на памет или консумация на процесор, ще можете да разберете каква дейност е довела до това потребление на ресурси. Сега, не е задължително да искате да го убиете, но вие също искате да сте наясно с това и каквото се случва, колко често се случва, и т.н. Ние сме, все още, нови по отношение на адресирането на целия набор или готварска книга с отговори при различни обстоятелства. И така, това е чудесен въпрос и времето ще покаже. Ще имаме повече информация с течение на времето.
Ерик Кавана: Това е всичко. Е, вие, момчета, сте на много интересно пространство. Мисля, че ще видите много активност през следващите месеци и следващите няколко години, защото аз знам, че SAP, както предложихте в нашето обаждане за съдържание, предостави доста дълъг път на рампа за хората, за да направят прехода до HANA. Но въпреки това тази рампа има край и в определен момент хората ще трябва да вземат някои сериозни решения, така че колкото по-рано, толкова по-добре, нали?
Бил Елис: Абсолютно.
Ерик Кавана: Добре, ние сме изгорили още един час тук на Hot Technologies. Можете да намерите информация онлайн, insideanalysis.com, също techopedia.com. Съсредоточете се върху този сайт за много интересна информация, включително списък на всички наши архиви на тези минали уеб предавания. Но хора, голямо благодаря на всички вас, на нашите приятели от ИДЕРА, на Робин и разбира се, Дез. И ще те догоним следващата седмица, хора. Благодаря отново за отделеното време и внимание. Пази се. Чао чао.
