Autors: Techopedia Staff, 2017. gada 25. janvāris
Izņemšana: Uzņēmējs Ēriks Kavanaghs diskutē par atmiņu skaitļošanu un SAP HANA ar viesiem Dr. Robinu Blooru, Dezu Blanšfīldu un IDERA Bilu Ellisu.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Ēriks Kavanaghs: Labi, dāmas un kungi. Sveicināti un vēlreiz sveicam. Trešdien ir pulksten četri Austrumu laiki un pēdējie pāris gadi nozīmē, ka atkal ir laiks Hot Technologies. Jā, tiešām, mans vārds ir Ēriks Kavanaghs, es būšu jūsu šodienas sarunas vadītājs.
Un ļaudīm, mēs šodien runāsim par foršām lietām. Mēs iegremdēsimies atmiņu pasaulē, precīzs nosaukums ir “Into the Future: On-Ramp for In-Memory Computing”. Mūsdienās tas ir viss dusmās, un ar labu iemeslu, galvenokārt tāpēc, ka atmiņa ir daudz ātrāka nekā paļaušanās uz vērpšanas diskiem. Tomēr izaicinājums ir tas, ka jums ir jāpārraksta daudz programmatūras. Tā kā mūsdienu programmatūra, lielākoties, ir izstrādāta, paturot prātā disku, un tas patiešām maina lietojumprogrammas arhitektūru. Ja jūs izstrādājat lietojumprogrammu, lai gaidītu vērpšanas disku, jūs vienkārši darāt lietas savādāk nekā tad, ja jums ir visas šīs atmiņas tehnoloģijas iespējas.
Šeit ir informācija par jūsu patiesību, uzklikšķiniet man uz čivināt, @eric_kavanagh. Es vienmēr cenšos sekot līdzi un retweetēt vienmēr, kad kāds mani piemin.
Kā es teicu, šodien mēs runājam par atmiņu un jo īpaši par SAP HANA. Jūsu patiesais pēdējais gads ir pavadīts, lai patiešām labi iepazītu SAP kopienu, un man jāsaka, ka tā ir aizraujoša vide. Cepures cilvēkiem, kuri vada šo operāciju un ir priekšējās rindās, jo SAP ir neticami laba operācija. Tas, kas viņiem patiešām ir ļoti labs, ir uzņēmējdarbība. Viņi, protams, lieliski prot arī tehnoloģijas, un viņi patiešām ir ieguldījuši lielas investīcijas HANA. Patiesībā es atceros - tas bija iespējams apmēram pirms sešiem vai septiņiem gadiem -, ka mēs faktiski strādājām ASV gaisa spēku labā, un mēs saņēmām kādu no SAP ienākt un mums savlaicīgi paskatīties uz pasaules HANA un tas, kas bija plānots. Un, maigi izsakoties, SAP Labs ļaudis bija veltījuši daudz laika un pūļu, lai saprastu, kā izveidot šo arhitektūru, kas atkal ir pilnīgi atšķirīga no tradicionālās vides, jo jums viss ir atmiņā. Tātad, viņi runā par darījuma veikšanu un analītisku veikšanu ar vieniem un tiem pašiem datiem atmiņā, nevis tradicionālajam veidam, kas tiek izvilkts, ievietots kubā, piemēram, analizēts tur, salīdzinot ar darījumu, kas notiek pavisam savādāk.
Šī ir interesanta telpa, un mēs no cita pārdevēja, IDERA, uzzināsim mazliet par to, kā viss šie materiāli darbosies, un ko atklāti runājot par uzbrauktuvi. Tātad, mēs uzklausīsim Dr. Robinu Blooru, mūsu pašu galveno analītiķi šeit, The Bloor Group; Dezs Blanšfīlds, mūsu datu zinātnieks un pēc tam labs draugs Bils Elliss no IDERA. Tāpēc es atdošu atslēgas doktoram Robinam Blooram, kurš to atņems.
Dr Robins Bloors: Jā, kā Ēriks teica, laiks, kuru mēs vispirms saņēmām SAP HANA, bija atpakaļ pirms daudziem gadiem, tagad. Bet tas bija ļoti interesanti, konkrētais laiks bija ļoti interesants. Mēs būtu iekļuvuši vienā vai divos uzņēmumos, kas vienā vai otrā veidā piedāvā atmiņas tehnoloģiju. Bija pilnīgi skaidrs, ka atmiņā bija jānāk. Un tas īsti nebija, kamēr SAP piecēlās un pēkšņi neuzsāka HANA. Es domāju, tas bija šoks, kad redzēju, kā SAP to dara. Tas, tāpat kā, bija šoks, jo es gaidīju, ka tas nāks no citurienes. Es gaidīju, ka tas būs, jūs zināt, Microsoft vai Oracle, vai IBM, vai kādam tamlīdzīgam. Ideja, ka SAP to dara, mani tiešām pārsteidza. Es domāju, ka tam nevajadzēja būt, jo SAP ir viens no stratēģiskajiem pārdevējiem, un, jūs zināt, gandrīz viss, kas notiek nozarē, nāk no viena no tiem.
Jebkurā gadījumā viss punkts par atmiņu, es domāju, mēs sapratām, ka mēs mēdzam par to runāt, ka, tiklīdz jūs faktiski iedziļināties atmiņā - tas nav par datu ievietošanu atmiņā, tas ir par apņemšanos ideja, ka atmiņas slānis ir sistēmas ieraksts - tiklīdz migrējat sistēmas ierakstu uz atmiņu, disks sāk kļūt par viena veida nodošanas nesēju, un tas kļūst par citu lietu. Un es domāju, ka tas bija ļoti aizraujoši, kad tas sāka notikt. Tātad, tas ir beidzies, lai vērptu disku. Drīzumā vērpšanas disks būs pieejams tikai muzejos. Es neesmu pārliecināts, cik drīz tas ir, bet būtībā cietvielu disks tagad atrodas Mūra likuma līknē, tas jau ir desmit reizes ātrāk nekā rūsējošā rūsēšana, kā viņi to tagad sauc, un diezgan drīz tas joprojām būs ātrāks un tad tas nozīmē, ka diska lietošanas gadījumu vienkārši kļūst mazāk un mazāk.
Un ziņkārīgais fakts - tradicionālā DBVS - patiesībā daudz vērpšanas diska tika uzbūvēts daudz tradicionālās programmatūras, tas pieņēma vērpšanas disku. Tam bija visdažādākās fiziskā līmeņa iespējas, kuras tika cītīgi ieprogrammētas, lai izmantotu vērpšanas disku, pēc iespējas ātrāk veicot datu izguvi. Un tas viss tiek mazgāts. Tikai pazūd, jūs zināt? Un tad acīmredzot bija ļoti - es nezinu, ienesīgs, es domāju, ka tas galu galā būs - atvēršana atmiņā esošai datu bāzei, kas mēģināja ieņemt pozīciju, ko lielās datu bāzes, Oracle un Microsoft, SQL Serveris un IBM DB2, tas aizņēma atmiņā esošo vietu, un bija ļoti interesanti skatīties, kas soļo uz priekšu un dara.
Parunāsim par atmiņas kaskādi; tas ir tikai pieminēšanas vērts. Tas ir arī iemesls, kāpēc to pieminēt, iemesls, kāpēc es to iemetu, patiesībā bija tikai informēšana visiem, kad es runāju par atmiņu, visi šie slāņi, par kuriem es runāju, patiesībā ir atmiņā. Bet jūs pēkšņi saprotat, apskatot šo, tas ir hierarhisks veikals, tā nav tikai atmiņa. Un tāpēc attiecas arī uz gandrīz visu, ko mēs jau labu laiku atpakaļ uzzinājām par hierarhisko veikalu. Un tas arī nozīmē arī to, ka jebkurai atmiņā esošai datu bāzei ir jāvirzās pa šo ceļu, daži jūs vienkārši staigājat pa pašu RAM, jūs zināt. Un tas vienkārši ir kļuvis lielāks un lielāks, un tagad tas tiek mērīts megabaitos. Bet jums ir L1 kešatmiņa, kas ir simts reizes ātrāka par atmiņu, L2 kešatmiņa - 30 reizes ātrāka nekā atmiņa - un L3 kešatmiņa - apmēram 10 reizes ātrāka nekā atmiņa. Tātad, jūs zināt, ir daudz tehnoloģiju - labi, diezgan daudz tehnoloģiju -, ir pieņēmusi stratēģiju izmantot šos kešatmiņus kā sava veida krātuves vietu, lai pabeigtu lietas, jo īpaši datu bāzu tehnoloģiju. Tātad, jūs zināt, tā ir viena ietekme.
Tad mums ir parādījies 3D XPoint un IBM PCM. Un tas ir gandrīz RAM ātrums, būtībā ir tas, ar ko abi šie pārdevēji lepojas. Lietošanas gadījumi, iespējams, ir atšķirīgi. Agrīnie eksperimenti ar to vēl nav pabeigti. Mēs nezinām, kā tas ietekmēs operatīvās atmiņas izmantošanu un atmiņā esošo datu bāzu tehnoloģiju šajā jautājumā. Pēc tam jums ir RAM salīdzinājumā ar SSD. Pašlaik operatīvā atmiņa ir aptuveni 300 reizes ātrāka, bet, protams, šis skaits samazinās. Un SSD salīdzinājumā ar disku, kas ir apmēram 10 reizes ātrāks, ja es to saprotu. Tātad, tāda ir jūsu situācija. Tas ir hierarhisks veikals. Skatoties uz to citā veidā, atmiņā, protams, ir pavisam kas cits. Tātad, augšējā diagramma parāda divas lietojumprogrammas, no kurām abas, iespējams, piekļūst datu bāzei, taču noteikti piekļūst datiem par rūsējošo vērpšanu. Un tas, kā jūs faktiski piespiežat lietas plūst caur tīklu, atkarībā no tā, kādas atkarības ir apkārt, vai jums ir ETL. Tātad, tas nozīmē, ka, jūs zināt, dati nonāk uz vērpjošās rūsas un pēc tam izdalās ar vērpjošu rūsu, lai nokļūtu jebkur un lai nokļūtu jebkur, tie atgriežas pie vērpjošās rūsas, kas ir trīs kustības. Un paturiet prātā, ka atmiņa var būt simts tūkstošus reižu ātrāka nekā vērpšanas disks, un jūs noteikti saprotat, ka datu paņemšana un ievietošana atmiņā šo lietu padara pavisam citu.
Tātad, jūs, iespējams, domājāt, kas notiks uz ekrāna, kas atrodas šeit, jūs, iespējams, domājāt, ka vienā vai otrā veidā ETL faktiski pāriet no datiem uz datiem atmiņā. Bet patiesībā tas varētu to nedarīt; patiesībā jums var būt situācija labajā pusē šeit, kur divas programmas faktiski var aktivizēt to pašu atmiņu. Protams, atmiņā esoša datu bāze varētu jums dot šo iespēju, ja vien jums ir bloķēšana un viss pārējais, kas tam ir organizēts. Tātad tas nemaina tikai lietu ātrumu, tas maina arī to, kā jūs faktiski konfigurējat lietojumprogrammas un visas datu plūsmas.
Tātad, tā ir milzīga veida ietekme. Tātad, atmiņa ir graujoša, vai ne? Un mums tas būtu jāgūst no tā, ko es teicu. Apstrāde atmiņā pašlaik ir paātrinātājs, bet tas kļūs par normu. Tas tiks izmantots, tiek piemērots atbilstoši lietojumprogrammas vērtībai, un tāpēc ir ļoti, ļoti interesanti, ka SAP patiesībā nāks klajā ar ERP programmatūras versiju, kas ir atmiņā. Un pilnīgi iespējams latentuma uzlabojums līdz trim apjomiem un faktiski pat vairāk, nekā tas ir iespējams, atkarībā no tā, kā jūs to darāt. Tātad, dodoties atmiņā, jūs gūstat milzīgus ātruma uzlabojumus. Un rezultāts, SAP HANA's S / 4 - kuru viņi ir izlaiduši, es domāju, labi, cilvēki saka, ka tas joprojām tiek izlaists, bet tas noteikti tika izlaists pagājušajā gadā - tas ir spēļu mainītājs, ņemot vērā SAP klientu bāzi. Es domāju, ka tur ir 10 000 uzņēmumu, kas izmanto SAP ERP, un, jūs zināt, visi tie ir lieli uzņēmumi. Tātad, ideja par to, ka viņiem visiem ir stimuls iedziļināties atmiņā un izmantot savu pamatelementu, jo ERP gandrīz vienmēr ir fundamentālas lietojumprogrammas, kuras darbojas uzņēmumi, tas ir tikai milzīgs spēļu mainītājs, un tas būs ļoti interesanti. Bet, protams, tas viss izklausās ļoti labi, taču tas ir jākonfigurē saprātīgi un tas ir labi jāuzrauga. Tas nav tik vienkārši, kā izklausās.
To sakot, es domāju, ka nodošu bumbu tālāk - kurš ir šis puisis? Ak, Austrālijas puisis Dez Blanchfield.
Dez Blanchfield: Ļoti smieklīgi. Vienmēr smaga rīcība, kas jāievēro, Dr Robin Bloor. Paldies, ka šodien esat manī. Tātad, liela tēma, bet aizraujoša. Tātad, es esmu izvēlējies attēlu, kuru es bieži uzburtu prātā, domājot par mūsdienu datu ezeru un uzņēmumu datu noliktavām un maniem mazajiem dārgakmeņiem. Tātad, es esmu ieguvis šo skaisto ezeru, ko ieskauj kalni un iznāk viļņi, un viļņi sabrūk virs šīm klintīm. Tas ir veids, kādā es šajās dienās garīgi iztēlojos, kā tas izskatās lielā datu ezerā. Viļņi ir pakešdarbi un reāllaika analītika tiek izmesta uz datiem, kas ir ieži. Un, domājot par to kā fizisku ezeru, tas man atgriež modināšanas zvanu, ka, jūs zināt, datu noliktavu mērogs, ko mēs tagad uzbūvējam, ir iemesls, kāpēc mēs nācām klajā ar šo monētu un termiņu Datu ezers ir tāds, ka tie ir ļoti lieli un dziļi, un reizēm tajos var būt vētras. Kad mēs to darām, jums vienmēr ir jāatrisina tas, kas rada vētru.
Tāpēc man šķiet, ka šīs lietas tēmā šis sirēnas izsaukums uz skaitļošanas atmiņā ir ļoti spēcīgs un pamatota iemesla dēļ. Tas rada tik daudz nozīmīgu komerciālu un tehnisku ieguvumu. Tā ir diskusija pāris stundas citā dienā. Bet vispārējā pāreja uz datorizēšanu atmiņā, pirmkārt, es tikai vēlos aptvert, kā mēs šeit nokļuvām un kas to padara iespējamu, jo tas kaut kā rada pamatu tam, kur daži no izaicinājumiem var atrasties vispirms un kas mums jāzina un domājot par to, ka mūsu pasaulē mēs attālinamies no tradicionālajiem vecajiem vērpšanas diska, kurā tiek glabāti dati, un tiek meklēti pa disku un no tā, atmiņā un no atmiņas, un no centrālajiem procesoriem, mēs tagad noņemam gandrīz vienu no šiem veseliem slāņiem, ir vērpšanas disks. Tā kā atcerieties, ļoti agrīnajās skaitļošanas dienās, arhitektoniski, mēs ilgi nevirzījāmies no lieldatoru vai vidusšķiras pasaules, ko mēs sākotnēji domājām par galveno atmiņu un bungu glabāšanu, jūs zināt.
Kā sacīja Dr Robins Bloors, pieeja, ko mēs izmantojām datu pārvietošanai pa datoru arhitektūru, patiesībā kādu laiku, pāris desmitgažu laikā, dramatiski nemainījās. Ja jūs domājat par faktu, ka, jūs zināt, mūsdienīgā skaitļošana tehniski ir bijusi apmēram tad, ja jūs apžēlojaties par sodu, kādus 60 nepāra gadus, jūs zināt, sešas desmitgades un vairāk, un tas ir tādā nozīmē, ka jūs varat nopērciet kasti pie plaukta, it kā būtu. Pāreja uz jauno arhitektūru, manuprāt, patiešām notika, kad mēs pārgājām no domāšanas par lieldatoriem un vidējo diapazonu, kā arī pamat atmiņu un bungu glabāšanas arhitektūru uz drosmīgu vai superdatoru, it īpaši Seymour Cray, piemēram, tādām lietām kā šķērsvirziena pamatplani. kļuva par lietu. Tā vietā, lai būtu tikai viens maršruts, lai pārvietotu datus pa aizmugures plakni vai mātesplati, kā mūsdienās to sauc. Un iekšējā atmiņa, jūs zināt, mūsdienās cilvēki patiesībā nedomā par to, ko tas patiesībā nozīmē, sakot DIMM un SIMM. Bet, SIMM ir viena iekšējā atmiņa, un DIMM ir divējāda iebūvēta atmiņa, un mēs esam ieguvuši daudz sarežģītāku atmiņu, un kopš tā laika ir desmitiem dažādu atmiņu tipu dažādām lietām: daži video, daži tikai vispārīgām lietojumprogrammām, daži iebūvēti CPU.
Tātad notika liela pārbīde uz jaunu datu glabāšanas un piekļuves veidu. Mēs gatavojamies iziet šo pašu maiņu citā veselā paaudzē, bet ne tik daudz pašā aparatūrā, bet gan aparatūras pieņemšanā biznesa loģikā un datu loģikas slānī, un tā, manuprāt, ir vēl viena liela paradigmas maiņa. .
Bet tikai īsi par to, kā mēs šeit nokļuvām. Es domāju, ka aparatūras tehnoloģija ir uzlabojusies un dramatiski uzlabojusies. Mēs aizgājām no tā, ka mums bija CPU, un galvenā ideja bija diezgan moderna koncepcija. Mēs uzskatām to par pašsaprotamu tagad, kad mūsu tālruņiem ir divi vai četri serdeņi un mūsu datoriem ir divi vai četri vai pat astoņi serdeņi darbvirsmā un astoņi un 12 un vairāk, kā jūs zināt, 16 un 32 pat servera platformā . Bet patiesībā tā ir diezgan moderna lieta, ka kodoli ir kļuvuši par spēju CPU iekšienē un ka mēs pārgājām no 32 bitu uz 64 bitiem. Tur notika pāris lielas lietas: mēs saņēmām lielāku pulksteņa ātrumu uz vairākiem kodoliem, lai mēs varētu rīkoties paralēli un katrs no šiem kodoliem varētu palaist vairākus pavedienus. Pēkšņi mēs vienlaikus varētu vadīt daudzas lietas ar vieniem un tiem pašiem datiem. Sešdesmit četru bitu adreses atstatums mums deva līdz diviem terabaitiem operatīvās atmiņas, kas ir fenomenāls jēdziens, bet tagad tā ir lieta. Jūs zināt, mātesplates, daudzceļu aizmugures lidmašīnu arhitektūra, reiz jūs varētu darīt lietas tikai vienā virzienā: atpakaļ un uz priekšu. Un tāpat kā dienas laikā ar Cray skaitļošanu un dažiem tā laika superdatoru dizainiem, un tagad galddatoros un parastos stendos, sava veida, uz galddatoriem paredzētiem, statīvam piestiprināmiem datoriem, jo tiešām, lielākā daļa mūsdienu Personālie datori tagad ir pārdzīvojuši lieldatoru, vidējo diapazonu, mikro galddatoru laikmetu, un mēs esam tos pārvērtuši par serveriem.
Un liela daļa šo superdatoru iespēju, tas superdatoru klases dizains, tika iespiests vispārpieņemtajos standarta komponentos. Jūs zināt, ka šajās dienās jūs domājat uzņemt ļoti lētus statīvam piestiprināmus datorus un simtiem, ja ne tūkstošiem, ievietot tos plauktos, kā arī palaist viņiem atvērtā pirmkoda programmatūru, piemēram, Linux, un izvietot uz tā SAP HANA līdzīgās versijas. ziniet, mēs to bieži uztveram kā pašsaprotamu. Bet tā ir ļoti jauna, aizraujoša lieta, un tā nāk ar sarežģītību.
Arī programmatūra kļuva labāka, jo īpaši atmiņas pārvaldība un datu nodalīšana. Es par to neiedziļināšos daudz detalizētāk, bet, ja paskatāties uz lielajām pārmaiņām pēdējos 15 vai tik gados vai pat mazāk, kā tiek pārvaldīta atmiņa, īpaši dati RAM un kā dati tiek sadalīti RAM, lai, kā jau iepriekš minēja Dr. Robins Bloors, vai, uz ko atsaucoties, jūs zināt, lietas var lasīt un rakstīt vienlaikus, neietekmējot viena otru, nevis gaidīšanas laikus. Daudz ļoti jaudīgu funkciju, piemēram, saspiešana un šifrēšana mikroshēmā. Šifrēšana kļūst arvien svarīgāka lieta, un mums tas nav obligāti jādara programmatūrā, operatīvajā atmiņā un centrālā procesora telpā, kas tagad faktiski notiek mikroshēmā. Tas paātrina lietas dramatiski. Un izplatīta datu glabāšana un apstrāde - atkal lietas, kuras mēs kādreiz uzskatījām par superdatoriem un paralēlo apstrādi, mēs tagad to uzskatām par pašsaprotamu, piemēram, SAP HANA, Hadoop un Spark, un tā tālāk.
Tā visa ir šī augstas veiktspējas skaitļošana, HPC iespējas nonāca uzņēmumā, un tagad uzņēmums bauda ieguvumus, kas nāk ar ieguvumiem no veiktspējas un tehnoloģiju telpas, kā arī tehniskajiem ieguvumiem un komerciālajiem ieguvumiem, jo, jūs zināt, dramatiski tiek samazināts samazināts laiks līdz vērtībai.
Bet es izmantoju šo stāsta attēlu, kuru lasīju pirms kāda laika, par kungu, kurš no Lego uzbūvēja datora lietu, jo tas vienmēr nāk prātā, domājot par dažām no šīm lietām. Un tas ir tas, kas, šķiet, ir lieliska ideja brīdī, kad jūs to sākat būvēt, un tad jūs to dabūjat pusceļā un saprotat, ka patiesībā ir ļoti sarežģīti salikt visus Lego bitus un izveidot pamatīgu, pietiekami solīdu lietu ievietot mātesplati utt., kas veidos lietu personālajam datoram. Un galu galā jūs saprotat, ka visi mazie biti nav pareizi salipuši kopā, un jums ir jābūt mazliet uzmanīgiem par to, kurus mazos bitus jūs salīmējat, lai padarītu to stabilu. Un tā ir ļoti jauka ideja, bet tas ir modināšanas zvans, kad esat nokļuvis pusceļā un saprotat: “Hmm, varbūt man vienkārši vajadzēja nopirkt 300 USD lielu datoru lietu, bet es to pabeigšu tagad un kaut ko no tā iemācīšos.”
Manuprāt, tā ir lieliska analoģija tam, kā veidot šīs ļoti sarežģītās platformas, jo tas ir labi un labi, lai to izveidotu un nonāktu vidē, kurā jums ir maršrutētāji un slēdži, serveri un statīvi. Un jums ir sakopoti CPU, RAM un operētājsistēma. Un jūs tam pievienojat kaut ko līdzīgu HANA, kas paredzēta izplatīšanai atmiņā un datu glabāšanai un datu pārvaldībai. Jūs izveidojat SAP steku, tam papildus iegūstot datu bāzes iespējas, pēc tam ielādējot datus un biznesa loģiku, un tam sākat piemērot dažus lasījumus, rakstus un vaicājumus utt. Jums jāpaliek pie I / O, un jums ir jāplāno lietas un jāpārvalda darba slodze un daudznozaru darbs utt. Šī kaudze kļūst ļoti sarežģīta, ļoti ātri. Tā ir sarežģīta kaudze pati par sevi, ja tā ir tikai vienā mašīnā. Reiziniet, ka ar 16 vai 32 mašīnām tas kļūst ļoti, ļoti nenozīmīgs. Kad jūs reizināt līdz simtiem un galu galā tūkstošiem mašīnu, lai pārietu no 100 terabaitiem uz petabaitu mērogu, tas ir biedējošs jēdziens, un tās ir realitātes, ar kurām mēs tagad saskaramies.
Tātad jūs galu galā pieņemat pāris lietas, kas arī ir palīdzējušas mainīt šo pasauli, un tas ir, ka diska vieta kļuva smieklīgi lēta. Jūs zināt, kādreiz jūs tērējāt 380 līdz 400 tūkstošus dolāru uz gigabaitu cietā diska, kad tas bija milzīgs cilindrs, kura izmērs bija - kaut kas, kura pacelšanai bija nepieciešams iekrāvējs. Mūsdienās tas ir atkarīgs no veida, viena vai diviem centiem par gigabaitu preču diska vietas. Un RAM darīja to pašu. Šīs divas J-līknes abos šajos grafikos, starp citu, ir katra desmitgade, tātad citiem vārdiem sakot, mēs skatāmies uz diviem 10 gadu, 20 gadu cenu samazināšanas blokiem. Bet es tos sadalīju divās J-līknēs, jo galu galā labajā pusē tikai kļuva punktota līnija un jūs neredzējāt detaļas, tāpēc es to mainīju. Gigabaits operatīvās atmiņas pirms 20 gadiem bija kaut kas aptuveni sešarpus miljonu dolāru vērtībā. Mūsdienās, ja jūs maksājat vairāk nekā trīs vai četrus dolārus par gigabaitu operatīvo atmiņu par preču aparatūru, kuru jūs nolaupāt.
Šis nozīmīgais cenu samazinājuma kritums pēdējās divās desmitgadēs ir nozīmējis, ka tagad mēs varam pāriet ārpus diska vietas un tieši RAM, ne tikai megabaitu līmenī, bet tagad terabaitu līmenī un izturēties pret RAM tā, kā tas ir disks. Tomēr izaicinājums tam bija tas, ka operatīvā atmiņa bija īslaicīga - tas nozīmē kaut ko tādu, kas ilgst īsu laika posmu -, tāpēc mums nācās izdomāt veidus, kā šajā telpā nodrošināt noturību.
Un tā, mans viedoklis šeit ir tas, ka atmiņu skaitļošana nav paredzēta vājširdīgajiem. Šāda ļoti liela apjoma atmiņā esošo datu apstrāde un apstrāde ap to ir interesants izaicinājums; kā es jau norādīju iepriekš, tas nav domāts vājprātīgajiem. Tātad, viena lieta, ko mēs esam iemācījušies no liela apjoma un augsta blīvuma atmiņas skaitļošanas pieredzes, ir tāda, ka mūsu veidotā sarežģītība rada risku daudzās jomās.
Bet apskatīsim to tikai no uzraudzības un reakcijas viedokļa. Kad mēs domājam par datiem, tas sākas diskā, tas atrodas datu bāzēs diskos, un mēs to iespiežam atmiņā. Kad tas ir palicis atmiņā un izdalīts, un ir tā kopijas, mēs varam izmantot daudz tā kopiju, un, ja tiek veiktas kādas izmaiņas, tās var atspoguļot visā atmiņā, tā vietā, lai dotos uz un no, un pāri aizmugurē divi dažādi līmeņi, tas nonāk atmiņā un iziet no tā. Mēs esam pabeiguši šo hiperskalu aparatūras platformu, kas ļauj to izdarīt tagad. Ja mēs runājam par hiperskalibrēšanu, tas ir grūtāk smieklīgi blīvā līmenī, un ir ļoti augsta blīvuma atmiņa, ļoti augsts CPU, serdeņu un diegu skaits. Tagad, lai to atbalstītu, esam ieguvuši ļoti sarežģītas tīkla patoloģijas, jo datiem kaut kad jāpārvietojas pa tīklu, ja tas notiek starp mezgliem un klasteriem.
Tātad, galu galā ar ierīču kļūmju atlaišanu kļūst problēma, un mums ir jāuzrauga ierīces un to daļas. Mums šajā platformā ir jābūt iebūvētai elastīgai datu kļūmju dublēšanai un jāuzrauga tā. Mums ir jābūt iebūvētai izkliedētās datu bāzes elastīgumam, tāpēc mums ir jāuzrauga datu bāzes platforma un jākontrolē tā iekšpusē. Mums ir jāuzrauga izkliedētā apstrādes plānošana, kas notiek dažos procesos līdz pat aptaujai un vaicājumam, kā arī ceļš, kuru vaicājums ved, un veids, kā vaicājums tiek strukturēts un izpildīts. Kā tas izskatās, vai kāds ir izdarījis SELECT * uz “blah” vai arī viņi tiešām ir veikuši ļoti gudru un labi strukturētu vaicājumu, kas viņiem ļaus iegūt nominālo, minimālo datu daudzumu, kas nāk pāri aizmugurējās sienas arhitektūrai? Mums ir daudznozaru darba slodzes, vairāki lietotāji un vairākas grupas, kuras darbojas vienādas vai vairākas darba slodzes un pakešdarbi, un reāllaika plānošana. Un mēs esam ieguvuši šo pakešu un reālā laika apstrādes apvienojumu. Dažas lietas vienkārši darbojas regulāri - stundu, dienu, nedēļu vai mēnesi - citas lietas ir pieprasītas. Kāds tur varētu sēdēt ar planšetdatoru, kurš vēlas izveidot ziņojumu reāllaikā.
Un atkal mēs nonākam pie visa šī jautājuma, ka sarežģītība, kas rodas šajos gadījumos, nav tikai izaicinājums tagad, tas ir diezgan biedējoši. Un mums ir šī realitātes pārbaude, vai atsevišķs veiktspējas jautājums, tikai viens veiktspējas jautājums pats par sevi, var ietekmēt visu ekosistēmu. Un tā mēs nonākam pie šī ļoti jautrā izaicinājuma - uzzināt, kur ir ietekme? Un mums ir šis izaicinājums: vai mēs esam reaģējoši vai proaktīvi? Vai mēs vērojam lietu reāllaikā un redzam, ka kaut kas notiek “sprādzienā” un reaģējam uz to? Vai arī mēs esam redzējuši kāda veida tendences un sapratuši, ka mums aktīvi jāiet uz to? Tā kā galvenais ir tas, ka visi vēlas kaut ko ātru, lētu un vieglu. Bet mēs nonākam pie šiem scenārijiem, uz kuriem es gribu atsaukties, un savu iecienīto Donalda Rumsfelda mīkla līniju - kas, manuprāt, attiecas uz visiem šiem ļoti sarežģītās situācijas scenārijiem - un tas ir, ka mums ir zināmi zināmie, jo tas ir kaut kas mēs projektējām un uzbūvējām, un tas darbojas kā plānots. Mums ir zināmi nezināmie ar to, ka nezinām, kas, kad un kur skrien, ja tas ir nepieciešams. Un mums ir nezināmi nezināmi, un tās ir lietas, kuras mums jāuzrauga un jāpārbauda. Tā kā realitāte ir tāda, kā mēs visi zinām, jūs nevarat pārvaldīt kaut ko, ko nevarat izmērīt.
Tātad, lai iegūtu pareizos rīkus un pareizās iespējas uzraudzīt mūsu CPU plānošanu, meklējiet gaidīšanas laikus, uzziniet, kāpēc lietām ir jāgaida grafika rindās cauruļvados. Kas notiek atmiņā, kāda veida izmantošana tiek veikta, kāda veida performance mums paliek atmiņā? Vai sīkumi tiek sadalīti pareizi, vai tie tiek izplatīti, vai mums ir pietiekami daudz mezglu, kas glabā tā kopijas, lai tiktu galā ar darba slodzēm, kas tiek uz tām izmestas? Kas notiek ar procesa izpildi prom no operētājsistēmas procesiem? Vai paši darbi darbojas, atsevišķas lietotnes un dēmoni, kas tos atbalsta? Kas notiek šajos procesos, jo īpaši vaicājumu strukturēšanā un kā šie vaicājumi tiek izpildīti un apkopoti? Un vai visu šo procesu veselība ir izlikta kaudzē? Jūs atkal zināt, vai gaidīšanas laiks ir pareizs, vai tas ir jāgaida, kur tas tiek gaidīts, vai tas gaida atmiņas nolasīšanu, I / O, CPU, I / O visā tīklā gala lietotājam ?
Un tad pie šī brīža es tikko ātri minēju, pirms es apņemos, un tas ir, kā mēs tuvojamies jautājumu risināšanas un reakcijas laikiem uz tiem? Vai mēs vērojam reālā laikā un reaģējam uz lietām, kas ir vismazāk ideālais scenārijs, bet pat tad labāk to darīt, nekā nezināt un saņemt palīdzības dienesta zvanu un pateikt, ka kaut kas noiet greizi, un mums tas ir jāizseko ? Vai arī mēs to darām proaktīvi un skatāmies, kas notiek zem līnijas? Tātad, citiem vārdiem sakot, vai mēs redzam, ka mums trūkst atmiņas un ir jāpievieno vairāk mezglu? Vai mēs veicam tendenču analīzi, vai mēs plānojam kapacitāti? Un vai tajā visā mēs uzraugām vēsturiskos izpildes laikus un domājam par jaudas plānošanu vai arī vērojam to reāllaikā un proaktīvi plānojam un veicam kravas līdzsvarošanu? Un vai mēs zinām darba slodzes, kas notiek vispirms? Vai mēs zinām, kas ko dara mūsu klasterī un kāpēc?
Aprēķini atmiņā ir ļoti jaudīgi, taču ar šo jaudu tā ir gandrīz viena no šīm lietām, piemēram, pielādēts lielgabals un tu spēlē ar tiešu munīciju. Ja neesat piesardzīgs, galu galā varat nošaut sevi kājā. Tātad šī atmiņā aprēķinātā jauda nozīmē tikai to, ka mēs daudz ātrāk un ātrāk varam darboties ļoti izplatītās un diskrētās datu kopās. Bet tad tam ir lielāks pieprasījums no tiešajiem lietotājiem. Viņi pierod pie šīs varas, un viņi to vēlas. Viņi vairs negaida, ka darbu veikšanai vajadzīgas nedēļas un pārskati tiek parādīti vienkāršā vecā papīra formā. Pēc tam zem visa tā ikdienas uzturēšana ir apņemta ar labošanu, atjaunināšanu un uzlabošanu. Un, ja jūs domājat par apstrādi 24 stundas diennaktī, izmantojot iebūvēto atmiņu, šo datu pārvaldību, visā tajā ietilpstošās slodzes pārvaldību, tas viss ir atmiņā, tehniski īslaicīgā platformā, ja mēs sāksim lietot ielāpus un atjauninājumus, tur nāk arī ar virkni citu pārvaldības un uzraudzības izaicinājumu. Mums jāzina, ko varam izmantot bezsaistē, kad mēs to varam uzlabot un kad mēs to atgriežam tiešsaistē. Un tas noved pie mana pēdējā jautājuma, proti, tā kā mēs kļūstam arvien sarežģītāki šajās sistēmās, tas nav kaut kas tāds, ko cilvēks var darīt, vienkārši sūkot īkšķi un velkot viņam ausi. Nav vairs nekādu zarnu sajūtu. Mums tiešām ir vajadzīgi atbilstoši rīki, lai pārvaldītu un nodrošinātu šo augsto veiktspēju skaitļošanas un datu pārvaldībā.
Paturot to prātā, es nodošu mūsu draugam no IDERA un dzirdēsim, kā viņi ir izturējušies pret šo izaicinājumu.
Bils Elliss: Liels paldies. Es kopīgoju savu ekrānu, un šeit mēs ejam. Tātad ir patiesi pazemīgi vienkārši apsvērt visas tehnoloģijas un visus cilvēkus, kuri ieradās mūsu priekšā, lai padarītu pieejamu šo saturu, kas ir pieejams 2017. gadā. Mēs runāsim par SAP HANA darba slodzes analīzi - pamatā datu bāzes uzraudzības risinājumu: visaptverošs, bez aģentiem, nodrošina reāllaiku un veido vēsturi, un tāpēc jūs varat redzēt, kas ir noticis pagātnē. SAP S / 4 HANA piedāvā labākas, ātrākas un lētākas iespējas. Es nesaku, ka tas ir lēts, es tikai saku, ka tas ir lētāks. Pēc veida, kas tradicionāli notika, bija tas, ka jums būs galvenais ražošanas piemērs - iespējams, darbosies ar Oracle lielākā veikalā, iespējams, SQL Server - un tad jūs izmantotu šo ETL procesu un jums būtu vairākas, sava veida, patiesības versijas. . Un tas ir ļoti dārgi, jo par katru no šīm individuālajām vidēm jūs maksājāt par aparatūru, operētājsistēmu un Oracle licenci. Un pēc tam jums vajadzēs, lai cilvēki saskaņotu vienu patiesības versiju ar nākamo patiesības versiju. Tātad šī vairāku versiju ETL apstrāde bija tikai lēna un ļoti, ļoti apgrūtinoša.
Un tā, HANA, būtībā viens HANA gadījums, iespējams, var aizstāt visus šos citus gadījumus. Tātad, tā ir lētāka, jo tā ir viena aparatūras platforma, viena operētājsistēma, nevis multiplikācijas. Tātad S / 4 HANA patiešām maina visu, un jūs galvenokārt skatāties uz SAP attīstību no R / 2 uz R / 3, dažādiem uzlabošanas pakotnēm. Tagad mantotā sistēma ir pieejama līdz 2025. gadam, tāpēc jums ir astoņi gadi, līdz jūs patiešām esat spiesti migrēt. Lai gan mēs redzam cilvēkus, jūs zināt, iedziļināmies viņu kāju pirkstos, jo viņi zina, ka tas nāk, un, visbeidzot, jūs zināt, ECC darbosies HANA, un tāpēc jums patiešām vajadzētu būt tam sagatavotam un jāsaprot tehnoloģija.
Tātad, viena datu bāze, nav ETL procesu, nav kopiju, kas jāsaskaņo. Tātad, atkal, ātrāk, labāk un lētāk. HANA ir atmiņā. SAP piegādā programmatūru, jūs piegādājat aparatūru. Kopējo tabulu nav. Viena no lietām, ko viņi, domājot par to, liek domāt, ka nevēlaties tajā iekļūt, mēs vienkārši iegādāsimies lielāko pieejamo serveri. Viņi iesaka jums, sava veida, pareizajā SAP ainavā pirms laika, un viņi būtībā saka, ka neemigrējiet 20 gadu datus. Es domāju, ka arhivēšana ir kaut kas pārāk maz izmantots IT, visumā, ne tikai SAP veikalos. Tāpēc nākamā lieta ir tāda, ka SAP ir daudz laika pavadījis, pārrakstot vietējo kodu, lai neizmantotu SELECT *. SELECT * atgriež visas tabulas kolonnas, un tas ir īpaši dārgi kolonnveida datu bāzē. Tātad SAP HANA tā nav laba ideja. Tātad veikaliem, kuriem ir daudz pielāgošanas, daudz pārskatu, tas ir kaut kas, ko jūs vēlēsities meklēt, un jūs gatavojaties norādīt sleju nosaukumus, pārejot uz visu HANA.
Mums patīk teikt, ka HANA nav panaceja. Tāpat kā visas datu bāzes un visas tehnoloģijas, tā ir jāuzrauga, un, kā minēts iepriekš, jums ir nepieciešami skaitļi, lai pārvaldītu lieko, mērīšana pēc mērīšanas. Un viena no lietām, par ko es runāju IDERA jomā, ir tā, ka katrs biznesa darījums mijiedarbojas ar ierakstu sistēmu, un šajā gadījumā tas būs HANA. Un tā, HANA kļūst par jūsu SAP darījumu izpildes galalietotāju pieredzi. Tāpēc ir svarīgi, lai tas darbotos maksimālā ātrumā. Tas patiešām kļūst par vienu neveiksmes punktu, un, runājot ar ļaudīm, tas ir kaut kas, kas var parādīties tur, kur ir gala lietotājs, un, iespējams, izmanto šos reāllaika datus, un viņiem ir īpašs vaicājums, kas potenciāli nav gluži taisnība. Varbūt viņi nepievienojas galdiem un ir izveidojuši ārēju pievienošanos, partizānu produktu, un viņi būtībā patērē daudz resursu. Tagad HANA to galu galā atzīs un nogalinās šo sesiju. Un tā ir izšķirošā mūsu arhitektūras daļa, kas ļaus jums to reāli iemūžināt vēsturē, lai jūs varētu redzēt, kas bija noticis pagātnē, un atpazīt šīs situācijas.
Tātad, apskatīsim SAP HANA darba slodzes analīzi. Šī ir 1. versija, tāpēc mēs ļoti aicinām jūs pievienoties mums ceļojumā, un tas ir IDERA produkts. Tas ir visaptverošs, taču vienkāršs. Reāllaikā ar tendencēm. Saimnieka veselība, piemēram, veselība. Mēs izsekojam gaidīšanas stāvokļus, SQL vaicājumus, atmiņas patērētājus un pakalpojumus. Tātad, tas izskatās GUI, un jūs uzreiz varat redzēt, ka ir iespējots tīmeklis. Es faktiski atvēru šo risinājumu, kas darbojas tiešsaistē manā sistēmā. Ir dažas svarīgas lietas, kuras vēlaties apskatīt. Mēs, veida veida, esam sadalīti dažādās darbvietās. Vissvarīgākais ir tas, kas notiek resursdatora līmenī, sākot no CPU un atmiņas izmantošanas. Jūs noteikti nevēlaties nonākt pie maiņas vai zagšanas viedokļa. Un tad jūs galvenokārt strādājat pie tendencēm, sākot no reakcijas laika, lietotājiem, SQL paziņojumiem, tas ir, kas vada darbību sistēmā.
Viena no lietām, kas saistītas ar IDERA, ir tāda, ka, jūs zināt, datu bāzē nekas nenotiek, kamēr tajā nav aktivitātes. Un šī darbība ir SQL paziņojumi, kas nāk no lietojumprogrammas. Tātad, lai varētu noteikt galveno cēloni, SQL paziņojumu izmērīšana ir absolūti nepieciešama. Tātad, iesim un iedziļināsimies resursdatorā. Tātad resursdatora līmenī mēs faktiski varam apskatīt atmiņu, izsekot laika gaitā, izmantot resursdatora centrālo procesoru. Atkāpieties atpakaļ, un jūs varat apskatīt COBSQL paziņojumus. Tagad viena no lietām, ko jūs redzēsit mūsu arhitektūras pusē, ir, ka šī informācija tiek glabāta ārpus HANA, tāpēc, ja kaut kas notiktu ar HANA, mēs galvenokārt uztveram informāciju līdz situācijai, kurai nedod Dievs, nepieejamības. . Mēs arī varam tvert visu, kas notiek sistēmā, lai jums būtu skaidra redzamība. Un viena no lietām, ko mēs darīsim, ir tas, ka mēs SQL paziņojumus iesniegsim svērtā secībā. Tātad, tiek ņemts vērā izpildījumu skaits, un tas ir kopējais resursu patēriņš.
Un šeit jūs varat iekļūt atsevišķos metrikos - kad tas SQL izpildīja? Resursu patēriņu lielā mērā nosaka izpildes plāns, un tāpēc mēs to varam fiksēt pastāvīgi. HANA ir atmiņā. Tas ir ļoti paralēli. Tam katrā tabulā ir primārie indeksi, kurus daži veikali izvēlas izveidot sekundāro indeksu, lai risinātu noteiktas veiktspējas problēmas. Un tāpēc, piemēram, zināt, kas notika ar noteiktu SQL paziņojumu izpildes plānu, var būt ļoti vērtīgi. Mēs arī vēlreiz apskatīsim pakalpojumus, atmiņas patēriņu, laika grafiku. Arhitektūra: tātad, tas ir patstāvīgs risinājums, kuru varat lejupielādēt no mūsu vietnes, un arhitektūra ir tāda, ka tā ir iespējota tīmeklim.
Jums var būt vairāki lietotāji, kas izveido savienojumu ar noteiktu gadījumu. Jūs varat uzraudzīt vietējos SAP HANA gadījumus. Un mēs glabājam četras nedēļas mainīgo vēsturi savā krātuvē, un to var pārvaldīt paši. To izvietot ir diezgan vienkārši. Jums nepieciešams Windows Server. Jums tas ir jālejuplādē. Lielākajai daļai Windows serveru būs iebūvēts .NET ietvars, un tam ir pievienota licence. Tātad jūs dotos uz instalēšanas vedni, kuru virza Setup.exe, un tas faktiski atvērtu ekrānu, licences līgumu, un jūs vienkārši samazinātu šo kontūru, noklikšķinot uz Tālāk. Un tā, kur jūs vēlaties, lai HANA jāinstalē? Nākamais ir datu bāzes rekvizīti, un tas būs jūsu savienojums ar SAP HANA, tāpēc šī ir HANA instances bezatbildīga uzraudzība. Un tad mēs pamatā sniegsim priekšskatījumu, tas ir ports, kurā mēs pēc noklusējuma sazināmies. Noklikšķiniet uz Install (Instalēt), un tas būtībā palaiž HANA un jūs sākat veidot vēsturi. Tātad, tikai nedaudz par izmēru diagrammas informāciju. Mēs varam novērot līdz pat 45 HANA gadījumiem, un jūs to vēlēsities izmantot bīdāmā mērogā, lai noteiktu vajadzīgo kodolu skaitu, atmiņu un diska vietu. Un tas nozīmē, ka jums ir pilnīga četru nedēļu ritošā vēsture.
Tātad, tāpat kā ātrs atkārtojums, mēs aplūkojam servera veselību, instanču veselību, CPU / atmiņas izmantošanu. Kas ir atmiņas patērētāji, kādi ir darbības virzītāji, kādi ir pakalpojumi? SQL paziņojumi ir ļoti svarīgi - kādi ir izpildes stāvokļi? Parādiet man izpildes plānus, kad lietas tika izpildītas, nodrošinot tendences? Tas jums parādīs reāllaiku un notikušā vēsturi. Un kā jau minēju, tā kā mūsu vēsture ir nošķirta no HANA, mēs tverēsim lietas, kurām bija beidzies laiks un kuras tika izlaistas no HANA vēstures. Lai atsevišķās vēstures dēļ jūs varētu redzēt patieso resursu patēriņu savā sistēmā.
Tātad, kā jau minēju, IDERA vietnes sadaļā Produkti varat to viegli atrast. Ja vēlaties to izmēģināt, noteikti esat laipni gaidīts. Uzziniet, kā tas sniedz jums informāciju, un šajā vietnē ir papildu informācija. Tātad visas ieinteresētās puses ir priecīgas par to iedziļināties. Tagad IDERA piedāvātajos portfeļa produktos ir arī SAP ECC transakciju monitors, un to sauc par SAP precīzu. Un kas tas ir - neatkarīgi no tā, vai izmantojat portālu vai tikai tiešu ECC - tas faktiski fiksēs gala lietotāja darījumu no klikšķa uz disku līdz pat SQL paziņojumam un parādīs, kas notiek.
Tagad es jums parādīšu tikai vienu kopsavilkuma ekrānu. No šī kopsavilkuma ekrāna es gribētu, lai jums būtu pāris takeamers. Tas ir Y ass reakcijas laiks, X ass laiks plus diena, un šajā transakcijas skatā mēs parādīsim klienta laiku, rindas laiku, ABAP koda laiku, datu bāzes laiku. Mēs varam uztvert gala lietotāju ID, T-kodus, un jūs faktiski varat filtrēt un parādīt serverus, izmantojot noteiktu transakciju. Un tā, daudzi veikali vada ainavas priekšējo daļu zem VMware, lai jūs faktiski varētu izmērīt, kas notiek katrā serverī, un nokļūt ļoti detalizētā analīzē. Tātad, šis darījuma skats ir paredzēts gala lietotāja darījumam visā SAP ainavā. Jūs to varat atrast mūsu vietnes sadaļā Produkti APM rīki, un tas būtu mūsu piedāvātais SAP risinājums. Instalēšana tam ir nedaudz sarežģītāka, tāpēc to ne tikai lejupielādējiet un izmēģiniet, kā tas ir HANA gadījumā. Tas ir kaut kas tāds, kurā mēs kopīgi strādātu, lai izveidotu, izstrādātu un ieviestu kopējo darījumu jūsu labā.
Tātad, tikai trešā ātras atkārtošanās, SAP HANA darba slodzes analīze ir visaptveroša, bez aģentiem un reāllaikā, tā piedāvā vēsturi. Mēs piedāvājam iespēju lejupielādēt un izmēģināt to jūsu vietnei.
Līdz ar to es atdošu laiku Ērikam, Dezam un Dr Blooram.
Ēriks Kavaņahs: Jā, varbūt Robinam, kādi jautājumi no jums, un pēc tam Dezam pēc Robina?
Dr Robin Bloor: Labi. Es domāju, ka pirmais, ko es gribētu pateikt, ir tas, ka man ļoti patīk darījuma uzskats, jo tas ir tieši tas, ko es šajā situācijā gribētu. Es paveicu daudz darba - labi, tas ir sen, tieši tagad - veicu veiktspējas uzraudzību, un tas bija šāda veida lieta; tajos laikos mums nebija grafikas, bet tieši to es gribēju, lai varētu. Lai jūs varētu vienā vai otrā veidā iepludināt sevi visur, kur rodas problēma.
Pirmais jautājums, kas man ir, ir, jūs zināt, vairums cilvēku kaut kādā veidā ievieš S / 4 ārpus kārtas, jūs zināt. Kad jūs iesaistījāties kādā no S / 4 ieviešanām, vai jūs atklājāt, ka tā ir labi ieviesta, vai jūs galu galā zināt, vai esat atklājis lietas, kas klientam varētu radīt vēlmi pārkonfigurēt? Es domāju, kā tas viss notiek?
Bils Elliss: Nu, katrs veikals ir mazliet atšķirīgs. Un tur ir dažādi lietošanas veidi, ir dažādi pārskati. Vietnēm, kurām ir īpašs pārskats, es domāju, ka tas faktiski ir tāds pats kā sistēmas aizstājējzīme. Tātad, viena no izšķirošajām lietām ir sākt mērīšanu un noskaidrot, kāds ir pamatstāvoklis, kas ir normāli konkrētai vietnei, kur ir šī konkrētā vietne, pamatojoties uz to lietošanas paradumiem, uzsverot sistēmu. Un pēc tam veiciet korekcijas no turienes. Parasti monitoringa optimizēšana nav vienreizēja, tā patiešām ir pastāvīga prakse, kurā jūs uzraugāt, noskaņojat, uzlabojat sistēmu, padarot sistēmu labāku gala lietotāju kopienai, lai tā varētu efektīvāk apkalpot biznesu.
Dr Robin Bloor: Labi, tāpēc, kad jūs ieviešat - es domāju, es zinu, ka uz šo jautājumu ir grūti atbildēt, jo tas mainīsies atkarībā no ieviešanas lieluma - bet cik daudz resursa IDERA uzraudzības iespējas nodrošina, cik tas patērē ? Vai tas kaut ko izmaina vai ir, vai tas tikai netraucē? Kā tas darbojas?
Bils Elliss: Jā, es teiktu, ka pieskaitāmās izmaksas ir aptuveni 1–3 procenti. Daudzi veikali ļoti vēlas to upurēt, jo, iespējams, jūs to varēsit iegādāties optimizācijas ziņā. Tas patiešām ir atkarīgs no lietošanas veidiem. Ja jūs veidojat pilnu ainavu, tas ir atkarīgs no individuālajām pārraudzītajām tehnoloģijām. Tātad nobraukums dažāda, bet, kā mēs runājām, noteikti ir labāk mazliet veltīt laiku, lai zinātu, kas notiek, nekā vienkārši vadīt aklā. Īpaši tas būtu, jūs zināt, šeit, janvārī, mēs atrodamies gadu apstrādes procesā un apkopojat 12 mēnešu datus. Jūs zināt, ka tas ir veiktspēja, ziņojumu saņemšana pārvaldes organizācijām, bankām un akcionāriem ir ārkārtīgi svarīga kritiskā biznesa sniegumā.
Dr Robin Bloor: Pareizi. Un tikai no jūsu viedokļa - ātri, jo domāju, ka jūs esat iesaistīts veselā virknē SAP vietņu - cik liela ir SAP klientu loka kustība virzienā uz S / 4? Es domāju, vai kaut kas notiek, jūs zināt, ka tur notiek sava veida entuziasma pilni lavīnas, vai tas ir tikai vienmērīgs triks? Kā jūs to redzat?
Bils Elliss: Es domāju, ka pirms pāris gadiem es teiktu, ka tas bija purngals. Tagad es teiktu, ka cilvēki ir līdz savam ceļam. Es domāju, ka, jūs zināt, ņemot vērā laika grafiku, kuru cilvēki nākamajos pāris gados patiešām iegremdēs HANA. Tātad uzraudzība, pārveidošana, jūs zināt, es domāju, ka lielākā daļa klientu ir kopā ar mācīšanās līkni. Un tāpēc es domāju, ka mēs neesam tikuši pie lavīnas, kā jūs teicāt, bet es domāju, ka mēs esam uz lielās pārveides uz HANA virsotnes.
Dr Robin Bloor: Labi, ka, ņemot vērā vietnes, kuras jūs esat redzējis un kuras jau ir izmantojušās, vai tās arī pielāgo HANA citām lietojumprogrammām, vai arī tās tādā vai citā veidā ir pilnībā patērētas, lai izveidotu šo sīkumi strādā? Kāds tur attēls?
Bils Elliss: Jā, nereti cilvēki integrēs SAP ar citām sistēmām, atkarībā no moduļiem un tā tālāk, tāpēc ir mazliet. Es pagaidām neredzu cilvēkus, kuri HANA izvieto citas programmas. To noteikti ir iespējams izdarīt. Tātad tas vairāk attiecas uz ainavu ap SAP infrastruktūru.
Dr Robin Bloor: Es domāju, ka es jūs labāk nodotu Dezam. Esmu ķēries pie jūsu laika. Dez?
Dez Blanchfield: Paldies. Nē, tas viss ir labi. Divas ļoti ātras, tikai lai mēģinātu iestatīt tēmu. SAP HANA darbojas jau pāris gadus, un cilvēkiem ir bijusi iespēja to apsvērt. Ja jūs mums pateiktu aptuvenu to cilvēku procentuālo daļu, kuri to pārvalda, - jo šo lietu pārvalda daudz cilvēku, kāds, jūsuprāt, kāds ir jūsu tirgus procentuālais daudzums, par kuru jūs esat informēts, šobrīd ir pagājis sākot no tradicionālajām SAP ieviešanām līdz SAP HANA? Vai mēs skatāmies uz 50/50, 30/70? Kādu procentuālo tirgus daļu jūs redzat no cilvēkiem, kuri ir mainījušies un ir pārcēlušies tagad, salīdzinot ar ļaudīm, kuri tikai kavējas un gaida, kamēr lietas uzlabosies vai uzlabosies, vai mainīsies, lai arī kāds būtu gadījums?
Bils Elliss: Jā, es, no mana viedokļa raugoties, es liktu procentus ap 20 procentiem. SAP mēdz būt tradicionāls bizness. Cilvēki mēdz būt ļoti konservatīvi, un tāpēc viņu tauta vilksies kājās. Es domāju, ka tas ir atkarīgs arī no tā, vai, jūs zināt, vai jūs jau ilgu laiku vadāt SAP, vai arī jūs esat tāds SMB, kurš varbūt nesen bija izmantojis SAP? Un tā, tur ir sava veida virkne faktoru, bet kopumā es nedomāju, ka procenti ir 50/50. Es teiktu, ka 50 procenti vismaz sabojājas un HANA darbojas kaut kur viņu datu centrā.
Dezs Blanšfīlds: Interesants aizvedums, ko jūs mums iepriekš piešķīrāt, bija tas, ka tas savā ziņā ir faktisks sasniegums un pulkstenis fiziski un burtiski norāda laiku uz pāreju. Vai, jūsuprāt, cilvēki to ir izdarījuši? Kāda ir tautas izpratne par to, ka šī ir pāreja uz platformu, tā nav tikai iespēja, tā kļūst par noklusējuma opciju?
Un no SAP viedokļa es esmu pārliecināts, ka viņi to virzās, jo sniegumā ir ievērojamas konkurences priekšrocības, taču, es domāju, ka viņi arī cīnās ar platformas kontroli, nevis nonāk uz trešo, partiju datu bāzi, viņi tagad to atgriež savā platformā. Vai jūs domājat, ka uzņēmumi tiešām ir saņēmuši šo ziņojumu? Vai jūs domājat, ka cilvēki to saprot un tagad to izmanto? Vai arī tā joprojām ir kaut kāda neskaidra lieta, jūsuprāt, tirgū?
Bils Elliss: Es nedomāju, ka SAP kautrējas sazināties un cilvēki, kuri ir devušies uz SAPPHIRE, visur ir redzējuši HANA. Tāpēc es domāju, ka cilvēki labi apzinās, bet cilvēka daba ir tāda, kāda tā ir, jūs zināt, daži cilvēki ir tādi, kas mazliet velk kājās.
Dezs Blanšfīlds: Tā kā es domāju, ka iemesls, kāpēc es uzdevu šo jautājumu, un jums būs man jāpiedod, bet tas ir tas, ka es tam piekrītu. Es domāju, ka viņi nav kautrējušies par to paziņot. Es domāju, ka signāls daudzējādā ziņā ir izdzisis. Un es jums piekrītu - es nezinu, ka visi vēl ir uzlēkuši. Jūs zināt, ka tradicionālie uzņēmumi, ļoti lieli uzņēmumi, kas to vada, joprojām daudzējādā ziņā ne tikai nevelk kājas, bet tikai mēģina tikt galā ar maiņas sarežģītību. Tā kā es domāju, ka ir izcēlusies viena lieta, ko jūsu rīks, un, protams, jūsu demonstrācija šodien, un, manuprāt, viens no galvenajiem ņemšanas gadījumiem es gribētu, lai visi, kas šodien klausās un noregulē, sēdētu un pievērstos uzmanībai, ir: rīks, kas, manuprāt, šo procesu ir vienkāršojis. Es domāju, ka zem viņiem ir ļoti daudz nervozu CIO un viņu komandu, kas domā: “Kā es varu pāriet no tradicionālajām RDBMS, relāciju datu bāzu pārvaldības sistēmām, kuras mēs zinām gadu desmitiem ilgi, uz pilnīgi jaunu aprēķināšanas un krātuves pārvaldība telpā, kas joprojām ir samērā drosmīga? ”, manuprāt. Bet tas ir daudzējādā ziņā nezināms, un ir ļoti maz cilvēku, kas ir izdarījuši šo maiņu citās jomās, ka tas nav tā, it kā viņi būtu ieguvuši citu biznesa sadaļu, kas jau ir pārcēlusies uz atmiņas atmiņā aprēķināšanu. Tātad, tas ir pilnīgi vai nekas, kas viņu prātā virzās.
Tātad, viena no lietām, ko es no tā visa esmu atņēmusi vairāk nekā jebkas, un es minūtes laikā uzdošu jums jautājumu, ir tā, ka tagad, manuprāt, bailes ir daudzējādā ziņā mazinātas, un ka pirms šodienas, ja es klausītos CIO, es kaut kā domātu: “Nu, kā es izdarīšu šo pāreju? Kā es garantēšu tādu pašu spēju, kāda mums ir relāciju datu bāzes pārvaldības platformā, un gadu pieredzi DBAs, uz jaunu platformu, kurā mums šobrīd nav iemaņu? ”Tātad, mans jautājums ar to ir šāds:, vai jūs domājat, ka cilvēki ir sapratuši, ka rīki ir tagad ar to, ko jūs piedāvājat, un ka viņi, iespējams, var dziļi elpot un atviegloti nopūsties, ka pāreja nav tik biedējoša, kā tas varētu būt bijis iepriekš vai šis rīks ir pieejams? Vai jūs domājat, ka cilvēki ir sapratuši vai tā joprojām ir tāda veida lieta, ka viņi vienkārši cīnās ar pāreju uz atmiņā esošiem aprēķiniem un atmiņas saglabāšanu, salīdzinot ar vecās skolas NVMe, zibatmiņas un diska kombinācijām?
Bils Elliss: Jā, tāpēc, bez šaubām, ir daudz tehnoloģiju un rīku, kas grafiski var parādīt notiekošo un ļauj ļoti viegli noteikt top resursu patērētājus. Es domāju, ka tas palīdz vienkāršot lietas, un tas palīdz tehnoloģiju darbiniekiem patiešām iegūt labu rokturi. Hei, viņi varēs uzzināt, kas notiek, un spēt saprast visu sarežģītību. Tātad tirgū pieejamie rīki noteikti ir noderīgi, tāpēc mēs piedāvājam SAP HANA darba slodzes analīzi.
Dezs Blanšfīlds: Jā, es domāju, ka lieliskā lieta, ko jūs šodien parādījāt, ir tā, ka, pārraugot aparatūras daļu, operētājsistēmas daļu, pat novērojot, kā daļa no darba slodzes pārvietojas cauri, kā jūs teicāt, es domāju, rīkiem kādu laiku tur bijuši. Man mazliet, it īpaši HANA patīk, ir tas, ka mums nav obligāti bijusi iespēja iegūt palielināmo stiklu un palūrēt tajā un redzēt, ko jūsu rīks dara ar to, kas notiek ar jautājumiem un kā viņi ir strukturēts un kur šī slodze ir.
Izmantojot līdz šim redzētos izvietojumus, ņemot vērā to, ka jūs savā burtiski burtiski esat visautoritatīvākais šajā vietā savā platformā pasaulē, daži no ātrajiem uzvariem, ko esat redzējis, - vai jums ir kādas anekdotiskas zināšanas, ar kurām varat dalīties? mums apkārt daži no eureka mirkļiem, aha mirkļi, kad cilvēki ir izvietojuši IDERA rīku kopu, viņi ir atraduši lietas, kuras viņi vienkārši nebija zinājuši, savās platformās un izrādēs. Vai jums ir kādi lieliski anekdotiski piemēri par to, kur cilvēki to tikko ir izvietojuši, īsti nezinādami, kas viņiem ir bijis, un pēkšņi aizgājuši: “Oho, mēs patiesībā nezinājām, ka tur atrodas?”
Bils Elliss: Jā, vietējiem rīkiem liels ierobežojums ir tāds, ka, ja bēguļojošais vaicājums tiek atcelts, tas izspiež informāciju un tāpēc jums principā nav vēstures. Ja mēs vēstures datus glabāsim bezsaistē, piemēram, aizbēgušu vaicājumu, jums būs vēsture, jūs zināt, kas noticis, jūs varēsit redzēt izpildes plānu un tā tālāk. Un tas ļauj jums sava veida palīdzēt galalietotāju kopienai labāk darboties, labāk rakstīt ziņojumus, utt. Un tā, vēsture ir kaut kas patiešām jauks. Un viena no lietām, ko man bija iecerēts parādīt, ir tas, ka jūs varat skatīties reālajā laikā līdz četrām nedēļām, un pēc tam jūs varat viegli pietuvināt jebkuru interesējošu laika grafiku, un tad jūs varat atklāt braukšanas pamatmērķus. Tikai šīs redzamības nodrošināšana ir ļoti noderīga, lai zinātu, kas ir izveidojies.
Dezs Blanšfīlds: Jūs pieminējāt, ka tas ir daudzlietotāju, tiklīdz tas ir ieviests, un mani diezgan pārsteidza fakts, ka tas ir bez aģenta un daudzējādā ziņā faktiski ir bez pieskāriena. Vai ir normāli, ja viena rīka izvietošana pēc tam ir pieejama ikvienam no tīkla operāciju centra NOC, kas visā klasē esošās pamatinfrastruktūras skatās līdz pat lietojumprogrammu un izstrādes komandai? Vai tā ir norma, un jūs vienreiz to izvietojat, un viņi to dalīs, vai arī jūs domājat, ka cilvēkiem varētu būt paraugi, kas aplūko dažādas kaudzes daļas? Kā tas izskatās?
Bils Elliss: Tātad bāzes komandai parasti būs ļoti liela interese par tehnoloģijām, kas balstās uz SAP notiekošo. Acīmredzot ir vairākas komandas, kas atbalstīs visas ainavas. HANA gabals ir tikai koncentrēts uz to. Es tikai noklusēšu SAP bāzes komandu kā primāros informācijas patērētājus.
Dez Blanchfield: Pareizi. Tomēr mani pārsteidz tas, ka, ja man ir attīstības komanda vai pat ne tikai koda līmenī, bet gan, ja man ir datu zinātnieku vai analītiķu komanda, kas veic analītisko darbu ar tur esošajām datu kopām, īpaši ņemot vērā, ka tur ir ievērojams stimuls datu zinātnei, kas tagad, manuprāt, tiek piemērota visam organizāciju iekšienē - un labojiet mani, ja es kļūdos - man šķiet, ka tas viņus ļoti interesēs, jo daudzējādā ziņā viens Dažas no nopietnām lietām, kuras varat darīt datu noliktavas vidē, ir datu zinātnieka atbrīvošana no tā un ļauj tam tikai sākt veikt īpašus vaicājumus. Vai jums ir bijuši piemēri, ka šāda veida lietas notiek, ja veikali ir tevi uzrunājuši un teikuši: “Mēs esam metuši lietā datu zinātnes komandu, tas tiešām sāp, ko mēs varam viņu labā izdarīt, salīdzinot ar to, ko mēs vienkārši darām tradicionālā operatīvā uzraudzība un vadība? ”Vai tā ir kaut kas?
Bils Elliss: Jā, jā, es to mazliet pārvērtīšu un sagrieztu savu atbildi, ja, apskatot sniegumu, apzinoties sniegumu, izstrādājot kvalitātes nodrošināšanas ražošanu, jūs zināt, jo ātrāk jūs uzglabāt, jo mazāk problēmu, mazāk pārsteigumi jums ir. Tātad, absolūti.
Dezs Blanšfīlds: Pēc tam, izmantojot daudzus rīkus, ar kuriem man ir bijusi pieredze - un esmu pārliecināts, ka Robins tam piekritīs -, ir daudz šeit pieejamo rīku, ja jums ir liela RDBMS, jums ir nepieciešams patiešām augsts - kvalificēti, dziļi zināmi, pieredzējuši DBA. Dažas no infrastruktūras un platformas prasībām, kas saistītas ar SAP HANA, jo tas, cik man zināms, pašlaik tiek atbalstīts īpašos izplatījumos, kas pielāgojas noteiktai aparatūrai un tā tālāk. Jūs zināt, ka ir cilvēki ar gadu desmitu pieredzi, kas nav viens un tas pats. Tomēr es redzu, ka šī rīka prasība nav obligāta. Man šķiet, ka jūs varat izvietot savu rīku un dot to dažām diezgan jaunām sejām un uzreiz dot viņiem spēku atrast lietas, kuras nedarbojas labi. Vai ir tā, ka ir diezgan īsa mācīšanās līkne, lai to panāktu un gūtu kādu labumu no tās ieviešanas? Jūs zināt, mana vispārējā izpratne ir tāda, ka, lai nekavējoties redzētu vērtību, jums nav jābūt 20 gadu pieredzei darbinot instrumentu. Vai jūs piekrītat, ka tas tā ir?
Bils Elliss: Ak, absolūti, un, jūsuprāt, es domāju, ka liela daļa dislokācijas panākumu ir atkarīgi no SAP HANA vides plānošanas un arhitektūras. Un tad neapšaubāmi ir daudz sarežģītības, daudz tehnoloģiju, uz kuras tā ir veidota, bet tad atliek tikai pārraudzīt notiekošā lietošanas paradumus. Tātad, kaut arī tas ir sarežģītāks, savā ziņā tas ir iesaiņots un nedaudz vienkāršots. Tas ir ļoti slikti.
Dezs Blanšfīlds: Jā, tāpēc pirms es došos atpakaļ pie Ērika, jo es zinu, ka viņam ir pāris jautājumu, it īpaši no dažiem, kas nāk caur jautājumiem un atbildēm, kuri izskatījās interesanti, un es labprāt uzklausu atbildi. Tradicionāls ceļojums kādam - jūs jau iepriekš minējāt, ka varat to iegūt, varat lejupielādēt un izmēģināt. Vai jūs varat vienkārši ātri to atrunāt, lai klausītos mūsdienās vai arī tos, kuri to vēlāk varētu atkārtot? Kādas ir ātras divas vai trīs darbības, lai panāktu viņu kopēšanu un ieviešanu un izmēģināšanu savā vidē pirms pirkšanas? Kā tas izskatās? Kādi ir soļi?
Bils Eliss: Jā. Tātad, IDERA.com un vienkārši dodieties uz Produktiem un redzēsit SAP HANA darba slodzes analīzi. Ir lejupielādes lapa. Es domāju, ka viņi lūgs jums kādu kontaktinformāciju, un produkts ir vienkārši iesaiņots kopā ar licences atslēgu, lai jūs varētu to instalēt ar Setup.exe un, manuprāt, ļoti ātri sāktu darboties.
Dezs Blanšfīlds: Tātad, viņi var apmeklēt jūsu vietni un lejupielādēt. Es atceros, ka pirms kāda laika to apskatīju, un es arī vakar vakar pārbaudīju, vai jūs no atmiņas varat pieprasīt demonstrāciju, kur kāds no jūsu komandas locekļiem jums to izdarīs? Bet jūs faktiski to varat lejupielādēt bez maksas un izvietot lokāli savā vidē, savā laikā, vai ne?
Bils Elliss: Jā.
Dez Blanchfield: Teicami. Es domāju, ka vairāk nekā par kaut ko, iespējams, tā ir lieta, kuru es personīgi ieteiktu darīt tautai, ir paņemt kopiju no vietnes, paņemt daļu tur esošās dokumentācijas, jo es zinu, ka tur ir daudz laba satura, lai to izdarītu, un vienkārši izmēģiniet to. Ielieciet to savā vidē un redziet, ko atrodat. Man ir aizdomas, ka, tiklīdz jūs esat ielūkojies zem pārsega ar savu SAP HANA vidi, izmantojot IDERA rīku, jūs atradīsit tur lietas, kuras patiesībā nezināt.
Skatieties, liels paldies par to un paldies par laiku, par jautājumiem un atbildēm ar Robinu un I. Ēriku. Es jums atgriezīšos, jo es zinu, ka daži jautājumi un atbildes rodas arī no mūsu apmeklētājiem.
Ēriks Kavaņahs: Jā, šeit vienkārši īsts ātrs. Tātad, viens no dalībniekiem šeit sniedz patiešām labu komentāru, runājot tikai par to, kā lietas mainās. Iepriekš sakot, atmiņa bija aizrīšanās, palēninājās ar biežu peidžēšanu, pašlaik centrālais procesors aizrīkojas ar pārāk lielu atmiņā esošo datu daudzumu. Jūs zināt, ka pastāv tīkla problēmas. Tas vienmēr būs kustīgs mērķis, vai ne? Ko jūs redzat kā trajektoriju šajās dienās attiecībā uz to, kur būs vājās vietas un kur jums vajadzēs koncentrēt savu uzmanību?
Bils Eliss: Jā. Kamēr nemērīsit, to ir grūti zināt. Viena no lietām saistībā ar SQL apgalvojumiem ir tā, ka tās būs resursu patēriņa virzītājspēks. Un tādā gadījumā, ja jums vajadzēja, piemēram, lielu atmiņas vai CPU patēriņu, jūs varēsit izdomāt, kādas darbības izraisīja šo resursu patēriņu. Tagad jūs to noteikti nevēlaties nogalināt, bet arī vēlaties to apzināties un, piemēram, to, kas notiek, cik bieži tas notiek, utt. Mēs, sava veida, joprojām esam jauni, ņemot vērā visu komplektu vai pavārgrāmatu, kurā tiek sniegtas atbildes uz dažādiem apstākļiem. Tātad, tas ir lielisks jautājums, un laiks rādīs. Laika gaitā mums būs vairāk informācijas.
Ēriks Kavaņahs: Tas arī viss. Jūs, puiši, atrodaties ļoti interesantā telpā. Es domāju, ka nākamajos mēnešos un nākamajos pāris gados jūs redzēsit daudz aktivitāšu, jo es zinu, ka SAP, kā jūs ierosinājāt mūsu satura aicinājumā, ir nodrošinājis jauku ilgu uzbrauktuvi ļaudīm, lai veiktu pāreju uz HANA. Bet neskatoties uz to, šai rampai ir beigas un noteiktā brīdī cilvēkiem būs jāpieņem daži nopietni lēmumi, tāpēc, jo ātrāk, jo labāk, vai ne?
Bils Eliss: Absolūti.
Ēriks Kavanaghs: Labi, ļaudis, mēs vēl vienu stundu šeit esam nodedzinājuši vietnē Hot Technologies. Informāciju varat atrast tiešsaistē, insideanalysis.com, kā arī techopedia.com. Koncentrējieties uz šo vietni, lai iegūtu daudz interesantas informācijas, ieskaitot visu mūsu iepriekšējo tīmekļa pārraižu arhīvu sarakstu. Bet ļaudis, liels paldies jums visiem, kas jūs esat, mūsu draugiem IDERA, Robinam un, protams, Dez. Mēs ar jums sazināsimies nākamnedēļ, ļaudis. Paldies vēlreiz par jūsu veltīto laiku un uzmanību. Rūpēties. Labdien!
