Izņemšana: Saimnieks Ēriks Kavanagh apspriež prognozēšanu ar Dr. Robinu Blooru, Riku Šermanu un IDERA Bullett Manale.
Lai apskatītu video, jums jāreģistrējas šim notikumam. Reģistrējieties, lai redzētu video.
Ēriks Kavanaghs: Dāmas un kungi, sveiciens vēlreiz un laipni gaidīti Hot Technologies tīmekļa apraides sērijā! Mans vārds ir Ēriks Kavanaghs. Es esmu jūsu šodienas tīmekļa semināra, kura nosaukums ir “Ietaupiet laiku, naudu un nepatikšanas, izmantojot optimālas prognozes”, kursa vadītājs. ”Kursa laikā es nokavēju nosaukuma pirmo daļu“ Labākie nolīgtie plāni ”. Mēs vienmēr runājam par to šajā izrādē. Protams, Hot Technologies, protams, ir mūsu forums, lai saprastu, kādi daži izcili produkti ir šodien mūsdienu pasaulē, uzņēmumu tehnoloģiju pasaulē, ko ļaudis dara ar viņiem, kā viņi strādā, un tas viss, kas ir jautri.
Un šī tēma šodien, kā es iesaku, nodarbojas ar prognozēšanu. Patiešām jūs mēģināt saprast, kas notiks jūsu organizācijā. Kā jūs gūsit prieku saviem lietotājiem neatkarīgi no tā, ko viņi dara? Ja viņi veic analīzi, ja viņi veic reālu darbu, viņi saskaras ar reāliem klientiem ar darījumu sistēmām neatkarīgi no gadījuma, jūs vēlaties saprast, kā darbojas jūsu sistēmas un kas notiek, un tas ir tas, par ko šodien labi runā. Tas ir smieklīgi, jo prognozēšana nav tas, kas man patīk darīt, rada māņticību, piemēram, es domāju, ka, ja es pārāk daudz prognozēju, notiks sliktas lietas, bet tas ir tikai man. Neseko manai vadībai.
Tātad, šeit ir mūsu šodienas vadītāji, patiesi cieņā augšējā kreisajā stūrī. Riks Šermens zvana no Bostonas, mūsu draugs Bullett Manale no IDERA un mūsu pašu Dr. Robins Bloors. Un līdz ar to es to nododu Robinam un atgādinu tikai cilvēkiem: uzdodiet jautājumus, nekautrējieties, mēs mīlam labus jautājumus, labi izlieciet tos šodien mūsu vadītājiem un citiem. Un ar to, Robin, atņem to.
Robins Bloors: Labi, labi, tā kā esmu nekustīgā situācijā, kā viņi saka, es domāju, ka šodien pastāstīšu SQL stāstu, jo tā fons ir tas, par ko notiks diskusija, un tas neizbēgami nesaskarsies, jo Riks nekoncentrējas uz šo , un nebūs pretrunā ar to, kas jāsaka Rikam. Tātad, SQL stāsts, ir dažas interesantas lietas par SQL, jo tā ir tik dominējošā. Redziet, tas ir kļūdaini, SQL ir deklaratīva valoda. Ideja bija tāda, ka jūs varētu izveidot valodu, kurā jūs pieprasītu to, ko vēlaties. Un datu bāze izstrādātu, kā to iegūt. Un faktiski tas ir izstrādāts diezgan labi, taču ir vairākas lietas, par kurām ir vērts teikt, tas ir sekas, ja visa IT nozare balstās uz deklaratīvu valodu. Lietotājs nezina un nerūpējas par datu fizisko organizāciju, un tas ir ļoti noderīgi deklaratīvajā valodā - tas jūs atšķir no visa tā, un pat uztraucoties par to - vienkārši jautājiet, ko vien vēlaties, un datu bāze ies un dabūšu.
Bet lietotājam nav ne jausmas, vai tas, kā viņi strukturē SQL vaicājumu, ietekmēs vaicājuma veiktspēju, un tas ir mazliet negatīvs. Esmu redzējis simtiem un simtiem rindu garu vaicājumu, kas, kā jūs zināt, ir tikai viens SQL pieprasījums, sākas ar “atlasīt” un vienkārši turpinās un turpinās ar apakšjautājumiem un tā tālāk un tā tālāk. Un patiesībā izrādās, ka, ja vēlaties, lai konkrēta datu kolekcija būtu ārpus datu bāzes, jūs to varat lūgt daudzos dažādos veidos, izmantojot SQL, un saņemt tādu pašu atbildi, ja jums ir zināmi zināmi dati. Tātad viens SQL vaicājums nebūt nav labākais veids, kā pieprasīt datus, un datu bāzes reaģēs diezgan atšķirīgi atkarībā no SQL, ko jūs tajās ievietojāt.
Un tā, SQL faktiski ietekmē veiktspēju, tāpēc cilvēki, kas izmanto SQL, ir taisnība par viņiem, tas pats attiecas arī uz SQL programmētājiem, kuri izmanto SQL, un vēl jo mazāk domā, ka viņi domā par ietekmi, kāda viņiem būs, jo lielākā daļa viņu koncentrējas faktiski ir saistīts ar manipulācijām ar datiem, nevis ar datu iegūšanu, ievietošanu. Tas pats attiecas arī uz BI rīkiem, es esmu redzējis SQL, kas, ja vēlaties, izspiež no dažādu datu bāzu BI rīkiem, un jāsaka, ka daudz kas tas ir, labi, es nerakstītu SQL vaicājumus tāpat. Tas kāds ir izveidojis, ja vēlaties, nelielu motoru, ka neatkarīgi no tā, kādi parametri ir, tas izmetīs nedaudz SQL un atkal, ka SQL ne vienmēr būs efektīvs SQL.
Tad es domāju, ka pieminēšu pretestības neatbilstību, dati, kurus programmētāji izmanto, ir atšķirīgi no datiem, jo tie šķiro. Tātad, mūsu DMS datus glabā tabulās, organizētais objektorientētais kods lielākoties ir kodētāji, mūsdienās programmē objektorientētu formu un pasūta datus objekta struktūrās, tātad tas savstarpēji nesalīdzina. Tātad, ir nepieciešams tulkot no tā, ko programmētājs domā, ka dati ir līdz tam, ko datu bāze domā, kādi ir dati. Liekas, ka mums vajadzēja kaut ko izdarīt nepareizi, lai tā būtu. SQL ir DDL datu definēšanai, tam ir DML - datu manipulācijas valoda - atlasiet, projektējiet un pievienojieties, lai iegūtu šos datus. Tagad ir ļoti maz matemātikas un ļoti maz laika balstītu lietu, tāpēc tā ir nepilnīga valoda, lai gan jāsaka, ka tā ir paplašināta un turpina paplašināties.
Un tad jums rodas SQL barjeras problēma, kas vienmēr ir skaidrāka nekā diagrammā, bet daudzi cilvēki uzdeva jautājumus analītisku apsvērumu dēļ, tiklīdz viņi ir ieguvuši atbildi uz jautājumu datu noteikumiem, vēlas uzdot citu jautājumu. Tātad, tas kļūst par dialoga lietu, labi, SQL nebija izveidots dialogiem, tas tika izveidots, lai pajautātu, ko vēlaties uzreiz. Un to ir vērts zināt, jo ir daži produkti, kas faktiski pamet SQL, lai padarītu iespējamu sarunu starp lietotāju un datiem.
Runājot par datu bāzes veiktspēju - un šāda veida izplatās uz visu - jā, ir arī centrālais procesors, atmiņa, disks, tīkla pieskaitāmās izmaksas, kā arī bloķēšanas problēma vairāk nekā vienai personai, kas vēlas ekskluzīvi izmantot datus noteiktā datumā. noteiktā laikā. Tomēr ir arī slikti SQL zvani, un tas ir šausmīgi daudz, ko var darīt, ja jūs faktiski optimizējat SQL veiktspējas ziņā. Tātad, datu bāzes veiktspējas faktori: slikta konstrukcija, slikta programmas izstrāde, trūkstošās slodzes vienlaicīgums, slodzes līdzsvarošana, vaicājuma struktūra, kapacitātes plānošana. Tas ir datu pieaugums. Un dažos vārdos sakot, SQL ir ērts, bet tas pats neveic optimizāciju.
To sakot, es domāju, ka mēs varam nodot Rikam.
Ēriks Kavanaghs: Labi, Rick, ļaujiet man dot jums WebEx automašīnas atslēgas. Ņem to prom.
Riks Šermens: Labi, lieliski. Labi, paldies Robinam, tā kā mēs sākām prezentācijas sākumā, mana grafika joprojām ir diezgan garlaicīga, bet, protams, iet ar to. Tātad, es piekrītu visam, ko Robins runāja SQL pusē. Bet tas, ko es tagad gribu mazliet koncentrēt, ir pieprasījums pēc datiem, kas ļoti ātri tiek cauri, piegāde, piemēram, šajā telpā izmantotajiem instrumentiem, vai nepieciešamība pēc rīkiem šajā telpā.
Pirmkārt, katrā lasītajā rakstā ir daži ar lieliem datiem, daudz datu, nestrukturētiem datiem, kas nāk no mākoņa, lieliem datiem visur, ko vien varat iedomāties. Bet datu bāzu tirgus pieaugums vienmēr ir bijis ar SQL - relāciju datu bāze, iespējams, no 2015. gada joprojām ir 95 procenti no datu bāzes tirgus. Trīs galvenajiem relāciju pārdevējiem ir aptuveni 88 procenti no tirgus daļas šajā telpā. Tātad, joprojām runājām, kā runāja Robins, par SQL. Patiesībā, pat ja meklētu Hadoop platformā, Hive un Spark SQL - ko mans dēls, kurš ir datu zinātnieks, visu laiku izmanto - noteikti ir dominējošais veids, kā cilvēki var piekļūt datiem.
Tagad datubāzu pusē ir divas plašas datu bāzu izmantošanas kategorijas. Viens no tiem ir paredzēts operatīvām datu bāzu pārvaldības sistēmām, tātad - biznesa attiecību plānošana, klientu attiecību nodrošināšana, Salesforce ERP, Oracles, EPIC, N4 utt., Visā pasaulē. Un tas ir ļoti liels un arvien plašāks datu apjoms datu noliktavās un citās biznesa informācijas sistēmās. Cēlonis visam, neatkarīgi no tā, kur un kā tas tiek notverts, glabāts vai veikts, galu galā tiek analizēts, un tāpēc ir milzīgs pieprasījums un palielinās datu bāzu, jo īpaši relāciju datu bāzu, izmantošana tirgū.
Tagad mēs esam ieguvuši pieprasījumu, un mums nāk milzīgs datu apjoms. Un es nerunāju tikai par lielajiem datiem, es runāju par datu izmantošanu visu veidu uzņēmumos. Bet, sākot no piedāvājuma puses, cilvēkiem, kuri var pārvaldīt šos resursus, mums vispirms ir sava veida DBA deficīts. Pēc Darba statistikas biroja datiem, laikā no 2014. līdz 2024. gadam DBA darbavietu skaits pieaugs tikai par 11 procentiem - tas ir cilvēki, kuriem ir DBA amatu nosaukumi, bet par to labi jārunā sekundē - salīdzinot ar 40 plus plus procentiem ikgadējā datu pieauguma telpa. Un mums ir daudz DBA; vidēji tajā pašā pētījumā tika runāts par vidējo vecumu, salīdzinot ar citām IT profesijām. Un tad mums ir daudz cilvēku, kas pamet šo lauku, ne vienmēr dodoties pensijā, bet gan pārorientējoties uz citiem aspektiem, pāriet vadībā vai kā citādi.
Daļēji iemesls, kāpēc viņi aiziet, ir tāpēc, ka DBA darbs kļūst arvien grūtāks. Pirmkārt, mums ir DBA, kas paši pārvalda dažādas datu bāzes, fiziskās datu bāzes, kas atrodas visur, kā arī dažāda veida datu bāzes. Tagad tas varētu būt relāciju vai arī tie var būt arī citi datu bāzes veidi. Bet, pat ja tas ir saistīts, viņiem varētu būt viens, divi, trīs, četri dažādi pārdevēji, kurus viņi patiesībā mēģina pārvaldīt. DBA parasti iesaistās pēc datu bāzes vai lietojumprogrammas izstrādes. Robins stāstīja par to, kā tiek veidotas datu bāzes vai lietojumprogrammas, kā tiek izveidots SQL. Ja runājam par datu modelēšanu, ER modelēšanu, paplašinātu ER modelēšanu, dimensiju modelēšanu, progresīvu dimensiju modelēšanu, neatkarīgi no tā, ko parasti lietojumprogrammu programmētāji un lietojumprogrammu izstrādātāji projektē, ņemot vērā savu gala mērķi - viņi nedomā par pašas datu bāzes struktūras efektivitāti . Tātad mums ir daudz slikta dizaina.
Tagad es nerunāju par komerciālu uzņēmumu lietojumprogrammu pārdevējiem; viņiem parasti ir ER modeļi vai paplašināti ER modeļi. Tas, par ko es runāju, ir tas, ka katrā uzņēmumā daudz vairāk biznesa procesu un lietojumprogrammu tiek būvēti lietojumprogrammu izstrādātāji - tie ir tie, kas nav obligāti paredzēti ieviešanas efektivitātei. Un pašas DBA ir pārmērīgi strādājošas, un dažkārt viņiem ir 24/7 atbildība, viņi turpina iegūt arvien vairāk datu bāzu. Es domāju, ka tas ir kaut nedaudz saistīts ar to, ka cilvēki īsti nesaprot, ko viņi dara vai kā viņi to dara. Viņu mazā grupa un cilvēki vienkārši domā: “Nu, visi šie rīki ir tik vienkārši lietojami, mēs varam turpināt izmantot arvien vairāk datu bāzu par viņu darba slodzi”, kas tā nav.
Kas mūs noved pie nepilna laika un nejaušām DBA. Mums ir nelielas IT komandas, un tās nevar atļauties īpašu DBA. Tagad tas attiecas uz maziem un vidējiem uzņēmumiem, kur datubāzu un datu bāzu lietojumprogrammu paplašināšana ir eksplodējusi pēdējā desmitgadē un turpina paplašināties. Bet tas attiecas arī uz lielām korporācijām, kuras parasti ilgi un ilgi veic datu glabāšanu un biznesa informācijas analīzi. Sen mēs izmantojām šiem projektiem paredzētas DBA; mēs nekad vairs nesaņemam īpašu DBA. Bijām atbildīgi par datu bāzes izveidošanu, kas ir lieliski, ja tā ir kāda ar pieredzi.Bet kopumā DBA ir lietojumprogrammu izstrādātāji, viņi bieži uzņemas šo lomu kā nepilna darba laika darbu, viņiem tajā nav oficiālu apmācību, un viņi to izstrādā, lai sasniegtu savus mērķus, nevis plāno to efektivitātes uzlabošanai.
Ir arī daudz atšķirību starp dizainu un attīstību, salīdzinot ar izvietošanu un pārvaldību. Tātad mums ir “santīma gudrs, muļķīgs mārciņa” ar nelielu cūciņu banku, izlaižot projektos nepieciešamo prasmju un resursu iegūšanu. Domājot, ka visi ir no “Nerdu atriebības”, mana tur mazā bilde. Tagad, ciktāl tas vajadzīgs cilvēkiem, mums ir arvien plašāka datu bāzu un datu izmantošana SQL. Mums ir ierobežots DBA skaits - cilvēki, kuri ir prasmīgi un kompetenti šajās skaņošanas un projektēšanas, kā arī pārvaldības un izvietošanas situācijās. Un mums ir arvien vairāk nepilna laika vai nejaušu DBA, cilvēki, kuriem vēl nav bijusi oficiāla apmācība.
Tātad, kādas ir dažas citas lietas, kas arī iedziļinās jautājumā par to, ka arī šīs datubāzes netiek pielāgotas vai tiek pārvaldītas? Pirmkārt, daudzi cilvēki pieņem, ka datu bāzes sistēmai pašai ir pietiekami rīki, lai sevi pārvaldītu. Tagad rīkus kļūst vieglāk un vieglāk izdarīt - projektēšanu un izstrādi -, bet tas atšķiras no ieviešanas labu dizainu un labu pārvaldību, kapacitātes plānošanu, uzraudzību utt. Tātad vispirms cilvēki pieņem, ka viņiem ir visi nepieciešamie rīki. Otrkārt, ja esat nepilna laika vai nejaušs DBA, jūs nezināt, ko nezināt.
Es domāju, ka es aizmirsu daļu no šīs frāzes, tāpēc ka daudzas reizes viņi vienkārši nesaprot, kas viņiem pat ir jāaplūko, izstrādājot dizainu vai pārvaldot vai izmantojot datu bāzes. Ja tā nav jūsu profesija, tad nesapratīsit, kas jums jādara. Treškārt, SQL ir tiešais rīks, tāpēc Robins runāja par SQL un to, cik slikti SQL dažreiz tiek veidots vai bieži tiek konstruēts. Un arī viens no maniem lolojumdzīvniekiem ir saistīts ar datu glabāšanu BI, datu migrēšanu un datu inženieriju, jo cilvēkiem ir tendence rakstīt SQL kodu, pat saglabātās procedūras, pat ja tie izmanto rīkus, pat ja viņi izmanto dārgu datu integrācijas rīku vai dārgu BI rīks, viņi bieži to tiešām izmanto tikai, lai palaistu saglabātās procedūras. Tā, ka arvien svarīgāka kļūst izpratne par datu bāzes dizainu un SQL konstruēšanu.
Visbeidzot ir šī tvertnes pieeja, kurā mums ir atsevišķi cilvēki, kas skatās atsevišķas datu bāzes. Viņi neskatās, kā lietojumprogrammas darbojas un mijiedarbojas savā starpā. Un viņi arī bieži meklē datu bāzes salīdzinājumā ar lietojumprogrammām, kurās tās izmanto. Tātad darba slodze, ko iegūstat datu bāzē, ir kritiska projektēšanā, kritiska tās pielāgošanā, kritiska, mēģinot izdomāt, kā plānot ietilpību utt. Tātad, aplūkojot mežu no kokiem, cilvēki atrodas nezālēs , apskatot atsevišķās tabulas un datu bāzes un neapskatot šo lietojumprogrammu kopējo mijiedarbību darba slodzē.
Visbeidzot, cilvēkiem ir jāaplūko galvenās jomas, kuras viņiem ir jāaplūko. Plānojot datu bāzu pārvaldību, viņiem vispirms jādomā par, jāizstrādā daži uz lietojumprogrammām orientēti veiktspējas rādītāji, tāpēc viņiem ir jāapskata ne tikai tas, kā šī tabula ir strukturēta, kā tā ir īpaši modelēta, bet arī kā tā tiek izmantota? Tātad, ja jums ir uzņēmuma lietojumprogrammas, kas ir jāmaksā piegādes ķēdes pārvaldībā, ja pasūtījumus veicat tīmeklī, ja darāt BI - neatkarīgi no tā, ko darāt, jums jāaplūko, kas to izmanto, kā viņi to izmanto, kādi ir datu apjomi , kad tas notiks. Tas, ko jūs patiešām cenšaties meklēt, ir nogaidīšanas laiki, jo neatkarīgi no tā, visas lietojumprogrammas tiek vērtētas pēc tā, cik ilgs laiks nepieciešams, lai kaut ko izdarītu, neatkarīgi no tā, vai tā ir persona vai tikai datu apmaiņa starp lietojumprogrammām vai procesoriem. Un kādas ir vājās vietas? Tik bieži, mēģinot atkļūdot jautājumus, protams, jūs patiešām cenšaties izpētīt, kādi ir īstie sašaurinājumi - ne vienmēr kā visu noregulēt, bet gan kā atbrīvoties un novirzīt priekšnesumu uz gaidīšanas laiku un caurlaides spēju - neatkarīgi no tā, jums jāskatās.
Un jums tiešām ir jānošķir datu uztveršana, transakcijas, pārveidojumu aspekti datu bāzē, kā arī analītika. Katram no tiem ir atšķirīgi dizaina modeļi, katram no tiem ir atšķirīgi lietošanas veidi, un katram no tiem ir jābūt noregulētiem atšķirīgi. Tātad jums ir jādomā par to, kā šie dati tiek izmantoti, kad tie tiek izmantoti, kādiem nolūkiem tie izmantoti, un jāizdomā, kāda ir veiktspējas metrika un kādas ir galvenās lietas, kuras vēlaties analizēt saistībā ar šo lietojumu. Tagad, kad skatāties veiktspējas uzraudzību, jūs vēlaties aplūkot pašas datu bāzes darbības; vēlaties aplūkot abas datu struktūras, tāpēc indeksi, sadalīšana un citi datu bāzes fiziskie aspekti, pat datu bāzes struktūra - neatkarīgi no tā, vai tas ir ER modelis vai dimensiju modelis, lai arī cik strukturēts -, visām šīm lietām ir ietekme uz veiktspēju , jo īpaši dažādos datu uztveršanas analīzes mīnusos un notiekošajās transformācijās.
Un kā Robins minēja SQL pusē, ir svarīgi kritiski aplūkot SQL, kas tiek pārvaldīts no šīm dažādajām lietojumprogrammām šajās datu bāzēs. Apskatot kopējo lietojumprogrammu darba slodzi un infrastruktūras vidi, kurā darbojas šīs datu bāzes un lietojumprogrammas. Tātad, lai tīkli, serveri un mākonis - neatkarīgi no tā, kur tie darbojas - arī apskatītu šo programmu un šo datu bāzu ietekmi tajā pašā kontekstā, visi šie elementi ir savstarpēji saistīti, lai varētu noskaņot datu bāzi.
Visbeidzot, aplūkojot rīkus, jūs vēlaties apskatīt trīs dažādus ar to saistītos analītiskos veidus. Vēlaties aplūkot aprakstošu analīzi: kas notiek un kur, kas saistīts ar datu bāzi un lietojumprogrammu veiktspēju. Jūs vēlaties, lai būtu iespēja veikt diagnostisko analīzi, lai izdomātu ne tikai to, kas notiek, bet kāpēc tas notiek, kur ir vājās vietas, kur ir problēmas, kas darbojas labi, kas nedarbojas labi? Bet spēja analizēt un iedziļināties problemātiskajās zonās, lai pievērstos tām gan dizaina, gan arī visa cita dēļ.
Visbeidzot, visagresīvākais vai proaktīvākais analīzes veids ir faktiski veikt kādu paredzamo analīzi, prognozējošo analītisko modelēšanu, neatkarīgi no tā. Mēs zinām, ka datu bāze un lietojumprogrammas darbojas šajā kontekstā, ja mēs palielinām ietilpību, ja iegūstam vairāk lietotāju, ja darām lielāku caurlaidspēju, neatkarīgi no tā, ko darām, un varam projicēt, kas, kā un kur tas ietekmē datu bāzi, lietojumprogrammas, ļauj mums plānot un proaktīvi izdomāt, kur ir vājās vietas, kur var ciest gaidīšanas laiki un kas mums jādara, lai salabotu lietas. Tāpēc mēs vēlamies, lai būtu rīki, kas varētu ieviest veiktspējas rādītājus, uzraudzīt veiktspēju, tāpat kā šie trīs analīzes veidi. Un tas ir mans pārskats.
Ēriks Kavanaghs: Labi, atļaujiet man to nodot - starp citu, tās ir divas lieliskas prezentācijas - ļaujiet man to nodot Bullett Manale, lai ņemtu to no turienes. Un ļaudis, neaizmirstiet uzdot labus jautājumus; mums jau ir labs saturs. Atņemiet to, Bullett.
Bullett Manale: Izklausās labi. Paldies, Ēriks. Tātad, daudz no tā, ko teica Riks un Robins, acīmredzot es piekrītu 100 procentiem. Es teiktu, ka es uzvilku šo slaidu, jo, manuprāt, tas ir piemērots, es nezinu tiem no jums, kas ir “A-Team” fani 80. gados, Džons Hannibala Smits teica, ka viņš vienmēr saka: “Es mīlu tas ir, kad plāns sanāk kopā ”, un es domāju, ka, kad jūs runājat par īpaši SQL Server, uz kuru tika koncentrēta uzmanība, kas ir produkts, par kuru šodien runāsim, SQL Diagnostic Manager, tā noteikti ir viena no tām lietām, kas jums ir jābūt; jums jāspēj izmantot jūsu rīcībā esošos datus un pieņemt lēmumus, pamatojoties uz šiem datiem, un dažos gadījumos jūs nemeklējat lēmumu; jūs meklējat kaut ko, lai pateiktu, kad kaut kas beidzas ar resursiem, kad jums beigsies resursi, kad jums būs sašaurinājums, šāda veida lietas.
Tas attiecas ne tikai uz noteiktas metrikas uzraudzību. Tātad, izmantojot Diagnostic Manager, viena no lietām, ko tas dara ļoti labi, jums palīdzēs prognozēšanas un darba slodzes īpašās izpratnes jomā, un šodien par to daudz runāsim. Šis rīks ir paredzēts datu pārvaldītājam, DBA vai darbojas DBA, tāpēc daudzas lietas, kuras Riks pieminēja, darbojas DBA. Daudzos gadījumos, ja jūs neesat DBA, theres būs daudz jautājuma zīmju, kuras jums būs, kad pienāk laiks pārvaldīt SQL vidi, lietas, kuras jūs nezināt. Un tāpēc jūs meklējat kaut ko, kas jums palīdzētu, iepazīstinātu jūs ar šo procesu un izglītotu arī jūs šajā procesā. Tāpēc ir svarīgi, lai rīks, kuru izmantojat šāda veida lēmumiem, sniegtu jums nelielu ieskatu par iemesliem, kāpēc šie lēmumi tiek pieņemti, tas jums ne tikai pasaka: “Ei, dari to.”
Tā kā esmu DBA pārstāve, galu galā es varētu būt pilnvērtīga DBA ar faktiskajām zināšanām un zināšanām, lai atbalstītu šo titulu. Tātad, runājot par datu bāzes administratoru, es vienmēr parādīšu šo slaidu vispirms, jo DBA ir dažas atšķirīgas lomas un atkarībā no organizācijas, kurā strādājat, jums būs, tās atšķirsies no no vienas vietas uz otru - bet parasti jūs vienmēr kaut kādā veidā esat atbildīgs par jūsu krātuvi, šīs krātuves plānošanu un izpratni par to, kā paredzēt, man jāsaka, cik daudz vietas jums vajadzēs, vai tā ir paredzēta jūsu dublējumiem, vai vai tas attiecas uz pašām datu bāzēm. Jums tas būs jāsaprot un jānovērtē.
Turklāt jums būs jāspēj saprast un optimizēt lietas pēc nepieciešamības, un, kad jūs ejat apkārtējās vides uzraudzību, ir acīmredzami svarīgi, lai jūs veiktu izmaiņas, jo tās ir vajadzīgas, pamatojoties uz lietām, kas mainās vidē. pati. Prognozēšanas laikā jāņem vērā tādas lietas kā lietotāju skaits, piemēram, lietojumprogrammu popularitāte, datu bāzes sezonalitāte. Un tad acīmredzami aplūko citas lietas attiecībā uz iespēju sniegt ziņojumus un informāciju, kas ir nepieciešama, ciktāl tas attiecas uz šo lēmumu pieņemšanu. Daudzos gadījumos tas nozīmē veikt salīdzinošo analīzi; tas nozīmē, ka jāspēj īpaši aplūkot noteiktu metriku un saprast, kāda laika gaitā ir bijusi šīs metrikas vērtība, lai jūs varētu paredzēt, kur tā virzīsies uz priekšu.
Tātad tam, ko paveic Diagnostic Manager rīks, ir šīs iespējas, un cilvēki to izmanto katru dienu, lai varētu veikt tādas darbības kā prognozēšana, un es šeit ievietoju jaudas plānošanas definīciju. Un tā ir diezgan plaša un patiesībā diezgan neskaidra definīcija, kas ir tikai ražošanas jaudas noteikšanas process, kas vajadzīgs organizācijai, lai apmierinātu mainīgās prasības pēc tās produktiem, un dienas beigās tas tiešām ir viss, kas tas ir: par iespēju uztvert informāciju, kas jums ir kaut kādā veidā, un šīs informācijas pieņemšanu un lēmumu pieņemšanu, lai palīdzētu jums virzīties uz priekšu, virzoties uz priekšu jūsu datu bāzu dzīves ciklā. Un tā, lietu veidi, kas ir iemesls, kāpēc cilvēkiem tas jādara, acīmredzami, pirmkārt, ir galvenokārt naudas ietaupīšana. Acīmredzot uzņēmumu galvenais mērķis ir nopelnīt naudu un ietaupīt naudu. Bet vienlaikus tas nozīmē arī spēju pārliecināties, ka jūsu dīkstāves nav. Un spēja pārliecināties, ka jūs mazināt visas dīkstāves iespējas, tāpēc neļaujiet tai sākties, citiem vārdiem sakot, negaidiet, kamēr tā notiks, un tad reaģējiet uz to.
Šeit bez šaubām ir arī iespēja palielināt savu lietotāju produktivitāti, padarot tos efektīvākus, lai jūs varētu vairāk nokārtot biznesu, tāpēc šeit acīmredzami ir arī galvenā lieta, tāpēc šie ir lietu veidi, ko kā DBA vai kāds, kas iesaistīts prognozēšanā vai kapacitātē plānošanai būs jāspēj izsekot informācijai, lai spētu pieņemt šos lēmumus. Un tad kopumā tas acīmredzami palīdzēs jums novērst atkritumu rašanos, ne tikai naudas ziņā, bet arī laika ziņā un vispārīgi runājot par resursiem, kurus, iespējams, varētu izmantot citām lietām. Tātad, spējot iznīcināt šos atkritumus tā, ka jums nav papildu izmaksu, kas ir saistīta ar pašiem atkritumiem.
Tātad, ņemot vērā iepriekš teikto, kādi ir jautājumu veidi, kurus mēs saņemam un kas ir specifiski personai, kas ir DBA? Kad man beigsies telpa? Tas ir liels, ne tikai to, cik daudz vietas es patērēju tagad, bet arī kad es būšu izsīcis, balstoties uz tendencēm un pagātnes vēsturi? Tas pats ar faktiskajiem SQL gadījumiem, datu bāzēm, kurus serverus es varu konsolidēt? Es ielikšu dažus VM, kāda jēga ir to datu bāzēm, kuras es konsolidēšu un kādos SQL gadījumos tām vajadzētu atrasties? Uz visiem šiem jautājumiem ir jāspēj atbildēt. Jo vairumā gadījumu, ja jūs esat DBA vai darbojaties DBA, jūs to plānojat nostiprināt kaut kad savā karjerā. Daudzos gadījumos jūs to darīsit pastāvīgi. Tātad jums ir jāspēj ātri pieņemt šos lēmumus, nevis jāspēlē minēšanas spēles, kad runa ir par to.
Mēs runājām par sastrēgumiem un to, kur tie notiks tālāk, spējot to atkal paredzēt, tā vietā, lai gaidītu, kamēr tie notiks. Tātad acīmredzami par visām šīm lietām bija jēga tādā nozīmē, ka, paļaujoties uz vēsturiskiem datiem, vairumā gadījumu spējat ģenerēt šos ieteikumus vai dažos gadījumos spēt pats formulēt lēmumus, lai spētu nāciet klajā ar šīm atbildēm. Bet tas man atgādina, kad, dzirdot radio reklāmas kādam, kurš pārdod vērtspapīrus vai kaut ko tamlīdzīgu, tas vienmēr “iepriekšējais sniegums neliecina par nākotnes rezultātiem” un tamlīdzīgas lietas. Un tas pats attiecas arī uz šeit. Jums būs situācijas, kad šīs prognozes un šīs analīzes var nebūt 100% pareizas. Bet, ja jūs nodarbojaties ar lietām, kas ir notikušas pagātnē un ir zināmas, un spējat uzņemties un paveikt “kas būtu, ja” ar daudziem šāda veida jautājumiem, jums nāksies ieskrieties, tas ir ļoti vērtīgi, un tas notiks aizvedīs jūs daudz tālāk, nekā spēlējot minēšanas spēli.
Tātad, šie jautājumu veidi acīmredzami nāks klajā, tāpēc kā mēs ar Diagnostic Manager pārvaldīsim daudzus no šiem jautājumiem, pirmkārt, mums ir prognozēšanas iespējas, jo mēs to varam izdarīt datu bāzē, pie galda, kā arī piedziņa vai skaļums. Lai varētu ne tikai pateikt: “Hei, bija vietas daudz”, bet arī pēc sešiem mēnešiem, divus gadus pēc šī brīža, pēc pieciem gadiem, ja es tam plānoju budžetu, cik daudz vietas man vajadzēs budžetā priekš? Tie ir jautājumi, kas man būs jāuzdod, un man vajadzēs spēt izmantot kādu metodi, kā to izdarīt, nevis minēt un likt pirkstu gaisā un gaidīt, lai redzētu, kur pūš vējš, kas ir daudz reizes, diemžēl, veids, kā tiek pieņemti daudzi šie lēmumi.
Papildus tam, ka spēja - izskatās, ka mans slaidiņš tur bija mazliet nogriezts -, bet spēja sniegt zināmu palīdzību ieteikumu veidā. Tā ir viena lieta, lai jūs varētu parādīt metriku, kas ir pilna ar metriku, un pateikt: “Labi, šeit ir redzami visi rādītāji un to atrašanās vieta”, bet pēc tam spēt izveidot dažus vai kaut nedaudz saprast, ko darīt darīt, pamatojoties uz to, ir vēl viens lēciens. Un dažos gadījumos cilvēki ir pietiekami izglītoti DBA lomā, lai spētu pieņemt šos lēmumus. Tāpēc rīkā ir daži mehānismi, kas palīdzēs ar to darboties, un tas jums labi parādīsies tikai sekundes laikā. Bet spēja parādīt ne tikai ieteikumu, bet arī sniegt nelielu ieskatu, kāpēc šis ieteikums tiek izteikts, un pēc tam arī dažos gadījumos spēt nākt klajā ar skriptu, kas automatizē ieteikumu. arī šī jautājuma atlīdzināšana ir ideāla.
Pārejot pie nākamā šeit, kas labi redzams, tā vienkārši vispārīgi saprotamā izpratne līdz metriskajam līmenim ir normāla. Es nevaru pateikt, kas nav normāli, ja es nezinu, kas ir normāli. Un tāpēc, lai kaut kādā veidā izmērītu to, kas ir galvenais, un jums vajadzēja spēt ņemt vērā vairāku veidu apgabalus, piemēram, vai, man jāsaka, termiņus, dažādas serveru grupas, spējot to izdarīt dinamiski, sākot no trauksmes perspektīva, citiem vārdiem sakot, nakts vidū, uzturēšanas loga laikā, es ceru, ka mana centrālā procesora darbība būs 80 procenti, pamatojoties uz visiem uzturēšanas darbiem, kas notiek. Tāpēc es varētu vēlēties paaugstināt savus sliekšņus augstāk šajos laika periodos, salīdzinot ar varbūt dienas vidū, kad es neveicu tik daudz aktivitātes.
Šīs ir dažas lietas, kas acīmredzami būs videi draudzīgas, taču tās var attiecināt uz to, kas tiek pārvaldīts, lai varētu jums palīdzēt efektīvāk pārvaldīt šo vidi un padarot to vienkāršāku. Acīmredzami otra joma kopumā spēj sniegt tikai ziņojumus un informāciju, lai varētu atbildēt uz šāda veida jautājumiem “kas būtu, ja”. Ja es tikko izdarīju izmaiņas savā vidē, es vēlos saprast, kāda ir šī ietekme, lai es varētu šīs pašas izmaiņas piemērot arī citiem gadījumiem vai citām datu bāzēm manā vidē. Es vēlos, lai man būtu kāda informācija vai kāda munīcija, lai varētu veikt šīs izmaiņas ar mieru un apzinoties, ka tās būs labas izmaiņas. Tātad, spējot veikt šo salīdzinošo pārskatu, spēt sarindot manus SQL gadījumus, spēt sarindot manas datu bāzes savā starpā, pateikt: “Kurš ir mans augstākais CPU patērētājs?” Vai kurš no tiem ilgāk izmanto termiņu gaidīšanas un tamlīdzīgas lietas? Tātad liela daļa šīs informācijas būs pieejama arī ar rīku.
Un visbeidzot, bet ne mazāk svarīgi, tā ir tikai vispārējā spēja, ka jums ir nepieciešams rīks, kas ir paredzēts, lai spētu rīkoties neatkarīgi no situācijas, kas nāk jūsu virzienā, un tāpēc es domāju to ar to, ka, ja esat ieguvis lielu vidi ar daudz piemēram, jūs, iespējams, nonāksit situācijās, kad jums būs jāvelk metrika, kas tradicionāli nav metrika, kuru DBA dažos gadījumos vēlētos pat uzraudzīt, atkarībā no konkrētās situācijas. Tātad, ja jums ir rīks, kuru jūs varat paplašināt, lai varētu pievienot papildu metriku un varētu izmantot tos metrus tādā pašā formā un veidā, kā jūs tos lietotu, ja jūs lietotu ārpus kastītes metriskā, piemēram. Tātad, spēja vadīt pārskatus, spēja brīdināt, sākotnējais stāvoklis - visas lietas, par kurām tika runāts - ir arī galvenā daļa no tā, lai spētu veikt šo prognozēšanu un veidošanu, lai jūs saņemtu atbildes, kuras meklējat, lai varētu sniegt šie lēmumi, virzoties uz priekšu.
Tagad, kā to dara Diagnostic Manager, mums ir centralizēts pakalpojums - pakalpojumu grupa, kas darbojas, apkopo datus no 2000 līdz 2016 gadījumiem. Un tas, ko mēs darām, ir tas, ka mēs ņemam šos datus un ievietojam tos centrālajā repozitorijā, un tad, protams, ko mēs labi darām ar šiem datiem, mēs daudz darām, lai varētu sniegt papildu ieskatu. Tagad papildus tam - un viena no lietām, kas šeit nav aplūkots - vai mums ir arī pakalpojums, kas darbojas nakts vidū, kas ir mūsu paredzamās analīzes dienests, un tas kaut nedaudz izsauc numuru un palīdz saprast un palīdzēt jums kā DBA vai rīkojoties DBA, spēt sniegt šāda veida ieteikumus, kā arī sniegt nelielu ieskatu bāzes līniju jomā.
Tātad, ko es gribētu darīt, un tas ir tikai ātrs arhitektūras piemērs, šeit lielā izņemšana nav tie aģenti vai pakalpojumi, kas patiesībā sēž jūsu pārvaldītajās instancēs. Bet tas, ko es gribētu darīt, ir tikai reāla pieeja šeit esošajai lietojumprogrammai un ātra demonstrācija. Un ļaujiet man arī vienkārši iziet ārā, un lai tas notiek. Tātad, ļaujiet man zināt, es domāju, Ēriks, vai jūs varat redzēt, ka viss ir kārtībā?
Ēriks Kavanaghs: Es to saņēmu tagad, jā.
Bullett Manale: Labi, tāpēc es iepazīšos jūs ar dažām no šīm dažādajām daļām, par kurām es runāju. Un būtībā ļauj sākt ar lietām, kas vairāk saskan ar šeit sastopamajām lietām, kas jums jādara, vai arī šeit ir kaut kas nākotnē svarīgs un kas jums sniegs nelielu ieskatu par to. Un tas spēj patiesi paredzēt - vai man vajadzētu teikt, dinamiski paredzēt - lietas tā, kā tās notiek. Tagad pārskatu gadījumā viena no lietām, kas mums ir rīkā, ir trīs dažādi prognozēšanas pārskati. Un, piemēram, datu bāzes prognozes gadījumā, ko es, iespējams, darītu situācijā, ja es varētu paredzēt datu bāzes lielumu noteiktā laika posmā, un es tikai sniedzu jums dažus piemērus. Tāpēc es ņemšu savu revīzijas datu bāzi, kas ir diezgan intensīva I / O intensitāte - tajā ir daudz datu. Mēs šeit esam ieguvuši, redzam, labi darām, un šeit varēsim izvēlēties veselības aprūpes datu bāzi.
Bet jēga ir tāda, ka es ne tikai redzu, kāda ir šī telpa, bet arī varu pateikt: “Paskatieties, ļaujiet ņemt pēdējos gadus vērtus datus” - un es vēl mazliet piefiksēju, man īsti nav gadu Datu vērtībā, man ir apmēram divus mēnešus vērti dati, bet, tā kā šeit izvēlējos mēnešu izlases likmi, es šajā gadījumā varēšu paredzēt vai prognozēt nākamās 36 vienības, jo mūsu izlases likme ir noteikta mēnešiem. - tā ir vienība, ir mēnesis - un tad es varētu pēc tam sagatavot ziņojumu, lai principā parādītu man, kur mēs varētu paredzēt mūsu turpmāko izaugsmi šīm trim datu bāzēm. Un mēs varam redzēt, ka starp trim dažādām datu bāzēm ir dažāda līmeņa atšķirība vai dispersija, it īpaši attiecībā uz datu daudzumu, ko viņi vēsturiski patērē.
Mēs redzam, ka šeit esošie datu punkti attēlo vēsturiskos datus, un pēc tam līnijas, kuras mums sniegs prognozi, kopā ar skaitļiem, kas to dublē. Tātad mēs to varam izdarīt galda līmenī, mēs to varam izdarīt pat piedziņas līmenī, kur es varu paredzēt, cik lielus manus diskus iegūs, ieskaitot stiprināšanas punktus. Mēs varētu prognozēt tāda paša veida informāciju, bet atkal, atkarībā no izlases intensitātes, man ļaus noteikt, cik vienību un kur tika ņemts, ko mēs vēlamies prognozēt. Ņemiet vērā, ka mums ir arī dažādi prognožu veidi. Tātad jūs saņemat daudz iespēju un elastības, kad ir pienācis laiks veikt prognozēšanu. Tagad tas viss ir labi, faktiski dodot jums konkrētu datumu un spējot pateikt: “Ei, šajā datumā, mēs sagaidām, ka jūsu dati pieaugs.” Turklāt mēs tomēr varam jums sniegt ar citām atziņām, kas saistītas ar kādu no analīzēm, kuras mēs veicam darba laikā un pakalpojumu, kad tā darbojas. Dažas no lietām, ko tā dara, ir mēģinājums paredzēt lietas, kas, iespējams, notiks, balstoties uz vēstures to laiku, kad lietas notika pagātnē.
Tātad faktiski šeit redzam, ka prognoze sniedz mums nelielu ieskatu iespējamībā, ka mums vakara laikā radīsies problēmas, balstoties uz lietām, kas atkal ir notikušas pagātnē. Tātad, protams, tas ir lieliski, it īpaši, ja es neesmu DBA, es varu apskatīt šīs lietas, bet kas vēl labāk, ja es neesmu DBA, šī ir analīzes cilne. Tātad, pirms tas bija šeit, rīkā, kuru mēs apskatītu un parādītu produktu cilvēkiem, un viņi būtu “Tas ir lieliski, es redzu visus šos numurus, es redzu visu, bet es nezinu, ko darīt” (smejas) “kā tā rezultāts. ”Un tas, kas mums šeit ir, ir labāks veids, kā jūs varat saprast, ja es gatavojos rīkoties, lai palīdzētu ar sniegumu, ja es gatavojos rīkoties, lai pat palīdzētu manas veselības labā. vide, spēja būt vērtētam veidam, kā sniegt šos ieteikumus, kā arī noderīgiem informācijas padomiem, lai uzzinātu vairāk par šiem ieteikumiem un patiesībā pat ar ārējām saitēm ar dažiem no šiem datiem, kas man parādīs un apskatīs iemeslus, kāpēc šie ieteikumi ir sniegti.
Un daudzos gadījumos spēja nodrošināt skriptu, kas automatizētu, kā es teicu, šo problēmu novēršanu. Daļa no tā, ko mēs šeit darījām ar šo analīzi - un es jums parādīšu, kad es dodos konfigurēt šī gadījuma rekvizītus un dodos uz analīzes konfigurācijas sadaļu - mums ir daudz dažādu kategoriju, kas šeit ir uzskaitītas, un Daļa no tā mums ir indeksa optimizācija un vaicājumu optimizācija. Tātad, tika vērtēta ne tikai pati metrika un tamlīdzīgas lietas, bet arī tādas lietas kā darba slodze un indeksi. Šajā gadījumā veiciet arī papildu hipotētisku indeksa analīzi. Tā ir viena no tām situācijām, kad es daudzos gadījumos nevēlos pievienot indeksu, ja tas man nav vajadzīgs. Bet kādā brīdī ir sava veida atskaites punkts, kur es saku: “Nu, tabula kļūst pie tāda lieluma vai tādu vaicājumu veidiem, kuri darbojas darba apjomā, tagad ir jēga pievienot indeksu. Bet tam nebūtu bijis jēgas varbūt sešas nedēļas iepriekš. ”Tātad tas ļauj jums dinamiski iegūt ieskatu lietās, kas, kā jau teicu, uzlabos sniegumu, pamatojoties uz to, kas notiek vidē, kas notiek darba slodzēs, un darot tādas lietas.
Tātad jūs šeit iegūstat daudz labas informācijas, kā arī iespēju šīs lietas automātiski optimizēt. Tā ir vēl viena joma, kurā mēs varētu palīdzēt, ņemot vērā to, ko mēs saucam par prognozējošo analīzi. Tagad, man jāsaka, ka mums ir arī citas jomas, kuras, manuprāt, parasti palīdz jums pieņemt lēmumus. Un, kad mēs runājam par lēmumu pieņemšanu, mēs atkal varam aplūkot vēsturiskos datus, sniedzot zināmu ieskatu, lai nokļūtu tur, kur mums jābūt, lai uzlabotu šo sniegumu.
Tagad viena no lietām, ko mēs varam darīt, ir tāda, ka mums ir sākotnējais vizualizators, kas ļauj mums selektīvi izvēlēties jebkuru metriku, kuru mēs vēlamies, - un ļaujiet man šeit atrast pienācīgu -, es dodos uz SQL CPU izmantošanu, taču jēga ir tā, ka varat doties Tomēr dažu nedēļu laikā varat gleznot šos attēlus, lai jūs varētu redzēt, kad ir jūsu novirzes, lai vispārīgi runājot, kur šī vērtība ietilpst laika periodos, par kuriem mēs esam apkopojuši datus. Un tad papildus tam jūs arī pamanīsit, ka, izejot pie pašas faktiskās instances, mums ir iespēja konfigurēt savas bāzes līnijas. Sākumlīnijas ir patiešām svarīga sastāvdaļa, lai spētu automatizēt lietas, kā arī lai tiktu informētas par lietām. Un izaicinājums, kā jums teiktu vairums DBA, ir tas, ka jūsu vide visu dienu ne vienmēr darbojas vienādi, salīdzinot ar vakaru, un tas, kā mēs jau pieminējām iepriekš piemērā ar uzturēšanas periodiem, kad mēs ir augsts CPU līmenis vai jebkurš cits, kas varētu notikt.
Tātad šajā gadījumā ar šīm faktiskajām bāzes līnijām mums var būt vairākas bāzes līnijas, tāpēc man varētu būt, piemēram, bāzes līnija, kas ir mana apkopes laikā. Bet tikpat viegli es varētu izveidot bāzes punktu savām ražošanas stundām. To darīt ir tad, kad mēs iedziļināmies SQL eksemplārā un mums faktiski ir šīs vairākas bāzes līnijas, tad mēs varētu paredzēt un spēt veikt kaut kāda veida automatizāciju, kāda veida sanāciju vai vienkārši brīdināšanu kopumā, atšķirīgi specifiski tiem laika logiem. Tātad, viena no lietām, ko jūs šeit redzēsit, ir tas, ka šīs ģenerētās bāzes līnijas izmanto vēsturiskos datus, lai sniegtu šo analīzi, bet vēl svarīgāk ir tas, ka es varu šos sliekšņus statiski mainīt, bet es varu tos automatizēt arī dinamiski. Tātad, kad parādās tehniskās apkopes logs vai, man jāsaka, ka sākotnējais tehniskās apkopes logs, šie sliekšņi automātiski pārslēdzas tieši uz slodzēm, ar kurām saskaras šajā laika posmā, salīdzinot ar dienas vidu, kad manas kravas nav tik lielas daudz, kad darba slodzes nav tik ietekmīgas.
Tas ir kaut kas cits, kas jāpatur prātā, ņemot vērā sākotnējo situāciju. Acīmredzot tie jums būs patiešām noderīgi, saprotot arī to, kas ir normāli, un spēja arī saprast, iesaistīties, kad arī jums būs izlietoti resursi. Cita veida lieta, kas mums ir šajā rīkā, kas palīdzēs jums pieņemt lēmumus, papildus bāzes noteikšanai un iespējai iestatīt brīdinājumus ap tām bāzes līnijām un dinamiski izveidotajiem sliekšņiem, ir tāda, kā es teicu iepriekš, tikai spēja izpildīt neskaitāmas atskaites, kas man palīdz atbildēt uz jautājumiem par notiekošo.
Tātad, piemēram, ja man bija 150 gadījumi, kurus pārvaldīju - manā gadījumā es to nedaru, tāpēc mums šeit ir jāspēlē izlikšanās -, bet, ja man būtu visas manas producēšanas instances un man būtu jāsaprot, kur ir joma, kurā es nepieciešama uzmanība, citiem vārdiem sakot, ja man būs ierobežots laiks, lai veiktu kāda veida administrēšanu, lai uzlabotu sniegumu, es vēlos koncentrēties uz galvenajām jomām. Un tā, ņemot vērā iepriekš teikto, es varētu pateikt: “Balstoties uz šo vidi, sakārtojiet manus gadījumus viens pret otru un piešķiriet man šo vērtējumu pa konkursa mēģinājumiem.” Tātad, vai tā diska izmantošana, atmiņas izmantošana, vai tas gaida, neatkarīgi no tā, vai tas ir reakcijas laiks, es varu korelē - vai man vajadzētu teikt, rangs - šīs lietas viena pret otru. Acīmredzot šī ir katra saraksta augšdaļā esošā instance, ja tā ir tā pati instance, iespējams, tas ir kaut kas, uz ko es patiešām vēlos koncentrēties, jo tā acīmredzami atkal ir saraksta augšgalā.
Tātad, rīkā ir daudz pārskatu, kas palīdz klasificēt vidi instanču līmenī; to var izdarīt arī datu bāzu līmenī, kur es varu savas datu bāzes sakārtot viena pret otru. Īpaši sliekšņiem un apgabaliem, kurus varu iestatīt, šeit pat varu iestatīt aizstājējzīmes, ja gribu, lai koncentrētos tikai uz noteiktām datu bāzēm, bet vissvarīgākais ir tas, ka es varu salīdzināt savas datu bāzes tādā pašā veidā. Tāpat kā cita veida salīdzinošā analīze un lielā šī rīka analīze, ir arī pamata analīze. Tātad, ritinot uz leju līdz pakalpojuma skatam šeit, redzēsit, ka tas ir bāzes statistikas pārskats. Tagad šis ziņojums acīmredzami palīdzēs mums saprast ne tikai metrikas vērtības, bet arī konkrētā gadījumā es varētu iziet un jebkurai no šīm metrikām faktiski spēt aplūkot šo metriku bāzes līnijas.
Tātad, neatkarīgi no tā, kāds tas varētu būt, procentos vai neatkarīgi no tā, ko es varētu iziet un pateikt: “Ļaujiet tam redzēt bāzes līniju, kas sadalīta pēdējās 30 dienās”, šajā gadījumā tā man parādīs faktiskās vērtības salīdzinājumā ar bāzes līniju un Acīmredzot es varētu pieņemt dažus lēmumus, izmantojot šo informāciju, tāpēc šī ir viena no tām situācijām, kad tā būs atkarīga no tā, kāds tas ir jautājums, kuru jūs tajā laikā uzdodat. Bet tas acīmredzami palīdzēs jums daudzos no šiem jautājumiem. Es vēlētos, lai es teiktu, ka mums ir viens ziņojums, kas to visu izdara, un tāds pats kā vieglais ziņojums, kurā jūs nospiežat un nospiedat pogu, un tas tikai atbild uz katru jautājumu “kas būtu, ja”, uz kuru jūs kādreiz varētu atbildēt. Bet realitāte ir tāda, ka jums būs daudz atribūtu un daudz iespēju, lai jūs varētu izvēlēties no šiem nolaižamajiem rakstiem, lai varētu formulēt tos “kas būtu, ja” tipa jautājumus, kurus meklējat.
Tātad liela daļa šo ziņojumu ir domāti tam, lai varētu atbildēt uz šāda veida jautājumiem. Tāpēc patiesi svarīgi ir arī tas, ka šie pārskati un turklāt visas lietas, kuras mēs jums jau parādījām rīkā, kā jau minēju iepriekš, ar iespēju elastīgi iekļaut jaunus rādītājus, kas jāpārvalda, pat spējot izveidot skaitītājus, vai SQL vaicājumus, kas ir iestrādāti jūsu vēlēšanu intervālos, lai varētu man palīdzēt atbildēt uz šiem jautājumiem, ka varbūt jūs varat pievienot šo saturu ārpus tām iespējām, kuras mēs negaidījām pārraudzīt. Un jūs pēc tam varēsit darīt visas tās pašas darbības, kuras es jums tikko parādīju: pamatlīmeni, vadīt pārskatus un izveidot pārskatus no šīs metrikas, kā arī varēsit atbildēt un izdarīt daudz dažādu šo lietu veidu, kuras jums šeit parādīju.
Tagad, papildus tam - un viena no lietām, kas pēdējā laikā acīmredzami ir saskārusies, ir - vispirms tas bija tas, ka visi uzslidināja vai pārslēdzās uz virtuālajiem automātiem. Un tagad mums ir daudz cilvēku, kas dodas mākoņa virzienā. Un ir arī daudz jautājumu, kas rodas ap šiem lietu veidiem. Vai man ir jēga pāriet uz mākoni? Vai es ietaupīšu naudu, pārejot uz mākoni? Cik daudz naudas es varu ietaupīt, ja man šīs lietas tiktu ievietotas virtuālajā mašīnā, dalītu resursu mašīnā. Acīmredzot arī šāda veida jautājumi tiks izvirzīti. Tātad, paturot prātā daudz šo lietu, kopā ar Diagnostic Manager mēs varam pievienot un izvilkt no virtualizētās vides gan VMware, gan Hyper-V. Mēs varam arī pievienot gadījumus, kas atrodas ārpus mākoņa, tāpēc jūsu vidē, piemēram, Azure DB, vai pat RDS, mēs varam arī iegūt metriku no šīm vidēm.
Tātad ir daudz elastības un daudz iespēju atbildēt uz šiem jautājumiem, jo tie attiecas uz citiem apkārtējās vides veidiem, pie kuriem mēs redzam cilvēkus dodamies. Un joprojām ir daudz jautājumu par šo saturu, un, tā kā mēs redzam, ka cilvēki konsolidē šo vidi, viņiem būs jāspēj atbildēt arī uz šiem jautājumiem. Tātad, tas ir diezgan labs pārskats, es teiktu, par Diagnostic Manager, jo tas attiecas uz šo tēmu. Es zinu, ka biznesa inteliģences tēma tika izvirzīta, un mums ir arī biznesa inteliģences rīks, par kuru mēs šodien nerunājām, bet tas arī sniegs jums ieskatu atbildē uz šāda veida jautājumiem, jo tie attiecas uz jūsu klucīšiem un arī visas šīs atšķirīgās lietas. Bet, cerams, tas ir labs pārskats, vismaz attiecībā uz to, kā šis produkts var palīdzēt, izstrādājot labu plānu.
Ēriks Kavanaghs: Labi, labas lietas. Jā, es to izmetīšu Rikam, ja viņš joprojām tur atrodas. Rik, vai tev ir kādi jautājumi?
Riks Šermens: Jā, tātad vispirms tas ir lieliski, man tas patīk. Īpaši man patīk, ka tas sniedzas līdz VM un mākoņiem. Es redzu, ka daudz lietotņu izstrādātāju domā, ka, ja tas atrodas mākonī, viņiem tas nav jāpielāgo. Tātad -
Bullett Manale: Pareizi, mums par to joprojām ir jāmaksā, vai ne? Jums joprojām ir jāmaksā par visu, ko cilvēki uzliek mākonim, tāpēc, ja tā slikti darbojas vai ja tas izraisa daudz CPU ciklu, jums ir jāmaksā vairāk naudas, tātad nē, jums joprojām ir jāmēra šo lietu, absolūti.
Riks Šermens: Jā, es mākonī redzēju daudz sliktu zīmējumu. Es gribēju jautāt, vai šis produkts arī tiks izmantots - es zinu, ka jūs pieminējāt BI produktu un jums ir daudz citu produktu, kas mijiedarbojas viens ar otru - bet vai jūs sāktu aplūkot SQL veiktspēju, atsevišķus vaicājumus šajā rīkā? Vai arī tam tiktu izmantoti citi rīki?
Bullett Manale: Nē, tas būtu absolūti. Tā ir viena no lietām, ko es neattiecos un es to domāju, ir tās daļa no jautājumiem. Vaicājuma veiktspējas identificēšanai ir daudz dažādu veidu, neatkarīgi no tā, vai tas ir saistīts ar, jo īpaši, kas gaida, kā mēs redzam šeit šajā skatā, vai arī tas, vai tas ir saistīts ar vaicājumu resursu patēriņu kopumā, ir vesela virkne veidu, kā mēs varam analizēt vaicājumu izpildījums. Neatkarīgi no tā, vai tā ilgums, CPU, I / O un vēlreiz mēs varam aplūkot arī pašas darba slodzes, lai sniegtu nelielu ieskatu. Mēs varam sniegt ieteikumus analīzes sadaļā, un mums ir arī tīmekļa versija, kas sniedz informāciju par pašiem jautājumiem. Tātad es varu saņemt ieteikumus par trūkstošajiem indeksiem un spēju apskatīt izpildes plānu un visu šāda veida saturu; tā arī spēja. Tātad, absolūti, mēs varam diagnosticēt pieprasījumus septiņos veidos līdz svētdienai (smejas) un spēt sniegt šo ieskatu nāvessodu skaita ziņā, neatkarīgi no tā, vai tas ir resursu patēriņš, gaidījumi, ilgums un viss, kas labs.
Riks Šermens: Labi, lieliski. Un kā tad ir slodze pašām instancēm ar visu šo uzraudzību?
Bullett Manale: Tas ir labs jautājums. Izaicinājums, atbildot uz šo jautājumu, ir, vai tas ir atkarīgs, tāpat kā jebkas cits. Liela daļa no tā, ko mūsu rīks var piedāvāt, tas nodrošina elastību, un daļa no šī elastīguma ir arī tā, ka jūs saņemsit, lai pateiktu, ko vākt un ko nevākt. Tā, piemēram, attiecībā uz pašiem jautājumiem man nav jāapkopo informācija par gaidīšanu, vai es to varu. Es varu apkopot informāciju, kas saistīta ar vaicājumiem, kuru izpildes laiks pārsniedz laiku. Tā piemērs, ja es iedziļinātos konfigurācijas vaicājuma monitorā un teiktu: “Ļaujim mainīt šo vērtību uz nulli”, realitāte ir tāda, ka tas principā liek rīkam apkopot katru izpildīto vaicājumu, un tas tiešām nav Gars, kāpēc tas tur ir, bet vispārīgi runājot, ja es gribētu sniegt pilnu datu paraugu par visiem jautājumiem, es to varētu izdarīt.
Tātad, tas ir ļoti relatīvi salīdzinājumā ar jūsu iestatījumiem, kas parasti ir ārpus izvēles. Tas ir apmēram no 1–3 procentiem virs galvas, bet ir arī citi nosacījumi, kas tiks piemēroti. Tas ir atkarīgs arī no tā, cik daudz ostas vaicājumu darbojas jūsu vidē, vai ne? Tas ir atkarīgs arī no šo vaicājumu savākšanas metodes un no tā, kāda SQL versija tā ir. Tā, piemēram, SQL Server 2005, nevarēs izrauties no izvērstiem notikumiem, turpretim mēs to darīsim no pēdām. Tātad, tas būtu mazliet savādāk attiecībā uz to, kā mēs ejam, vācot šos datus, bet tas teica, tāpat kā es teicu, ka mēs, domājams, esam bijuši aptuveni kopš 2004. gada ar šo produktu. Tas ir bijis ilgs laiks, mēs esam ieguvuši tūkstošiem klientu, tāpēc pēdējais, ko mēs vēlamies darīt, ir veiktspējas uzraudzības rīks, kas rada darbības problēmas (smejas). Un tāpēc mēs cenšamies pēc iespējas izvairīties no tā, bet vispārīgi runājot, piemēram, apmēram 1–3 procenti ir labs īkšķa noteikums.
Riks Šermens: Labi, un tas ir diezgan zems, tāpēc tas ir drausmīgs.
Ēriks Kavanaghs: Labi. Robin, vai tev ir kādi jautājumi?
Robins Bloors: Es atvainojos, es biju kluss. Jums ir vairāku datu bāzu iespējas, un es esmu ieinteresēts, kāpēc varat apskatīt vairākas datu bāzes, un tāpēc jūs varat zināt, ka lielāka resursu bāze, iespējams, ir sadalīta starp dažādām virtuālajām mašīnām un tā tālāk un tā tālāk. Mani interesē, kā cilvēki to faktiski izmanto. Mani interesē, ko klienti ar to nodarbojas. Tā kā tas izskatās no manis, labi, protams, kad es kaut ko darīju par datu bāzēm, kaut ko tādu, kas man nekad nebija pa rokai. Un es vienmēr kādreiz izskatītu vienu gadījumu jebkādā jēgpilnā veidā. Tātad, kā cilvēki to izmanto?
Bullett Manale: Vispār runājot, jūs vispār runājat tikai par pašu rīku? Kā viņi to izmanto? Es vispār domāju par to, ka tam var būt centrālais vides klātbūtnes punkts. Ja jums ir miers un zināt: ja viņi skatās uz ekrānu un redz zaļu krāsu, viņi zina, ka viss ir labi. Tā ir tad, kad rodas problēmas, un acīmredzot lielākajā daļā gadījumu no DBA viedokļa, daudzas reizes šīs problēmas rodas, kad tās atrodas konsoles priekšā, tāpēc par tām var tikt paziņots, tiklīdz problēma ir parādījusies. Bet papildus tam, ka ir iespējams saprast, kad problēma rodas, spēt pievērsties informācijai, kas viņiem sniedz zināmas neskaidrības, kāpēc tā notiek. Un tas, manuprāt, ir lielākā daļa: būt aktīviem pret to, nevis reaģēt.
Lielākā daļa DBA, ar kurām es runāju - un es nezinu, to ir diezgan daudz - diemžēl joprojām atrodas reaģējošā vidē; viņi gaida, kad patērētājs pieiet pie viņiem, lai pateiktu viņiem šo problēmu. Tātad, mēs redzam, ka daudzi cilvēki mēģina no tā atkāpties, un es domāju, ka liela daļa no iemesla, kāpēc cilvēkiem patīk šis rīks, ir tas, ka tas palīdz viņiem būt proaktīviem, bet arī sniedz viņiem ieskatu notiekošajā. , kas saistīta ar problēmu, bet daudzos gadījumos tas, ko mēs vismaz atrodam - un varbūt tikai to, ka mums to saka DBA, - bet DBA, uztvere vienmēr ir viņu problēma, pat ja lietojumprogrammas izstrādātājs, kurš rakstīja pieteikumu kas to nav pareizi uzrakstījuši, viņi paši vainīgi, tāpēc viņi lieto šo lietojumprogrammu savās sistēmās vai serveros, un, kad veiktspēja ir slikta, visi norāda uz DBA: “Hei, tā ir jūsu vaina”.
Tātad šis rīks daudzkārt tiks izmantots, lai palīdzētu DBA pateikt: “Hei, šī ir problēma, un tā nav es.” (Smejas) Mums ir uzlabojiet to neatkarīgi no tā, vai tas ir vaicājumu mainīšana vai kāds tas varētu būt. Dažos gadījumos viņu atbildība samazināsies, taču vismaz ir rīks, kas viņiem palīdzētu to saprast un zināt, un savlaicīgi to darīt, acīmredzami, ir ideāla pieeja.
Robins Bloors: Jā, vairums vietņu, ar kurām esmu iepazinies, bet ir pagājis kāds laiks, kopš es tur esmu bijis ārpus mājas, apskatot dažādas vairāku datu bāzu vietnes, taču lielākoties tas, ko es mēdzu atrast, bija tas, ka būs DBA, kas koncentrējas uz nelielu datu bāzes. Un tās būtu datu bāzes, ja tās kādreiz samazinātos, tā būtu patiesi liela problēma biznesam utt. Un tā tālāk. Un citi, viņi ik pa laikam tikai apkopos statistiku, lai redzētu, ka viņiem vairs nav vietas, un viņi tos nekad neskatās. Un, kamēr jūs darījāt demonstrāciju, es to skatījos un domāju, ka tādā vai citādā veidā jūs domājat, jūs paplašināt, vienkārši nodrošinot kaut ko līdzīgu datu bāzēm, par kurām bieži neviens netika pārāk rūpējies, jo tām ir datu izaugsme , reizēm ir arī lietojumprogrammu pieaugums. Jūs paplašināt DBA pārklājumu diezgan dramatiskā veidā. Tātad, jautājums, kas īsti ir par šo jautājumu, ir tas, ka ar tādu rīku komplektu kā šis jūs galu galā spējat diezgan daudz sniegt DBA pakalpojumu katrai datu bāzei, kas atrodas korporatīvajā tīklā?
Bullett Manale: Protams, es domāju, ka izaicinājums ir tāds, ka tas, kā jūs diezgan daiļrunīgi teicāt, ir tāds pats kā dažām datu bāzēm, kas rūp DBA, un pēc tam tām ir arī tikpat daudz. Un tas, kā šis konkrētais produkts, tā licencēšana notiek uz gadījuma pamata. Tātad, es domāju, jūs teiksit, ir slieksnis, kad cilvēki izlemj: “Ei, tas nav pietiekami kritisks piemērs, ka es vēlos to pārvaldīt ar šo rīku.” Tas nozīmē, ka ir arī citi rīki, kas mums ir, vairāk , Es domāju, ēdināšana ar tiem mazāk svarīgajiem SQL gadījumiem. Viens no tiem būtu līdzīgs krājumu pārvaldniekam, kurā mēs veicam vieglas veselības pārbaudes attiecībā uz gadījumiem, bet papildus tam, ko mēs darām, mēs arī atklājam, tāpēc mēs identificējam jaunus gadījumus, kas ir ievietoti tiešsaistē, un pēc tam no šī brīža kā DBA es varu teikt: “Labi, šeit ir jauns SQL piemērs, tagad tas ir Express? Vai tā ir bezmaksas versija, vai arī tā ir uzņēmuma versija? ”Tas, iespējams, ir jautājums, ko es vēlos sev uzdot, bet, otrkārt, cik svarīga šī instance ir man? Ja tas nav tik svarīgi, man varētu būt, ka šis rīks iziet un to dara, vispārējs, ko es saucu par vispārēju veselības pārbaudi tādā nozīmē, ka tie ir elementāri lietu veidi, kas man rūp kā DBA: Vai disks piepildās? Vai serveris reaģē uz problēmām? Galvenās lietas, vai ne?
Kamēr Diagnostic Manager bija rīks, kuru es jums tikko parādīju, tas nonāks vaicājuma līmenī, tas nokļūs indeksu ieteikumos, apskatot izpildes plānu un visu šo labo, turpretī tas galvenokārt ir koncentrēts kam pieder kas, kas man pieder un kas par to atbild? Kādas servisa pakotnes un karstie labojumi man ir? Un vai mani serveri darbojas ar galvenajām sastāvdaļām, kuras es uzskatu par veselīgu SQL gadījumu? Tātad, lai atbildētu uz jūsu jautājumu, ir mazliet sajaukums. Kad mums ir cilvēki, kas skata šo rīku, viņi parasti aplūko kritiskāku gadījumu kopumu. Tas nozīmē, ka mums ir daži ļaudis, kas pērk katru viņu lietu un pārvalda to, tāpēc tas vienkārši ir atkarīgs. Bet kopumā es jums saku, ka noteikti ir slieksnis tiem ļaudīm, kuri uzskata, ka viņu vide ir pietiekami svarīga, lai viņiem būtu tāds rīks, kā pārvaldīt šos gadījumus.
Robins Bloors: Labi, vēl viens jautājums, pirms es to nododu Ērikam. Iespaids, kāds rodas, tikai skatoties nozari, ir tāds, ka datu bāzēm joprojām ir dzīve, bet visi dati tiek ielikti visos šajos datu ezeros un tā tālāk un tā tālāk. Tas ir patiesi, un hype nekad neatspoguļo realitāti, tāpēc mani interesē, kāda realitāte jūs tur uztverat? Vai organizācijas ir svarīgas datu bāzes, vai tās piedzīvo tradicionālo datu pieaugumu, ko es mēdzu domāt par 10 procentiem gadā? Vai arī viņi aug vairāk? Vai lieli dati padara šīs datu bāzes par balonu? Kāda ir bilde, ko redzat?
Bullett Manale: Es domāju, ka daudzos gadījumos daži dati tika pārvietoti uz citiem segmentiem, kur tam ir lielāka jēga, kad ir pieejamas citas tehnoloģijas. Kā nesen, daži no lielākiem datiem. Bet šīs datu bāzes, es teiktu, daudzos gadījumos ir grūti vispārināt, jo visi ir mazliet atšķirīgi. Tomēr kopumā es redzu zināmas atšķirības. Es redzu, kā es teicu, ka cilvēki daudzos gadījumos pāriet uz elastīgajiem modeļiem, jo viņi vēlas palielināt resursus, nevis tik daudz citās jomās. Daži ļaudis pāriet pie lieliem datiem. Bet to, kā jūs sakāt, ir grūti uztvert, jo parasti cilvēkiem, ar kuriem runāju, ir tradicionālās datu bāzes un viņi to izmanto SQL Server vidē.
Es teiktu, ka, runājot par pašu SQL, es joprojām domāju, ka tā iegūs tirgus daļu. Un es domāju, ka ļoti daudz cilvēku, kas joprojām virzās uz SQL no citām vietām, piemēram, Oracle, jo tas ir pieejamāks un šķiet acīmredzami, jo SQL versijas kļūst modernākas - un jūs to redzat ar jaunākajām lietām, kas notiek attiecībā uz SQL attiecībā uz šifrēšanu un visām pārējām iespējām, kas to padara par vidi vai datu bāzes platformu - tas, acīmredzot, ir ļoti svarīgs misijai, es domāju. Tāpēc es domāju, ka to redzēju arī mēs. Kur jūs redzat maiņu, tā joprojām notiek. Es domāju, ka tas notika pirms 10 gadiem, es domāju, ka tas joprojām notiek saistībā ar SQL Server, kur aug vide un pieaug tirgus daļa.
Robins Bloors: Labi, Ēriks, es pieņemu, ka auditorijai ir jautājums vai divi?
Ēriks Kavanaghs: Jā, ļaujiet man ātri uzmest jums vienu. Tas patiesībā ir diezgan labs jautājums. Viens no klātesošajiem jautā: vai šis rīks man pateiks, vai tabulā var būt nepieciešams indekss, lai paātrinātu vaicājumu? Ja jā, vai varat parādīt piemēru?
Bullett Manale: Jā, tāpēc es nezinu, vai man ir kāds īpašs indeksa pievienošanai, bet jūs varat redzēt šeit, mums šeit ir sadrumstalotības ieteikumi. Es arī vienkārši uzskatu, ka mums tikko bija, un šī bija daļa no diagnostikas pārvaldnieka, kas piedāvā tīmekļa versiju, kurā man teikts, ka man trūkst indeksa. Mēs varam apskatīt šos ieteikumus un, izmantojot indeksāciju, šo informāciju var pateikt par potenciālo ieguvumu. Otra lieta, kas man tikai jāpiemin, ir tā, ka tad, kad mēs izdarīsim ieteikumus, daudziem no tiem skripts tiks izveidots tam. Tas nav labs piemērs, bet jūs varētu redzēt, jā, situācijas, kad indekss - vai nu indeksa dublikāts, vai indeksa pievienošana - uzlabotu veiktspēju, un, kā es teicu iepriekš, mēs darām daudz ka ar hipotētiskas indeksa analīzes palīdzību. Tātad tas patiešām palīdz izprast darba slodzi, lai spētu to piemērot ieteikumam.
Ēriks Kavanaghs: Tas ir lieliski sīkumi, un tas man sniegs labu segu ar pēdējiem komentāriem šeit. Arī Robins, es un Riks esam dzirdējuši daudzus gadus, un viņi runā par datu bāzu pašregulēšanu. Tā ir pašregulējoša datu bāze! Viss, ko es jums varu pateikt, ir: neticiet viņiem.
Bullett Manale: Neticu hype.
Ēriks Kavanaghs: Var būt dažas mazas lietas, kas tiek paveiktas dinamiski, bet pat to, iespējams, vēlēsities to pārbaudīt un pārliecināties, ka tā nedara kaut ko tādu, ko nevēlaties darīt. Tātad diezgan ilgu laiku vajadzēja tādus rīkus kā šis, lai saprastu, kas notiek datu bāzes līmenī, un, kā teica Robins, datu ezeri ir aizraujoši jēdzieni, taču, iespējams, ir tikpat liela iespēja tos pārņemt, jo pastāv Loch Ness briesmonis jebkurā tuvākajā laikā. Tātad, es tikai vēlreiz teiktu, ka reālajā pasaulē ir daudz datu bāzu tehnoloģijas, mums ir nepieciešami cilvēki, DBA, lai apskatītu šo saturu un to sintezētu. Varat pateikt, jums jāzina, ko jūs darāt, lai šie materiāli darbotos. Bet jums ir nepieciešami rīki, lai sniegtu jums informāciju, lai zināt, ko jūs darāt. Rezultātā DBAs veiksies tikai lieliski.
Un liels paldies Bullett Manale un mūsu draugiem IDERA. Un, protams, Riks Šermens un Robins Bloors. Mēs arhivējam visas šīs tīmekļa pārraides, tāpēc, lai iegūtu papildinformāciju par visu to, ceram tiešsaistē insideanalysis.com vai mūsu partneru vietnei www.techopedia.com.
Un ar to labi atvadieties, ļaudis. Vēlreiz paldies, arī nākamreiz ar jums runāsim. Rūpēties. Labdien!