Izņemšana: Saimnieks Ēriks Kavanaghs diskutē par atmiņu skaitļošanu un SAP HANA ar viesiem Dr. Robinu Blooru, Dezu Blanšfīldu un IDERA darbiniekiem 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 četrs Austrumu laiks un pēdējie pāris gadi, tas nozīmē, ka atkal ir laiks Hot Technologies. Jā, tiešām, mans vārds ir Ēriks Kavanaghs, es būšu jūsu šodienas sarunu saimnieks.
Un ļaudis, 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.
Pastāv vieta, kur patiesi redzat jūs, piesitiet mani @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 ī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. Uzņēmējdarbība ir tas, kas viņiem patiešām ir ļoti labs. 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 vieta, un mēs no cita pārdevēja, IDERA, uzzināsim mazliet par to, kā viss šie materiāli darbosies un, atklāti sakot, ir informācija 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 Robin Bloor: 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 iesaistījāmies 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 tā 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, daudz kas no tā, kas notiek nozarē, nāk no viena.
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 tiešām ir beidzies diska griešanās. 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 to pieminēt, iemesls, kāpēc es to īsti iemetu, tas bija tikai darīt visiem zināmu, kad es šeit runāju par atmiņu, visi šie slāņi, par kuriem es runāju, faktiski ir atmiņa. 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 tas tagad 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 ļoti daudz tehnoloģiju - labi, diezgan daudz tehnoloģiju -, kas ir pieņēmušas stratēģiju izmantot šos kešatmiņus kā sava veida krātuves vietu, lai izpildītu lietas, jo īpaši datu bāzes 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 gandrīz ir ātrums RAM, galvenokārt tas ir tas, ar ko lielīties abi šie pārdevēji. 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 šajā gadījumā ietekmēs operatīvās atmiņas izmantošanu un atmiņā esošās datu bāzes tehnoloģiju. 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ūsa, 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 ap to 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āsaņem 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 domā, 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 savas pamatlietas, jo ERP gandrīz vienmēr ir pamata lietojumprogrammas, kuras vada uzņēmumi, tā ir tikai milzīga spēļu mainītāja, un tā būs ļoti interesanta. 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 kam, 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āpēc 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 veselajiem slāņiem, ir vērpšanas disks. Tā kā atcerieties, ļoti agrīnajās skaitļošanas dienās, arhitektoniski, mēs ilgu laiku nevirzījāmies no lieldatoru vai vidējās vērtības pasaules, ko mēs sākotnēji domājām par galveno atmiņu un bungu krātuvi, 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ā nebija mainījusies kādu laiku, pāris desmitgažu laikā. 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ā tā 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 īsti 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 mums tas ir daudz sarežģītāk, 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 serdeņi ir kļuvuši par spēju CPU un ka mēs pārgājām no 32-bit uz 64-bit. 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 par vēl svarīgāku lietu, 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īgam attiecībā uz to, kurus mazos bitus jūs salīmējat, lai padarītu to cietu. 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ā mācīšos.”
Manuprāt, tā ir lieliska analoģija tam, kā patīk veidot šīs ļoti sarežģītās platformas, jo ir labi un labi to izveidot un beidzot ar vidi, kurā jums ir maršrutētāji un slēdži, serveri un statīvi. Un jums ir apkopoti 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ā pati par sevi ir sarežģīta kaudze, 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 šī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, ka reiz jūs bijāt iztērējis no 380 līdz 400 tūkstošiem dolāru uz cietā diska gigabaitu, 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 viena vai diviem centiem par preču diska vietas gigabaitu. 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 punktēta 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 izlaupīto preču aparatūru.
Š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 diskā. 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 periodu -, 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ājiem. 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ā, ka mūsu izveidotā sarežģītība rada risku daudzās jomās.
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 ar ļoti augsta blīvuma atmiņu, ļoti lielu CPU, serdeņu un diegu skaitu. Tagad, lai to atbalstītu, esam ieguvuši ļoti sarežģītas tīkla patoloģijas, jo datiem kaut kad ir jāpārvietojas pa visu tīklu, ja tie notiks starp mezgliem un klasteriem.
Tātad galu galā ierīču kļūmju dublēšana kļūst par problēmu, un mums ir jāuzrauga ierīces un to daļas. Mums šajā platformā ir iebūvēta elastīga datu kļūdu dublēšana, un tā jāuzrauga. Mums ir jābūt iebūvētai izkliedētās datu bāzes elastībai, tāpēc mums ir jāuzrauga datu bāzes platforma un jākontrolē tā. Mums ir jāuzrauga sadalītā apstrādes plānošana, tas, 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ā 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 cauri fona arhitektūrai? Mums ir daudznozaru darba slodzes, vairāki lietotāji un vairākas grupas, kuras darbojas vienā un tajā pašā vai vairākās darba slodzēs, kā arī 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āms nezināmais, jo mēs nezinām, kas, kad un kur darbojas, 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 tādu, 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 izpildījums mums pazūd no atmiņas? 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 ārpus 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ēšana 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 pieminē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 dzīvu 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ētu atmiņā, š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 mani noved pie tā, ka mēs kļūstam arvien sarežģītākas šajās sistēmās, un 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ā.
Un, ņemot to vērā, es nodošu mūsu draugam no IDERA un dzirdēšu, 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, kas 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 tā ir lēta, es tikai saku, ka tā ir lētāka. 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, tas ir lētāks, 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, ienirstot to 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, 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ē. Un tā, SAP HANA 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, norādot uz kolonnu nosaukumiem, 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 pa labi. 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.
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, tāds ir GUI izskats, un jūs uzreiz varat redzēt, ka tas ir iespējots tīmeklī. Es faktiski atvēru šo risinājumu, kas darbojas tiešraidē manā sistēmā. Ir dažas svarīgas lietas, kuras vēlaties apskatīt. Mēs esam sava veida 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 nokļūt viedokļu maiņas vai plaukstošās pozīcijās. Un tad jūs būtībā strādājat pie tā, kas notiek, mainot tendences, 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 nav notikusi kāda darbība. 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 resursdatoros. Tātad resursdatora līmenī mēs faktiski varam apskatīt atmiņu, izsekot laika gaitā un 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, tas ņems vērā izpildes skaitu, 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īmeklī.
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 mainīgo četru nedēļu 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 ne vairāk kā 45 HANA gadījumus, un jūs to vēlēsities izmantot slīdā mērogā, lai noteiktu nepieciešamo serdeņu, atmiņas un diska vietas. 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, gadījumu 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 atšķirīga no HANA, mēs gatavojamies tvert 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, jūs noteikti laipni gaidīsit. 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 transakciju 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. Es vēlos, lai jūs no šī kopsavilkuma ekrāna varētu ņemt dažas lietas. Tas ir Y ass reakcijas laiks, X ass laiks plus diena, un šajā transakcijas skatā mēs jums 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 izmanto ainavas priekšējo daļu zem VMware, lai jūs faktiski varētu izmērīt, kas notiek katrā serverī, un veikt ļoti detalizētu analīzi. 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 šim nolūkam 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 Kavanaghs: Jā, varbūt Robinam, kādi jautājumi no jums, un pēc tam Dez 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 skats, 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 tas ir labi ieviests, vai jūs galu galā zināt, vai esat atklājis lietas, kas varētu likt klientam vēlēties pārkonfigurēt? Es domāju, kā tas viss notiek?
Bils Elliss: Nu, katrs veikals ir mazliet savādāks. Ir atšķirīgi 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ā aizstājējzīme sistēmā. Un tāpēc 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 uzņēmējdarbību.
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 kaut ko atšķir, vai arī tas tikai kaut kā 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 potenciāli 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, taču, 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, kas veic sniegumu, ir atskaites saņemšana pārvaldes organizācijām, bankām un akcionāriem, ir ārkārtīgi svarīgi kritiskā biznesa izpildē.
Dr Robin Bloor: Pa labi. Un tikai no jūsu viedokļa - ātri, jo es domāju, ka jūs esat tur iesaistīts veselā virknē SAP vietņu - cik liela ir SAP klientu bāzes virzība uz S / 4? Es domāju, vai tas ir kaut kas tāds, kas notiek, jūs zināt, ka tajā 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ārveidošanas virsotnes HANA virsotnes.
Dr Robin Bloor: Labi, vai, ņemot vērā redzētās vietnes, kas to ir pametušas, vai tās arī pielāgo HANA citām lietojumprogrammām, vai arī tās tādā vai citādā veidā ir pilnībā patērētas, lai šie materiāli darbotos? Kāds tur ir attēls?
Bils Elliss: Jā, bieži 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 lieto citas lietojumprogrammas. 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. Es esmu pavadījis jūsu laiku. 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? Tātad ir daži faktori, bet kopumā es nedomāju, ka procentuālais daudzums ir 50/50. Es teiktu, ka 50 procenti vismaz sabojājas un HANA darbojas kaut kur viņu datu centrā.
Dez Blanchfield: Interesanti, ka jūs mums to veltījāt iepriekš, bija tas, ka tas savā ziņā ir faktisks sasniegums un ka 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 to patiešām ir ieguvuši? 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.
Dez Blanchfield: 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 informēt. Es domāju, ka signāls ir izdzisis daudzējādā ziņā. 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, rīks, kas, manuprāt, ir šo procesu 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 daudzos veidos nezināms, un ir ļoti maz cilvēku, kuri citās sfērās ir mainījušies, ka tas nav tā, it kā viņiem būtu vēl viena uzņēmējdarbības sadaļa, kas jau ir pārgājusi uz atmiņas atmiņā aprēķināšanu. Tas ir viņu prātā viss, jeb nekas.
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 līdz šodienai, 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 kombinācijām ar NVMe, zibatmiņu un disku?
Bils Elliss: Jā, tātad, bez šaubām, ir daudz tehnoloģiju un rīku, kas grafiski var parādīt to, kas notiek, un tas ļoti viegli ļauj noteikt labākos 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.
Dez Blanchfield: Jā, es domāju, ka lieliskā lieta, ko jūs mums šodien parādījāt, ir tā, ka, uzraugot aparatūras daļu, operētājsistēmas daļu, pat uzraugot, kā daļa no darba slodzes pārvietojas, kā jūs teicāt, es domāju, rīki ir bijuši tur kādu laiku. 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, 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ājam bezsaistē, piemēram, bēguļojošs vaicājums, jums būs vēsture, jūs zināt, kas ir noticis, jūs varēsit redzēt izpildes plānu utt. 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 ļoti patīkams. 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.
Dez Blanchfield: Jūs pieminējāt, ka tas ir daudzlietotāju, tiklīdz tas ir ieviests, un mani ļoti pārsteidza tas, ka tas ir bezspēcīgs un daudzējādā ziņā faktiski 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 pamata 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: Pa labi. 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 pagriezīš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 glabājat, jo mazāk problēmu, mazāk pārsteigumu jums ir . Tātad, absolūti.
Dez Blanchfield: Pēc tam, izmantojot daudzus rīkus, ar kuriem man ir bijusi pieredze - un esmu pārliecināts, ka Robins tam piekritīs -, daudz šeit pieejamo rīku, ja jums ir liela RDBMS, jums ir nepieciešams patiešām augsti kvalificēts, dziļi zinoši, pieredzējuši DBA. Dažas no infrastruktūras un platformas prasībām, kas saistītas ar SAP HANA, jo šobrīd tiek atbalstītas īpašos izplatījumos, kas, cik man zināms, pielāgojas no noteiktas aparatūras 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 tas nebūt nav obligāti jāizmanto šis rīks. 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, kas 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 jums nav jābūt 20 gadu pieredzei darbinot instrumentu, lai nekavējoties redzētu vērtību. 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 izvēršanas panākumu patiešām ir atkarīgi no SAP HANA vides plānošanas un arhitektūras. Un tad neapšaubāmi ir daudz sarežģītības, daudz izstrādātu tehnoloģiju, bet tad atliek tikai uzraudzī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.
Dez Blanchfield: Jā, tāpēc pirms es došos atpakaļ pie Ērika, jo es zinu, ka viņam ir pāris jautājumu, jo īpaši no dažiem jautājumiem, 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 Elliss: Jā. Tātad, IDERA.com un vienkārši dodieties uz Produkti, un jūs 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, izmantojot Setup.exe, un, domāju, ka tas notiek ļoti ātri.
Dez Blanchfield: Viņi var apmeklēt jūsu vietni un lejupielādēt to. 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 tiešām to varat lejupielādēt bez maksas un izvietot lokāli savā vidē, savā laikā, vai ne?
Bils Elliss: Jā.
Dez Blanchfield: Lieliski. 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 SAP HANA vidē ar IDERA rīka palīdzību, 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 Kavanaghs: Jā, vienkārši īsts ātrs šeit. 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 Elliss: 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 centrālā procesora patēriņu, varēsit saprast, kādas darbības izraisīja šo resursu patēriņu. Tagad jūs to ne vienmēr gribētu 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 Kavanaghs: Tieši tā. 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 Elliss: Pilnīgi.
Ēriks Kavanaghs: Labi, ļaudis, mēs esam karsējuši vēl vienu stundu šeit, izmantojot 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 sazināsimies ar jums nākamnedēļ, ļaudis. Paldies vēlreiz par jūsu veltīto laiku un uzmanību. Rūpēties. Labdien!