Satura rādītājs:
Autors: Techopedia Staff, 2016. gada 9. maijs
Takeaway: Uzņēmējs Ēriks Kavanaghs intervē Marku Madsenu, Dezu Blanšfīldu un Bulletu Manālu par latentumu un sniegumu.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Techopedia satura partneris
Techopedia darbinieki ir saistīti ar Bloor Group, un ar viņiem var sazināties, izmantojot labās puses iespējas. Lai uzzinātu vairāk par to, kā mēs strādājam ar nozares partneriem, noklikšķiniet šeit.- Profils
- Vietne
Ēriks Kavanagh: dāmas un kungi, sveicināti un vēlreiz sveicam Hot Hot Technologies! Jā, patiesi! Mans vārds ir Ēriks Kavanaghs, šī ir mūsu Hot Tech izrāde, sadarbība ar mūsu labiem draugiem no Techopedia. Pārliecinieties tiešsaistē uz Techopedia.com par jaunumiem plašajā uzņēmējdarbības tehnoloģiju jomā; tie, protams, aptver arī patērētāja lietas. Mēs savā programmā koncentrējamies uz uzņēmumu, tāpēc to mēs darīsim šodien.
Šeit ir informācija par jums patiesi un pietiekami daudz par mani, uzrakstiet mani uz čivināt @eric_kavanagh, es mīlu čivināt, es mīlu pārbaudīt šos materiālus, tas ir lielisks veids, kā uzturēt kontaktus ar cilvēkiem un labi sarunāties, kā arī vienreizēji. -vienas sarunas.
Ko tad mēs runājam? Šis gads ir karsts, tas ir viss iespēju klāsts, kuru mēs šodien aplūkojam informācijas pārvaldības pasaulē, un tas, par ko mēs šodien runājam, būs jautājumi, tas paātrinās vaicājumus.
Es domāju, ka es aizmirsu pieminēt virsrakstu “Performance Play: Say Goodbye to Latency”. Nu kurš gan vēlas latentumu? Neviens nevēlas latentumu, latentums ir tad, kad jūs tur sēdējat, noklikšķiniet uz pogas un gaidāt, kamēr kaut kas notiks, un neviens to nevēlas. Bērniem tas nepatīk, viņi neuzskata, ka tas ir forši, arī pieaugušajiem tas nepatīk. Mūs visus ir sabojājis tīmekļa ātrums, un mēs vēlamies lietas ātri, mēs vēlamies lietas tagad, un mēs šodien par to visu runāsim savā šovā.
Analītiķis Marks Madsens šodien ir kopā ar mums no Trešās dabas, viens no mūsu pastāvīgajiem darbiniekiem. Mūsu jaunais datu zinātnieks Dezs Blanšfīlds piezvana no Sidnejas, Austrālijas. Un tad Bullett Manale, jā, tiešām, tas ir viņa vārds, patiesībā tam vajadzētu būt diviem T. Bullett Manale ir mūsu viesis no Idera, ļoti, ļoti interesanta uzņēmuma, kas veic daudz lietu. Es par viņiem jau zinu, no kuriem viens ir, ka viņi kādu laiku atpakaļ nopirka uzņēmumu ar nosaukumu Precise. Es zināju, ka viņu izpilddirektors vārdā Zohar Gilad, kā tas ir vārdam? Viņš bija viens gudrs puisis.
Bet ļaudīm, jums ir nozīmīga loma šajā tīmekļa pārraidē uzdotajos jautājumos, tāpēc, lūdzu, nekautrējieties, sūtiet savus jautājumus jebkurā laikā - jūs to varētu darīt, izmantojot tīmekļa apraides konsoles jautājumu un atbilžu veidu, kas atrodas turpat labajā apakšējā stūrī. Jūs varat arī tērzēt ar mani, un es tērzēšu to runātājiem. Mums jau ir kāds, kurš zvana no Itālijas, tāpēc: “Ciao, ciao. Nāc staigā? ”Labi, ka ar to es stumšu Marka pirmo līniju, es nodošu klāju Markam. Atzīmējiet, jums tagad ir WebEx. Atņemiet to, grīda ir jūsu.
Marks Madsens: Paldies, Ēriks. Es tomēr nesākšu sākties pa vidu, sākšu sākumā. Tātad tikai daži komentāri, lai sāktu diskusiju ar Dez un Idera, sava veida valsts stāvokli ar attīstību, kā arī datu bāzēm un operācijām. Un jūs zināt: ja jūs to aplūkojat, mums datubāzu un lietojumprogrammu tirgū joprojām pastāv šādas divu pasaules problēmu problēmas, jo izstrādātāji uzskata DBA par cilvēkiem, kuri tos apgrūtina. Jums ir jāveido datu modeļi, jums nevar piekļūt tam, jūs nevarat izveidot šo lietu, jūs nevarat ievietot indeksu katras datu bāzes katras tabulas kolonnā, lai padarītu to ātrāku. Un, protams, kāpēc mums ir nepieciešami modeļi? Tas ir tikai datu struktūras, ja mēs tās mainām, vai jūs nevarat tās vienkārši izrakstīt sērijveidā?
Problēma ir tā, ka izstrādātāji zina kodu un lietojumprogrammas, bet divas lietas, kuras viņi bieži nezina, ir vienlaicīgums, vienlaicīga programmēšana un datu bāzes un zem tām esošās operētājsistēmas. Tā kā esmu bijis kodola izstrādātājs un operētājsistēmas un datu bāzes, es varu teikt, ka vienlaicība un paralēlisms ir patiešām grūti, un tāpēc daudzas lietas, kuras jūs iemācāties iegūt labu veiktspēju no sava koda, patiešām sāk izjukt, kad esat darbs ar datu bāzi. Un veiktspēja izskatās lieliski, testa vide izskatās lieliski, un Q & A vide, un tad tā nonāk reālajā sistēmā, un tad pēkšņi tā nav tik lieliska. Tā kā tas ir daudzšķautņains, kā kods darbojas ar datu bāzi, kā tas darbojas ar vidi, un patiešām vienkāršai, mazai praksei var būt drastiskas sekas atkarībā no tā, kuru mērogu izmantojat.
Un, kad jūs sākat runāt par ārējām lietojumprogrammām, protams, ārēji vērstas lietojumprogrammas, tīmekļa lietojumprogrammas, var būt patiešām sarežģītas, jo lietas ir lieliskas, līdz pēkšņi tās izlīdzinās, un tās nav. Jūs sasniegsiet šos interesantos plakanumus, kuru izpratnei ir nepieciešams daudz nianšu.
Liela daļa ir DBA skats. DBA uzskata, ka ir operācijas, kuras lielāko daļu laika - 80 līdz 90 procentus - pavada operācijās un, iespējams, 10 līdz 20 procentus, nodarbojoties ar attīstības jautājumiem, kas notiek sākumā. Raugoties no šī viedokļa, jūs maksājat tagad vai maksājat vēlāk, un, ja visu laiku tērējat iepriekš, tad vēlāk jums būs daudz lielākas iespējas, nevis attīstībai, kurai ir tendence izpētīt kādu funkciju un mēģinot izdomāt, kā vislabāk rīkoties. Tāpēc mums ir problēmas, un tagad mums ir nesavienojamas metodoloģijas - pastāvīga izvietošana, jūsu lietotņu apkopošana, kad vien tās ir gatavas, periodiski veic koda nospiešanu, strādā veikalā, kas praktizē izstrādājumus. Šāda veida lietas paātrina attīstību, taču visas prakses, kas saistītas ar datu bāzi, un tas, ko dara DBA un kādi sistēmu vadītāji ir apmācīti, IT operāciju prakse nav turējusies kopsolī.
Ja padomājat par to, vairums DBA darbojas pārmaiņu kontroles vidē, salīdzinot ar nepārtrauktu izvietošanas vidi. Tas viss ir saistīts ar stabilitāti un kontroli, salīdzinot ar pārmaiņu ātrumu un atgriezeniskumu. Nepārtraukta izvietošana, ja nevarat atgriezties no izmaiņām, jūs esat nonācis grūtībās, tāpēc viss ir jāveido tā, lai tas būtu viegli atgriezenisks un pārslēdzams ar kodu, kas ļoti nedarbojas kā relāciju datu bāze, attīstības prakse un pārvaldības prakse. .
Jūs arī saskaraties ar šīm problēmām, kurām jābūt aktīvākām, ja varat, kā DBA, jo līdz brīdim, kad dzirdat par problēmu, simts tūkstoši cilvēku jūsu vietnē aizpilda sūdzību veidlapas. Tas nozīmē, ka jums būs vajadzīgas dažas jaunas lietas, kuras neizkļūsit no vecās vides. Jūs zināt, tādas lietas kā labāka uzraudzība un brīdināšana. Tajā pašā laikā datu bāzes ir reizinājušās, un mums ir vairāk lietojumprogrammu nekā jebkad, lai atbalstītu vairāk lietu nekā jebkad, tās ir iekšpusē, ārpusē, visur. Neatkarīgākos datu kopus analīzei cilvēki sāk izveidot datu bāzes, jo, protams, tagad tas ir vienkārši, jūs varat iestatīt virtuālo mašīnu. Ja jums ir mākoņa pakalpojumu sniedzējs vai iekšējs mākonis, varat tūlīt uznirst, un tas maina visu jūsu iepirkuma ceļu.
Vecais iepirkuma ceļš bija: “Man ir laiks iegūt serveri, ievietot to statīvā, atdalīt vietu, iegūt krātuvi, sakārtot datu bāzi un veikt lietas”, salīdzinot ar to, ka kāds notver kredītkarti un dodas piecās minūtēs. Ja jūs to darāt, šī modernā attīstības vide darbojas ļoti atšķirīgā tempā, tāpēc ir viegli izveidot datu bāzes, un tas tikai rada šo izplatīšanās problēmu, tāpat kā nekas cits, ko mēs iepriekš esam redzējuši. Un tas notiek jau desmit gadus, tas nav jaunums nevienam, bet tas nozīmē arī to, ka darbības vide ir kļuvusi sarežģītāka.
Visa klienta servera vide ir patiešām mainījusies, jo tā vairs nav klienta servera pasaule. Toreiz jums bija serveris, jums bija datu bāze, ja kaut kas nebija kārtībā, jūs zinājāt, uz kuru serveri doties, jūs zināt, kā pārvaldīt tajā esošos resursus, jo labākā prakse bija viena datu bāze, viens serveris. Virtualizācija sāka to sadalīt, mākonis to sagrauj vēl vairāk, jo tas, kas, jūsuprāt, ir datu bāzes serveris, ir tikai programmatūra. Tātad vide nav īsta. Tas, kas satur vidi, ir realitāte, un tas, iespējams, ir asmeņu plaukts vai liels serveris, kas sadalīts gabalos, jūs īsti nezināt.
Viss, kas saistīts ar datu bāzu administrēšanu un veiktspējas pārvaldību, kā arī tas, kuras datu bāzes ir veidotas, balstoties uz stingru kontroli ar vienu serveri vai nedaudziem serveriem un pāris datu bāzēm, visu nevar kontrolēt. Jūs sēdējat mašīnā, bet joslas platumu virtuālie vadītāji nevar viegli sadalīt, tāpēc ar atmiņu un centrālo procesoru viss var būt kārtībā, taču jums ir trūkumi resursos, kurus nevar izskatīt, un tad kad jūs mēģināt to labot, vecais modelis būtu bijis smags darbs, iegūstot lielāku serveri un kaut ko līdzīgu darot, tagad tas varētu būt patiešām vienkāršs, vienkārši pievienojiet virtuālo kursu, vienkārši pievienojiet atmiņu VM, un tas ir atrisināts. Bet kas notiek, ja jūsu VM atrodas pārpildītā serverī un ir nepieciešams to migrēt? Vai kas notiek, ja jūs esat AWS sistēmas lielumā un esat sasniedzis maksimālo lielumu, tagad kur jūs dodaties?
Tātad jums ir visas šīs problēmas, kurās vide tagad ir daļa no datu bāzes, jūs iesaiņojat vidi ar datu bāzi, visiem speciālajiem resursiem, visu lietojumprogrammā, kas ir daļa no konfigurācijas, konfigurācija tiek tur izstumta. Tas ir no datu bāzes vides, to ir daudz grūtāk pārvaldīt un kontrolēt.
Ja paskatās, ko dara datu bāzu centri, viņi ir sēdējuši uz rokām, vai ne? Mēs esam attālinājušies no idejas izturēties pret datu bāzēm un serveriem kā pret mājdzīvniekiem. Kalpotājiem ir vārdi, jūs izturaties pret viņiem tā, it kā viņi būtu individuāli unikāli, pret viņiem izturaties kā pret liellopiem, tas pārvalda ganāmpulku. Ganāmpulku pārvaldīšanas problēma ir tāda, ka, ja jūs tos nekontrolējat, tie galu galā var satraukties, un satraukšana nav laba lieta. Mums ir vajadzīgi labāki uzraudzības rīki, labāki veidi, kā rīkoties ar šo lietu, un jāzina, kas to ir ietekmējis. Vecajā modelī tas bija vieglāk, jo jūsu operētājsistēmas un visas jūsu vadības sistēmas jums to teica, bet, kad servera nosaukums ir UPC kods, to ir grūti izdomāt.
Jūs nevarat atļauties viltus brīdinājumus, nevarat atļauties lietas, kurās teikts: “Ar šo mašīnu ir problēma, un mašīna uztur 30 datu bāzes.” Jūs nevarat atļauties, ka lietām nav vēstures. Monitoringa konsoles ir lieliskas, kad tās iedegas, bet, ja sarkanā gaisma atkal kļūst zaļa un jūs nezināt, kāpēc, un jums nav vēstures, kurā atgriezties, lai apskatītu, kas noveda pie tā, un kas konteksts bija, jūs esat nepatikšanās. Mums ir vajadzīgas sistēmas, kuras uzraudzīs mūsu labā, mums ir nepieciešama labāka uzraudzība, risinot cirstīgās periodiskās problēmas, kas uztur šo datu vēsturi.
Labākas lietas un vienkārši metrikas sliekšņi, kas mums dod galveno metriku, bet tieši nepiedāvā mums to, kas ir parasts, kas ir neparasts un cik bieži rodas šīs problēmas. Tas, par ko mēs patiesībā runājam, ir uzraudzības vides apvienojums un darbība ar veiktspēju, un pārdevēji ir sēdējuši uz rokām. Viņi mums nav devuši labākus rīkus. Mums ir sistēmas ar lielāku CPU un atmiņu, nekā mēs zinām, ko ar to visu darīt, un tomēr mēs joprojām paļaujamies uz manuāliem iejaukšanās modeļiem, mēs neesam nolikuši mašīnu darbam, lai mūs vadītu, lai nonāktu problēmu vietā, mēs neesam tikuši pie šī jaunā stila, kas ir “Šeit ir problēma, jūs varat to izdarīt, lai labotu” vai “Šeit ir veiktspējas problēma, kas faktiski ir ar šo konkrēto SQL paziņojumu. Šeit ir trīs lietas, kuras jūs varētu izmantojiet, lai labotu šo SQL paziņojumu. ”Piemērojot heiristiku, izmantojot mašīnmācīšanās modeļus, kas var aplūkot jūsu sistēmas lietošanas modeļus, lai pamanītu problēmas un izvairītos no nepatiesiem brīdinājumiem. Izmantojot mašīnu, lai izdarītu to, ko mašīna dara vislabāk, lai palielinātu DBA vai palielinātu personu, kurai ir jārisina veiktspējas problēmas.
Tas ir jaunais veids, pretstatā vecajam stilam. Šajā datu bāzē ir problēma, lietas notiek lēni, un tāpēc mums ir jauni paņēmieni, jauni veidi, kā to izdarīt, un mums tie būtu jāpiemēro, un tieši tur virzās tirgus. Jūs redzat, ka tas sāk šķist nevis ar lielajiem pārdevējiem, bet gan ar trešo personu uzņēmumiem, un tas atspoguļo kaut ko tādu, kas notika pirms 20 gadiem, kad datu bāzes pārdevēji nesniedza vienu lietu, kas palīdzētu pārvaldīt sistēmas. Tātad tas ir tāds, kāds ir tirgus virziens, un līdz ar to es gribētu to atgriezt Ērikam.
Ēriks Kavanaghs: Labi, es to nodosim Dezam. Un Dez, atņem to, grīda ir tava.
Dez Blanchfield: Paldies, Marks. Jūs esat paveicis fantastisku darbu, aptverot tā tehnisko komponentu. Es pievērsīšos tam no nedaudz atšķirīga rakursa, lai uzsvērtu pārējā pasaulē notikušo, ciktāl tas ietekmē uzņēmējdarbību un apkārt esošās datu bāzes. Ļaujiet man tikai uzlēkt uz manu pirmo slaidu.
Tā kā jūs tikko esat apskatījis lietas lietu tehnisko un izstrādātāju pusi, es redzu, ka uzņēmumiem jāsaskaras ar datu un datu bāzu izaicinājumiem, un acīmredzot mums ir bijusi šī nozīmīgā pāreja uz šī lielo datu koncepcija, bet datu bāzes faktiski joprojām ir sirds un dvēsele tam, kur organizācijas saglabā savu biznesa informāciju, un tas notiek no ārdurvīm līdz pat aizmugures birojam. Katru organizācijas daļu aizskar kāda veida datu bāze, un to darbina datu bāze, un ļoti reti es iesaistos vai nu projekta diskusijās, vai kādā novatorisku stratēģisko sarunu formā organizācijā, kur datu bāzes vai datu bāzes sistēmas tēma tā nerodas, un vienmēr ir jautājumi par to, ko esam tikko dzirdējuši, par veiktspēju un drošību, kā arī par to, kā attīstība risina šo izaicinājumu, un kur piemērotas datu bāzes, kā arī mūsu apzinātās vides un lietojumprogrammas vides sarunāties, kā ir ar ierīcēm un mobilitāti?
Tas joprojām ir ļoti, ļoti karsts temats, un tas jau sen, ilgu laiku ir bijis plašajā lietu shēmā, ciktāl tas attiecas uz mūsdienu tehnoloģijām. Līdz šim es uzskatu, ka tas ir fakts, ka gandrīz viss, ko mēs darām mūsu ikdienas dzīvē, mūsu ikdienas dzīvē, tas ir, tagad tiek atbalstīts ar kāda veida datu bāzēm. Kad mēs domājam par visām mums apkārt esošajām lietām, neatkarīgi no tā, vai tas ir rēķins, kas katru dienu tiek piegādāts pa pastu par kādu pakalpojumu, kuru mēs pērkam, to neizbēgami izdrukā sistēma, kas runā ar datu bāzi, un mēs tur atrodamies. Mūsu tālruņos ir datu bāzes ar kontaktiem, zvanu žurnāliem un citām lietām.
Lai kur mēs dotos, aiz sarunām un mūsu izmantotajām sistēmām ir kāda veida datu bāze, un, visbiežāk, viņi mums ir diezgan caurspīdīgi, taču patiesība ir tāda, ka viņi tur atrodas. Tāpēc es domāju, ka es ātri uzzināšu, kāpēc tas ļoti īsā laika posmā ir kļuvis par nelielu problēmu. Sākumā datubāzes jēdzienu radīja šis jaukais kungs Edgars Kodds. Strādājot IBM, viņš mainīja pasauli, ciktāl tas attiecas uz datu pārvaldību, izveidojot koncepciju, kuru mēs tagad dēvējam par relāciju datu bāzi.
Sākumā datu bāze bija datu bāze, un dzīve bija laba, tā bija diezgan vienkārša gan slejās, gan atsaucēs un tā tālāk, gan tabulās, gan programmatūras izstrādē bija diezgan vienkārša, un veiktspēja patiesībā nebija tik liela problēma - tā bija jauna aizraujoša tehnoloģija. Mēs piekļāvām datu bāzēm, izmantojot kaut kādus termināļus, un tik lielu postu jūs varat radīt tikai lieldatoru 3270 termināļa beigās un vienmēr cita veida termināļiem - šīm citām sistēmām. Un vairumā gadījumu vecā stila termināļi bija ļoti līdzīgi tam, kāda ir pašreizējā tīmekļa vide, un tas ir, ja jūs aizpildāt veidlapu uz paša termināļa ekrāna un nospiediet taustiņu Enter un pēc tam, kad tas aiziet, tas atvašu kā vienu paciņu, kā pieprasījumu, un fona sistēma to risinātu. Tas ir tas, kas notiek tīmekļa pārlūkprogrammā šajās dienās, kad tīmekļa pārlūkprogrammā ierakstāt saiti un tādā formā tā parasti netiek atgriezta reāllaikā atpakaļ sistēmā, lai gan šajās dienās AJAX tas nav pilnībā lietu.
Bet tad kaut kas notika, nāca nākotne, pavisam nesen - internets, un gandrīz vakar - sec Web 2.0 un tepat ap stūri mēs izveidojām lietu internetu. Turpmākajā notikumu procesā datu bāzu pasaule ir tikko eksplodējusi, un mijiedarbība ar datu bāzēm vienkārši kļuva par lietu, ko mēs visi darījām pēc noklusējuma, nebija gadījuma, ka jūs dotos kaut kur kaut ko darīt, piemēram, pirkt lidmašīnas biļeti un vēlaties ceļot uz otru planētas pusi, kādam bija jāieraksta terminālī visa jūsu informācija un jāieiet datu bāzē un jāizdrukā biļete.
Gandrīz viss, ko mēs tagad darām, neatkarīgi no tā, vai tas ir kabīnes uzlikšana Google ar lietojumprogrammu, vai tas ir lēks internetbankā, viss, ko mēs darām ikdienā, ar kaut kādu sistēmu, to nodrošina datu bāze. Un, kad nāca internets, to bija mazliet vieglāk ienākt mums, izmantojot tīmekļa pārlūku, un tad pievienojās arī Web 2.0, un lietas kļuva mobilākas, un lietu mērogs vienkārši eksplodēja. Faktiski mana iecienītākā līnija šajā tēmā ir šāda: “Internets savienoja visu, Web 2.0 padarīja to mobilo un sabiedrisko, un lietas kļuva ļoti, ļoti lielas, un tagad mums ir internets un lietas, un IoT… Yikes !!” Mēs pat neesam sākuši iedomāties, kā lietiskais internets ietekmē pasauli datu bāzu sistēmās.
Tātad mūsdienu izteiksmē tas, par ko mēs parasti domājām kā termināli, ir faktiski kļuvis par šiem jautājumiem, tas ir mobilais tālrunis, tas ir dažāda veida planšetdators, vai nu personīgs patērētāja, vai uzņēmuma klases liela ekrāna planšetdators, tas ir klēpjdators un tā ir tradicionālā darbvirsma kaut kādā formā. Šajā vienā attēlā jūs varat redzēt gandrīz visas saskarnes formas, kuras mēs tagad izmantojam, lai sarunātos ar datu bāzu sistēmām un lietotnēm, kuras tos darbina, sākot ar mazajiem sīkrīkiem mūsu rokās, kas staigā un, šķiet, esam pielīmēti, visiem ceļš uz nedaudz lielākām versijām un iPad, kā arī citām planšetdatoriem un Microsoft Surface, līdz ikdienas klēpjdatoriem, kas vienmēr notiek profesionālajā vidē un tā tālāk. Cilvēki mēdz iegūt klēpjdatoru, nevis fiksētu darbvirsmu, taču, manuprāt, viņi ir modernais terminālis, un tas ir iemesls tam, ka datu bāzes mūsu dzīves pārvaldības jomā piedzīvo visa veida izaicinājumus, nevis tikai attīstību.
Tāpēc es pieņemu, ka tas ir viens no lielākajiem izaicinājumiem, ar kuriem uzņēmumi joprojām saskaras ikdienā. Visi domāja, ka datu bāzes ir mūsu vienīgās problēmas, un tās nav. Kas tad par visām satraukumiem? Ja mēs ejam no viena gala līdz otram ar visām lietām, kas saistītas ar datu bāzēm, no komerciālā viedokļa, un Marks ļoti labi ietvēra tehniskos komponentus, bet komerciālā nozīmē kā organizācija mēs domājam par datu bāzēm. Mēs strādājam ar lietām viscaur, sākot no pamata dizaina un attīstības priekšplāna. Kad bizness sāksies, viņi domās par lietojumprogrammu izstrādi, spēju attīstīšanu vai pat jau esošas lietojumprogrammas ieviešanu kaut kādā formā. Jānotiek kaut kādam izstrādes un attīstības veidam, un ir daudz jāpiedomā pie tā, kā šīs datu bāzu sistēmas tiks ieviestas, atbalstītas un pārvaldītas, kā arī izsekotas izsekojamības utt.
Datubāzes vides un lietojumprogrammu integrācija, kā arī API veidi, piekļuves veidi, kas tagad tiek nodrošināti, kļūst arvien sarežģītāki un sarežģītāki. Ikdienas administrēšana, atbalsts un rezerves kopijas atkal ir lietas, kuras mēs domājām atrisināt, bet tad pēkšņi mērogs kļuva daudz lielāks, un lietas pārvietojās ātrāk, un apjoms ir tik daudz lielāks; Vides lielumam, datu bāzu sistēmām bija jāatbalsta darījumu ātrums.
Padomājiet par datu bāzi ļoti, ļoti augstas frekvences tirdzniecības vidē, vienkārši nav tā, kā cilvēki to var izsekot. Tas ir tikai mašīnu kopums, kas cīnās ar citu mašīnu kopu, lai veiktu augstas frekvences tirdzniecību, pirkšanu un pārdošanu, kā arī apjomu kādi šie darījumi notiek. Padomājiet par mūsdienu scenāriju, piemēram, filmas Netflix agrīnu izlaišanu, kurā jūs nerunājat tikai par simtiem vai tūkstošiem vai pat simtiem tūkstošu, iespējams, miljoniem cilvēku, kas vēlas redzēt šo filmu jau no tās izdošanas brīža. Visa šī informācija tiek uztverta, izsekota, reģistrēta un analizēta datu bāzes platformā.
Un tad tur ir vienmēr ieslēgtā pasaule, kurā mēs tagad dzīvojam, visu diennakti, ne tikai sekojot Saulei, bet pusnaktī kāds vienmēr ir kaut kas vēlas kaut ko darīt, un darba laiks seko Saulei visā pasaulē. Tātad darbspējas laiks un pieejamība pēc noklusējuma ir klimats, jo apstādināšana patiešām nav pieņemama lieta. Un atlaišana, ja rodas veiktspējas problēma vai ja mums ir nepieciešams apkopes logs, lai veiktu jaunināšanu vai ielāpu, vai arī drošība, mums tiešām jāspēj pāriet no vienas datu bāzes vides uz citu un tas jādara nemanāmi un automātiski.
Drošība un standarti, kā arī atbilstība, vēlu pasaulē, īpaši GFC, ir notikušas dažas diezgan lielas lietas, un tāpēc mums ir virkne jaunu izaicinājumu, ar kuriem jāsaskaras, ievērojot atbilstību, drošību un atbilstošos standartus, un mums ir nepieciešams spēt ziņot par tiem reāllaikā un ideālā gadījumā paneļa formā. Mēs nevēlamies nosūtīt pērtiķu komandu uz datu centru, lai mēģinātu atrast lietas. Mums ir vajadzīga sistēma, kas to tūlīt, reālā laikā, mums paziņo.
Un tos divus lielos jautros, par kuriem gandrīz neviens nekad nerunā, mēs parasti tos spiežam zem paklāja un ceram, ka viņi nekad nepacels neglīto galvu, bet gan atjaunošanu pēc katastrofām un biznesa nepārtrauktību - arī šīm lietām vajadzētu būt, jo lielākoties notiek automātiski, ja rodas tāda nepieciešamība.
Mēs varētu pavadīt dienas, runājot par lietām, kas datu bāzu vidē var noiet greizi un uz kurām cilvēki parasti ir reaģējuši, bet tagad mums ir vajadzīgas sistēmas un rīki, lai to izdarītu mūsu labā. Viens piemērs ir datu pārkāpums, un tāpēc, domājot par datu bāzēm, es diezgan atklāti uzdodu šo jautājumu dažādās formās: kas notiek ar datu bāzēm, kad mēs noraujam acis, un kaut kas kritisks noiet greizi? Īpaši, ja nav sistēmas, kas novēro veiktspēju un drošību, kā arī citus svarīgus datu bāzu darbības aspektus.
Nu, kas varētu notikt, tas ir ekrānuzņēmums ar dažiem no nesenajiem pārkāpumiem pēdējos divos trīs gados. Vienmēr šie visi nāk no datu bāzes sistēmas, un vienmēr ir radusies kāda drošības vai kontroles vai piekļuves problēma, un augšējā kreisajā stūrī mēs skatāmies uz 152 miljoniem Adobe kontu, kur ir katra detaļa no šiem klientiem tika pārkāpts. Un, ja varētu būt bijuši piemēroti rīki negadījuma izsekošanai un tveršanai, kā arī drošības kontrolei, mēs varbūt dažus no tiem izvairījāmies, iespējams, ka pirmie pāris simti ierakstu, kas tika nozagti, mūs būtu brīdinājuši, un mums būtu pārtrauca nākamos simt piecdesmit miljonus.
Tad mēs nonākam pie visa šī ceļojuma galvenā punkta, kas mūs pārņēma, proti: kāpēc mums ir vajadzīgas labākas sistēmas? Kāpēc mēs nevaram vienkārši piemest vairāk ķermeņa šai lietai, ka, manuprāt, mēs esam labi un patiesi šķērsojuši izejas punktu, un es noteikti uzskatu, ka ir gadījums, kas pierādīts par vēlu, ka vairāk DBA, administratoru un vairāk cilvēku tiek izmesti šī lieta neatrisina problēmu. Mums ir vajadzīgs labāks instrumentu komplekts un labāks sistēmu komplekts.
Šie ir mani pieci galvenie iemesli, kuru dēļ es uzskatu, ka to atbalsta, un tie ir sarindoti svarīguma secībā, pamatojoties uz to, ko redzu šajos privātajos uzņēmumos un štatos, kurus pārvalda vide, izaicinājumiem, ar kuriem viņi saskaras ar datu bāzu vidēm, un pārvaldīt tos.
Drošība un atbilstība - numur viens. Jūs zināt, kontrolējot to, kam ir piekļuve, kur viņiem ir piekļuve, kad viņiem ir pieeja, cik bieži viņiem ir pieeja, no kurienes viņiem ir pieeja. Potenciāli ierīces, kurām viņi faktiski pieskārās, un to, kāda veida lietas viņi ir apskatījuši, kā arī atbilstība, kas ir ap to. Pēc tam, kad cilvēki pēc 30 dienām sagatavo ziņojumus, lai pastāstītu mums, vai viss ir kārtībā, vienkārši vairs nav piemērots, tam jānotiek reālajā laikā.
Veiktspēja un uzraudzība - šķiet, ka nav prāta, bet vienmēr tā nav. Neatkarīgi no tā, vai mēs izmantojam atvērtā pirmkoda rīkus vai kādus trešo pušu komerciālos rīkus, vienmēr daudzos veidos esam nokavējuši laivu ar nepieciešamajiem veiktspējas uzraudzības veidiem un nepieciešamo detaļu, kā arī spēju savlaicīgi reaģēt. .
Incidentu atklāšana un reaģēšana - tai ir jābūt tūlītējai reāllaika lietai, un vienmēr mums ir vajadzīga sistēma, lai to izdarītu mūsu labā vai vismaz mūs ātri brīdinātu, lai mēs varētu tikt galā ar to, lai tiktu risināti daži jautājumi, kas rodas. ātri un nekontrolējiet.
Pārvaldība un administrēšana - atkal mēs domājam, ka šīs problēmas ir atrisinātas, bet ne tās. Mērķis, lai problēmas risinātu datu bāzu komandas, jo īpaši DBA, kurās sistēmai vajadzētu rūpēties par mums pašiem, mēs šo problēmu vēl neesam atrisinājuši, tā joprojām ir reāla lieta.
Sākotnēji ar projektēšanu un attīstību, kad sākam veidot šos rīkus, mēs izveidojam datu bāzu vidi, spējam izmantot atbilstošos rīkus izstrādei un testēšanai, kā arī integrēt platformas. Tas joprojām nav viegli izdarāms, un viss šis ceļojums mūs virza pie viena un tā paša vēstījuma, ka, manuprāt, mums ir vajadzīgas labākas sistēmas un labāki rīki, kas mums palīdzētu sasniegt vajadzīgos rezultātus. mūsu datu bāzes vide, tātad uzņēmumi, kas palielina mūsu klientu vērtību. Mēs nevaram vienkārši turpināt mest vairāk ķermeņu un vairāk DBA, skala ir pārāk liela, ātrums ir pārāk ātrs un skaļums ir pārāk liels. Ar to Ēriks es varētu jums atgriezties.
Ēriks Kavanaghs: Es to mīlu, mums ir daudz zemes, kur ir cilvēki, daudz potenciālo potenciālo pircēju, un mēs dodamies uz priekšu un tikai vienā sekundē nododam viņiem atslēgas Bullett.
Bullett Manale: Labi.
Ēriks Kavanaghs: Ak, atņemsim to un Bullett, tagad es jums to nododu, un grīda ir jūsu.
Bullett Manale: Labi, paldies. Es domāju, ka ir izdarīts daudz labu punktu. Es gribēju tikai uz brīdi ātri runāt par Ideru, kas mēs esam, un tad mēs ielēksim iekšā. Es runāšu par rīku, par kuru, manuprāt, daudz šo lietu, par kuru mēs runājam, mēs varam veida un veida diskusijas par dažām jomām, kurās tās ar šo rīku sader kopā ar produktu Diagnostic Manager.
Tagad tas, ko es vispirms gribu darīt, ir tikai veids, kā sniegt jums nelielu fona informāciju par to, kas ir Idera; mēs esam bijuši aptuveni kopš 2003. gada, un tāpēc mēs esam sākuši tikai ar SQL Server rīkiem, un tas ir tas, uz ko mēs šodien koncentrēsimies, būtu Diagnostic Manager produkts. Bet jūs varat redzēt visus šeit esošos lietu spaiņus, un nesen, kā jau tika minēts iepriekš, mēs esam iegādājušies Precise un iegādājoties mums ir arī Embarcadero, un tāpēc mums ir diezgan labs produktu portfelis.
Runājot par veiktspējas uzraudzību, runājot par SQL Server, produkts, par kuru es gribu runāt, kas saskaņo šīs mūsu apspriestās tēmas, ir Diagnostic Manager. Tagad šis ir produkts, kas darbojas jau gandrīz tuvu Idera dienu sākumam, un man ir paveicies būt līdz šim apmēram kopš 2005. gada. Es esmu redzējis daudz izmaiņu attiecībā uz SQL Server, pāreja no fiziskā uz virtuālo, visa veida lietas, kas ir notikušas, kā arī DBA vajadzības, pieaugot videi, un šāda veida lietām.
Tas, ar ko es sāku, bija tas, ka mūsu produkta tipiskais lietotājs ir DBA, un tāpēc, kad mēs pirmo reizi runājam ar ļaudīm, potenciālajiem klientiem, tas galvenokārt ir DBA, ar kuriem mēs runājam. Mēs nerunājam ar IT vadītājiem vai direktoriem, tas kādā brīdī var sasniegt šo līmeni, bet sākotnējais sākums ir tāds, ka DBA ir problēma, DBA mēģina šo problēmu novērst, un daudzreiz mēs Es eju, lejupielādējot un izmēģinot produktu kā daļu no tā. Jūs vai nu saņemat datu pārvaldnieku, vai DBA, vai arī rīkojas DBA, puisis, kuram ir paveicies, ka dažos gadījumos telpā ir tehniskākais. Tagad, acīmredzot, kad jūs apmeklējat lielāku uzņēmumu vidi, jūs iegūsit pilnvērtīgas DBA, kas parasti būs tās, kuras izmanto šo rīku. Es devos uz priekšu un šeit tikai pievienoju nelielu izteicienu no Wikipedia. Kā saka Vikipēdija, tas, piemēram, pārsniedz DBA atbildību, to viņi arī dara.
Ja jūs šeit apskatīsit sarakstu ar daudzām šīm lietām, es to nelasīšu, bet jūs saņemat daudz tipisku lietu, par kurām jūs varētu domāt, un pēc tam vienā no tām esat uzraudzījis datu bāzes veiktspējas optimizēšana, un tas ir diezgan liels. Un kas ir interesanti, ir tas, ka, runājot ar DBA, viņi vienmēr ir tie, kas vispirms tiek vainoti, kad rodas problēmas, un tā, iespējams, nav īsti viņu vaina, bet, ja rodas veiktspējas problēma, parasti ar lietojumprogrammu, kas ir piesaistīts DBA datu bāzei, viņi vainīgi pie vainas, tāpēc viņi vienmēr meklē iemeslus, kāpēc tā nav viņu vaina. Daudzos gadījumos viņi var izmantot šo rīku Diagnostic Manager, lai palīdzētu viņiem to darīt.
Bet dienas beigās, ja datu bāze arī nedarbojas, tad daudzām citām lietām nav nozīmes, jūsu lietojumprogrammas nedarbojas, tad daudzām no tām nav nozīmes lietas. Pirmkārt un galvenokārt, mēs vēlamies, lai varētu pārliecināties, ka netiek mazināta lietotāju pieredze tā, kā mēs to zinām, tas ir kaut kas tāds, uz ko DBAs vienmēr tiecas. Un es domāju, ka, ja jūs veida izpētītu iemeslus, kāpēc cilvēki parasti pērk un izmanto SQL Diagnostic Manager produktu, tas ir viens no pirmajiem iemesliem, kas, iespējams, nav vissvarīgākais, ne pēdējais, ne mazākais, bet tas ir diezgan vienāds visā pasaulē, un atkarībā no tā, ar ko jūs runājat, šie iemesli, gandrīz vienmēr viens vai divi, vienmēr ir nepieciešami.
Bet pirmais ir tikai spēja iegūt centralizētu eksemplāru skatījumu kā SQL, kuru viņi pārvalda. Un smieklīgi ir tas, ka daudzos gadījumos, ja jūs jautājat DBA: “Cik gadījumu jūs pārvaldāt?”, Skaitlis mainās tik bieži, ka dažos gadījumos viņi nav īsti pārliecināti. Tātad jums ir nepieciešams kaut kas vairāk, nekā tikai spēja visu uz ekrāna. Jūs vēlaties iegūt šo informāciju, vēlaties to saprast, un tāpēc tā ir viena no lietām, kurai noteikti var palīdzēt Diagnostic Manager, - spēja sniegt jums šāda veida ieskatu vidē.
Un tas nav tikai skats uz vidi, bet arī uzskats, ka DBA, datu bāzes administratoram, tas ir ērti, un, ja vēlaties, tā ir konsole, kas ir orientēta uz DBA. Tas ir paredzēts datu bāzes administratoram. Tur ir daudz uzraudzības rīku, tur ir daudz veiktspējas rīku, bet, kā jau es teicu, dienas beigās DBA vēlas rīku, kas ir paredzēts DBA, jo tur ir daudz lietu, kas raksturīgas tieši tam, ko viņi dara viņu ikdienā.
Un ar to sakot, jums ir SCOM, jums ir HPF, visas šīs citas tehnoloģijas, taču viņi vēlas kaut ko īpašu, ko viņi dara. Es domāju, ka mēs šajā jomā varam palīdzēt ar šo produktu, jūs redzēsit, kad pēc tā nokļūsim tajā. Otra lieta, ko mēs redzam ar DBA, kas noteikti ir viena no lietām, uz kuru mēs pieskārāmies arī agrāk, ir tā, ka viņiem ir jāspēj acīmredzami redzēt, kas notiek, un viņiem jāspēj ielūkoties visā uzņēmumā un ziniet mieru, zinot, kas notiek. Bet tajā pašā laikā viņi tur nesēž un skatās uz konsolēm.
Atcerieties visus tos aizzīmju punktus, kurus jūs redzējāt šajā sarakstā, kurus es tikko uzvilku? Viņiem ir jādara arī šīs citas lietas, tāpēc tas nav tikai gaidīšana, kad tiks dzēsti ugunsgrēki. Daudzos gadījumos notiks sapulces vai daudzi ar datu bāzes administratoru saistītie uzturēšanas logi darbojas nakts vidū, kad viņi guļ, tāpēc viņiem ir jābūt iespējai atgriezties un redzēt notikušo. . Daudzos gadījumos, ja kaut ko neķerat, kad tas notiek, kad problēma ir novērsusies vai vismaz ar SQL Server, tā kļūst par sava veida problēmu, kurā jūs nodarbojaties ar situāciju, kad neveicat vai jums vairs nav šīs problēmas palieku. Šīs problēmas izzūd, tāpat kā paliekas, tas nozīmē, ka jums ir mazāk problēmu novēršanas, jums ir mazāk informācijas, ar kuru strādāt.
Ar šo teikto, tā noteikti ir viena no lietām, ar kuru var palīdzēt diagnostikas pārvaldnieks, ir dot jums šo skatu pagātnē, lai meklētu informāciju no pagātnes: “Vai man bija brīdinājums par bloķēšanu, vai man bija problēmas ar bloķēšanu, vai mums bija lietas, kas notika saistībā ar mūsu resursiem? ”Es varu atgriezties un vaicāt šo informāciju. Es varu iedziļināties noteiktos laika punktos. Es visas šīs lietas varētu izdarīt tieši no rīka.
Visas šīs lietas, neskatoties uz to, vai tā ir iekšēja vai ārēja lietojumprogramma, DBA vēlas zināt, jo viņi vēlas redzēt, kas rada problēmu. Nav īsti nozīmes tam, vai kodu ir uzrakstījis kāds organizācijas loceklis vai kāds ārpus organizācijas; viņi joprojām vēlas, lai varētu to izolēt, lai viņi zinātu, ka problēma notiek, un viņi zinātu, no kurienes tā rodas.
Tātad veiktspēja un atbildība ir mūsu produkta galvenā sastāvdaļa. Mēs varam sniegt visas šīs detaļas, un kas ir patīkami, vai jums ir iespējas to izskatīt. Ja ir sašaurinājums, varat to saistīt ar lietojumprogrammu, lietotāju, datu bāzi un vaicājumu. Un atkal tas ir sava veida smēķēšanas lielgabals. Jūs saņemat tiešu korelāciju starp šo vaicājumu, ko tas dara? Un tas attiecas ne tikai uz pašu vaicājumu, tā izpildi pats par sevi, bet arī ar to, vai laika gaitā vaicājums pasliktinās? Un uz šīm lietām var atbildēt arī ar produktu, kas noteikti ir kaut kas tāds, ka, ja jūs mēģināt būt proaktīvs, ir patīkami, ja varam pateikt: "Ei, lūk, vaicājums bija slikts, bet zēns to paskatās tā kā tas skrien tālāk, mēs redzam, ka tas darbojas vēl sliktāk un sliktāk, es varu kaut ko darīt šajā sakarā. "
Ja mēs šeit iesim nākamajā apgabalā; un tas droši vien ir - es teiktu, ka šis ir viens no lielajiem. Viens no jautājumiem, ko es uzdodu, parādot mūsu produktu, es vienmēr jautāšu datu bāzes administratoram: “Kā jūs dzirdat par problēmu, kas saistīta ar jūsu SQL Server datu bāzēm?” Un tas ir ļoti smieklīgi, jo lielāko daļu laika - tagad piešķirot, lielākoties viņi skatās uz mūsu produktu, jo daudzos gadījumos viņi mēģina atrisināt kādu konkrētu vajadzību. Bet ir interesanti dzirdēt sākotnējo lietu - vismaz attiecībā uz SQL Server, ka tā bija tāda veida - jūs zināt, SQL Server pirmajās dienās jums bija SQL Server un tad jums bija Oracle. Visiem bija Oracle, un SQL Server, pirmoreiz darbojoties, bija labāks izteiksmes trūkuma dēļ pārņemtais datu bāzu audžumeita.
Un tad, kad Microsoft tam pievienoja vairāk funkciju, tas mazliet kļuva par uzņēmuma rīku. Un acīmredzot kopš tā laika ir tāls ceļš ejams. Bet jēga ir tāda, ka vienu reizi jūs varētu iebilst, ka dienas laikā datu bāzes netika uzskatītas par kritiskām. Un tas laika gaitā ir mainījies. Tāpēc daudzos gadījumos cilvēki mēģina apbraukt to un saka: “Jūs zināt, ko? Man ir visas šīs SQL Server datubāzes, es cenšos tikt ar to galā. "Un tā vietā, lai dzirdētu par problēmām no palīdzības dienesta vai dzirdētu par problēmām no konkrētiem cilvēkiem, kuras - tāpat kā paši lietotāji - viņi meklē veidus, kā to apiet. Viņi meklē veidus, kā viņus informēt par šīm situācijām, pirms tās kādreiz notiek.
Un tā kā ar Diagnostic Manager, tā ir viena no lietām, ko mēs arī cenšamies darīt, vismaz ir jāprot panākt, ka DBA ir pirmā, kas uzzina par šīm situācijām vai tām problēmām, lai viņi to varētu darīt kaut ko par to, vai nu tad, kad tie notiek, vai arī spert to vēl soli tālāk, lai analizētu šīs sistēmas, kuras tas uzrauga. Un, lai varētu sniegt jums proaktīvus padomus, kas uzlabos šīs instances darbību, un spētu to darīt regulāri. Piemēram, mums jāpievieno indekss, pamatojoties uz darba slodzi; šāda veida lietas, instrumentus, kas arī ir spējīgi. Tātad rīkā mēs to redzēsim daudz.
Otra lieta un pēdējā lieta, kas ir šajā sarakstā, kas drīzāk ir vispārīgs apraksts, taču tas noteikti ir kaut kas ievērības cienīgs. Un jo īpaši, nonākot lielāka mēroga uzņēmuma līmeņa situācijās, kurās ir daudz gadījumu, vienmēr būs kāda neskaidra lieta, ko es gribētu pārraudzīt, ja es esmu datu bāzes administrators. piemērs. Un tas, ko mēs cenšamies darīt, ir paredzēt to, ko tipiskā DBA vēlēsies pārraudzīt.
To sakot, jūs arī spēsit - vienmēr būs kaut kas jauns. Tāpēc mēs jums piedāvājām veidu, kā pievienot instalēšanas punktu pievienošanai nepieciešamo metriku, kas jums jāuzrauga un jāpārvalda. Tātad visi PerfMon skaitītāji, WMI skaitītāji, SQL Server skaitītāja objekti; visus tos var iekļaut rīkā. Jums ir iespēja pievienot papildu vaicājumus, kurus var iekļaut vēlēšanu intervālos.
Un pēdējais, kas ir arī vērts atzīmēt, ir tas, ka mēs varam pievienot un faktiski sazināties gan ar vCenter, gan ar Hyper-V, lai varētu izvilkt metriku no šīm vidēm. Tā kā viena no lietām, ko mēs esam identificējuši ar DBA, ir tā, ka parasti tā nav īpaša operāciju daļa. Un viņiem, protams, nav obligāti jābūt vCenter videi, kas viņiem pieejama, vai tāda veida lietām.
Un tāpēc problēma ir tā, ka, ja viņi nodarbojas ar SQL Server instanci un viņiem ir piešķirti resursi, bet tas ir virtualizēts, var šķist, ka viņiem ir visi pasaules resursi, kad viņi tikai pārrauga viesa operētājsistēmā. Patiesībā resursdatorā var būt 30, 40, vai 50 vai 100 citi VM, kuriem viņi mēģina piekļūt, un viņiem ir tie paši resursi. Un vienīgais veids, kā to faktiski redzēt, ir saziņa ar šīm citām vidēm un ar tām saskarnēm, šajā gadījumā, ko mēs darām.
Jums ir iespēja rīkam pievienot šos cita veida skaitītājus. Tagad tas nav tikai par iespēju uzraudzīt šos skaitītājus, bet arī par iespēju padarīt šos jaunos skaitītājus, kurus jūs iepazīstināt ar produktu, padarīt tos par daļu no rīka, it kā tie būtu ārpuskopienas rādītāji. . Liela lieta, kuru jūs vēlētos uzraudzīt; tas nozīmē, ka jāspēj tos iekļaut informācijas paneļos. Tas nozīmē - spēja pievienot tos saviem pielāgotajiem pārskatiem, spēt acīmredzami noteikt sliekšņus un brīdināt par tiem, kā arī pamatot tos un spēt iestatīt sliekšņus ar zināmām zināšanām par to, kur tos iestatīt, pamatojoties uz tādām lietām kā jūsu bāzes līnijas un kas ir normāli. Tātad, jums ir daudz tādu lietu, kas arī ir izstrādājumā.
Tas, ko es jums esmu nodrošinājis, ir tas, ko es saucu par “galvenajiem diagnostikas menedžera nodevumiem”, un es varu iet uz priekšu un tikai nedaudz iedomāties to, iedziļinoties izstrādājumā. Tas, ko es darīšu, ir padalieties manā ekrānā, labi, un es vienkārši to pārvelku. Tātad, ko jūs redzēsit, šī ir Diagnostic Manager konsole. Un kā jau es minēju iepriekš, dodoties uz pirmo galveno piegādājamo materiālu, lai varētu aplūkot lietas no sava veida uzņēmuma līmeņa skata. Rīkā ir daudz dažādu piemēru. Mums ir sava veida sīktēlu skats; mums vairāk ir režģim līdzīgs skats. Mums ir arī elastīguma ziņā ir arī tīmekļa konsole. Tīmekļa konsolei ir arī citi jums pieejamie skati, piemēram, atslēgu kartes un tamlīdzīgas lietas. Bet jēga ir tā, ka jums ir šī spēja veida apskatīt un ieraudzīt lietas. Bet, kad rodas problēmas, jūs mazliet sīkāk iedziļināsities rīkā un patiesībā redzat konkrēto problēmu kā arī lai kaut kā saprastu un zinātu, kas notiek. Un tas acīmredzot ir ļoti svarīgi.
Tagad, runājot par iespēju reāli redzēt, kas notika pagātnē; Ja es aplūkoju problēmu, kas notika vakar vai pirms nedēļas, tad šajā situācijā, jūs zināt, jums būs jāprot doties uz noteiktu SQL gadījumu. Un labā ziņa ir tā, ka, ja jūs zināt, kurā laikā šī problēma radās izstrādājumā, varat doties tieši uz vēstures pārlūku. Un es varu norādīt uz konkrētu diennakts laiku; tas varētu būt no pāris nedēļām atpakaļ, tas varētu būt no vakardienas. Bet neatkarīgi no tā, kuru dienu es kalendārā izvēlos, man tiks pasniegts atšķirīgais vēlēšanu intervāls. Tādā gadījumā tagad es faktiski redzu to, ko es būtu redzējis, ja es būtu skatījies pulti 20. aprīlī pulksten 13:37.
Tāpēc es varu atgriezties laikā, un pēc tam, kad es to izdarīšu, visas dažādās cilnes, kuras mēs šeit redzam, atspoguļos šo konkrēto laiku, ieskaitot vaicājumus, kas, iespējams, darbojās slikti, ieskaitot varbūt, ja Man bija sesijas ar bloķēšanu. Visi šāda veida materiāli parādīsies rīkā, un tas man ļaus acīmredzami izmantot šo vēsturisko informāciju, lai, jūs zināt, varētu novērst problēmu. Tagad, kad mēs runājam par vēsturi, ir vērts pievērst uzmanību arī tam, ka tā nav tikai vēstures izmantošana problēmu novēršanai. Acīmredzami šī vēsture ir ļoti vērtīga citu iemeslu dēļ. Un viens no lielākajiem ir spēja efektīvi pieņemt lēmumus un ātri, ar pareizu informāciju, pieņemt lēmumus. Tātad visu šo vēsturi, visu informāciju, kuru mēs apkopojam, mēs varam ziņot pret.
Ja kāds nāk pie manis un saka: "Es saņēmu šo patiešām lielisko jauno lietojumprogrammu. Tas mainīs pasauli, kā mēs to zinām. Ak, starp citu, tam būs nepieciešama datu bāze, un, ak, starp citu, tas tiešām tiks piesaistīts I / O mašīnā, kurā atrodas šī datu bāze. " Ja es zinu, ka iedziļinos tajā, es varu izmantot šo informāciju, lai varētu sniegt visu manu ražošanas serveru rangu, pamatojoties, iespējams, uz pēdējām septiņām kolekcijas dienām. Un es ļoti ātri varētu secināt, kurās instancēs ir visnozīmīgāk izmantot šo datu bāzi. Tātad acīmredzami ļoti vērtīga ir šāda veida vēsturiskā informācija.
Pašu vaicājumu ziņā; attiecībā uz vaicājumu izskatīšanu mums ir ļoti daudz dažādu iespēju, kā to izdarīt rīkā. Un tas, ko man patīk aplūkot, ir Query Waits View, jo Query Waits View ir ļoti noderīgs, lai spētu novērtēt. Ja man rodas sastrēgums, lai varētu būtībā identificēt visas dažādās jomas, kas ietekmē šo konkrēto, konkrēto vaicājumu; ne tikai pats vaicājums un kāda ir šī vaicājuma ietekme, bet arī, jūs zināt, no kuras lietojumprogrammas tas nāca, no kuras sesijas tas nāca, kurš lietotājs to sauca un visi šie sīkumi, es uzskatu, ka acīmredzot informācija reālajā laikā, bet man ir arī iespēja aplūkot šos pagātnes datus. Tā ir viena no lietām šeit, un es aizsāku skriptu, bet man jāgaida, kad tas parādīsies.
Kamēr mēs to gaidām, es gribu - un es zinu, ka mums pietrūkst laika, tāpēc es gribēju mazliet sarunāties arī par to, ka brīdināšanas paziņojumi ir proaktīvi. Un, kad jūs runājat par šāda veida lietām, kā es jau teicu, tā ir proaktīvā daļa, un tur ir daudz rīku, kas brīdina. Grūtākais ir tas, ka netiek nosūtīts e-pasts. Cietā daļa nav rakstīšana notikumu žurnālā vai SNMP slazda ģenerēšana. Grūtākais ir zināt, kad nosūtīt šo brīdinājumu attiecīgajā laikā. Un tātad daudz kas nākas veikt dažus aprēķinus, kuriem ir jāsaprot: "Kas tas ir par šo konkrēto gadījumu un kas ir normāli, ja tas attiecas uz šo gadījumu?"
Un tāpēc visiem rādītājiem, kuriem ir jēga to darīt, mēs šos rādītājus izlīdzinām. Mēs faktiski parādīsim sākumstāvokli, mēs parādīsim slieksni, uz kādu tas pašlaik ir iestatīts. Un tad vēl viena jauka lieta par to ir tā, ka, teiksim, es šim gadījumam es uzstādīju sliekšņus uz sešiem un desmit. Pēc sešām nedēļām, ja es atgriezīšos pie šī gadījuma, šī bāzes līnija var pilnībā mainīties, jo viena no lietām, ko mēs darām, aprēķinot bāzes līniju, pēc noklusējuma ir slīdošs septiņu dienu aprēķins. Tāpēc tas vienmēr dod man jaunāko bāzes līnijas versiju. Un kas notiek, ja šī sākotnējā vērtība mainās uz manu slieksni? Šajā gadījumā es redzu un brīdinošus ieteikumus, kas būtībā saka: "Hei, jums ir noteikts slieksnis, kas, iespējams, ir nepareizi noteikts, kas attiecas uz to, kur mēs redzam slieksni, un acīmredzot tur, kur atrodas bāzes līnija, jūs, iespējams, gatavojaties saņemt brīdinājumu par kaut ko normālu. "
Un tā vietā, lai ārstētu simptomus kaut kam normālam, es varu noteikt tāda veida situāciju, kad faktiskais slieksnis ir noteikts nepareizi. Un tas, ko es varu darīt acīmredzami, ir noteikt sliekšņus atbilstoši tam, kur es saņemšu trauksmi. Es zinu, ka tas drīzāk ir aicinājums uz darbību, nevis izmeklēšana, lai noskaidrotu, vai tā tiešām ir problēma. Un es domāju, ka šī rīka daļa ir patiešām noderīga, ņemot vērā pašu sākumstāvokli un spēju aprēķināt.
Tagad, izmantojot šo produktu, jums ir iespēja reāli izmantot vairākas bāzes līnijas; tos var iestatīt dažādiem laika periodiem, un jūs varat dinamiski pielāgot sliekšņus, balstoties uz jūsu bāzes līnijām, kas ir arī ļoti svarīga veida pielāgošanās izmaiņām, kas katru dienu notiek jūsu SQL Server gadījumiem. . Tagad šajā gadījumā mēs sedzam daudz sliekšņu iestatījumus un parādām jums bāzes līnijas. Bet, ciktāl tas attiecas uz faktiskajiem brīdinājumiem, pats paziņojums, kas ir ļoti noderīga Diagnostic Manager, ir tas, ka tas jums nodrošina vairākus brīdināšanas profilus. Tātad, ja jums ir, piemēram, dežūras profils, kas ir no plkst. 2:00 līdz 5:00, tad man var būt profils, kas attiecas tieši uz šo laika diapazonu, un šeit es varu iestatīt visus nosacījumus un atbilstošos iestatījumus. par manu atbildi.
Tagad par atbildi ir tas, ka dažos gadījumos jā, es varu sūtīt e-pastu vai arī varu nošaut un ģenerēt SNMP slazdu vai rakstīt notikumu žurnālā. Ir daudz citu lietu, ko mēs varam darīt, bet, runājot ar DBA, kas viņiem patiešām patīk, ir tas, ka vairumā gadījumu liela daļa izpildītā darba ir atkārtojumi. Tie ir sīkumi, ko viņi precīzi zina, kad rodas problēma, kā rīkoties, lai to novērstu. Viņiem vienkārši jāiet un jāiejaucas. Un, tā kā jūs audzējat savu vidi, jo jums ir vairāk gadījumu, to izdarīt ir daudz grūtāk. Tātad viena no tām lietām, kuras, manuprāt, ir vērts pieminēt rīkā, ir tā, vai jums ir spēja iestatīt nosacījumu, taču, pamatojoties uz šo nosacījumu, lai jūs varētu iestatīt atbildi skripta palaišanai, darbs, lai palaistu izpildāmu. Un, ja jūs nolemjat palaist skriptu, es varu izmantot parametrus šī skripta iekšpusē, kas būs izpildes laikā, aizpildot ar faktisko informāciju.
Tātad, ja rodas problēmas ar noteiktu datu bāzi, skripts tiks izveidots tā, lai darbotos tieši pret datu bāzi, kur rodas šī problēma. Tātad, jūs varat dinamiski risināt problēmas automatizētā veidā, un tad es joprojām varu saņemt e-pastu, lai atgrieztos un man pateiktu, ka "hei, bija problēma, bet, starp citu, tā tika novērsta." Skripts tika palaists, un kā DBA jūs par to zināt, taču faktiski nevajadzēja ieiet un iejaukties. Tagad tajā pašā piezīmē par to, ka mēs esam aktīvi, acīmredzot mums šeit ir arī vēl viena funkcija, kas ir “Analizēt”. Un, ko tas darīs, tas veiks regulāru pārbaudi attiecībā pret SQL gadījumu. Un dažos gadījumos tas ļaus dziļāk ienirt meklēto ziņā. Tiks veiktas tādas lietas kā hipotētiska indeksa analīze. Vai es varu pievienot indeksu? Vai es varu noņemt indeksu? Un visas šīs lietas acīmredzami palīdzēs manā izpildījumā, bet atkal tas viss ir par proaktīvu darbību. Tas ir par to, kā spēt pieņemt lēmumus pirms lietu pārtraukuma, kā arī panākt, lai tie darbotos labāk. Un tāpēc daudzos gadījumos tas ir tas, ko mēs šeit cenšamies darīt.
Atgriežoties pie Query Waits, par ko mēs jau runājām; kā redzat, šeit ir liels smaile. Es agrāk vadīju skriptu, kas tikai izraisīja dažas nogaidīšanas aktivitātes, un, kā jau minēju iepriekš, mums ir patiešām unikāls veids, kā jūs varat izpētīt šo informāciju. Ja es gribu redzēt, kāda tā bija; Es redzu, ka tas nāk no lietojumprogrammas NoSQL. Mēs varētu redzēt datu bāzi, kurai tā ir piesaistīta, sesiju, lietotāju, un tad, ja es vēlos, varu to sarindot arī manu gaidu ziņā. Tātad, es varu teikt, no visām gaidībām, kas notika tajā laika logā, kuras notika visbiežāk? Un, ja es redzu, ka tad, kad tas ir noticis visvairāk, patiesi jauka lieta ir tas, ka es varu iedziļināties šajā gaidīšanas tipā un redzēt visas komandas. Ja paskatīsities šeit, viņi lika šai gaidīšanai notikt. Un es arī galvenokārt redzu, kura lietojumprogramma tā bija, kas lika tai gaidīt.
Tātad tas izliekas kā sāpīgs īkšķis. Es uzreiz varu aiziet un pateikt: "Šī ir programma, kas rada manu sastrēgumu. Tagad kāds bija izpildītais vaicājums? Kurš lietotājs to vadīja? Kurai datu bāzei tas darbojās?" Utt. Tāpēc, cerams, ka tam ir jēga, un tas palīdz arī pārliecināties, ka jums nav latences jūsu vidē, jo tas attiecas uz jūsu datu bāzēm. Cerams, ka tas ir noderīgi. Šajā brīdī es došos uz priekšu un pārsūtīšu to atpakaļ, un es domāju mēs varam turpināt no turienes.
Ēriks Kavanagh: Protams. Tātad, es domāju, es to vienkārši iemetīšu mūsu dienas ekspertiem. Atzīmējiet, varbūt vispirms vēlaties komentēt un uzdot pāris jautājumus. Tad Dez, jūs varat piebalsot.
Marks Madsens: Jā, paldies, man patiešām patika to skatīties. Tas ir daudz saprātīgāks monitorings, nekā es esmu pieradis redzēt. Mani interesē, kā tiek pārvaldīti dati; to metriku pārvaldīšana, kuras varat izsekot, un, kā jūs zināt, meklējiet tādas lietas kā, piemēram, mainot bāzes līnijas, kas ir viens no maniem mājdzīvnieku sāpju punktiem, izmantojot paneļus. Kā jūs rīkojaties ar šiem datiem, un tā otrā daļa ir, jūs zināt, bāzes līnijas metrika, piemēram, veida maiņa - vai jūs spējat arī automātiski novirzīt sliekšņus, lai man nebūtu dodieties atpakaļ un ar roku atiestatiet sliekšņus, kad mainās bāzes līnija?
Bullett Manale: Jūs to darāt, un tāpēc patīkami, ka jūs to varat izlemt. Jūs varat darīt vai nu. Es varu iestatīt slieksni un padarīt to par statisku iestatījumu, vai arī atzīmēt rūtiņu, sakot: “Padariet to par dinamisku slieksni, kas mainīsies, mainoties manām bāzes līnijām.” Un man ir iespējas un rīks iestatīt noklusējuma logu. Bet tad, ja man tas būs nepieciešams, man, piemēram, no apkopes loga, no plkst. 2:00, teiksim, līdz plkst. 5:00, man varētu būt atsevišķs bāzes līnijas logs, jo es aplikšu ar nodokli Centrālais procesors, mani diskdziņi un viss pārējais, jo tieši tad mēs veicam visu mūsu tehnisko apkopi. Tad automātiski, ja es būtu izvēlējies to darīt, tas automātiski pielāgotu manus sliekšņus ārpus tā, kur ir normāli tiem metrikām, kas Es izvēlos to darīt ar. Tas ļautu man to darīt. Būtībā rīkā rīkā ir iespēja iestatīt laika logus, kas ir jūsu pamata logi, un katru logu var uzskatīt par atsevišķu entītiju attiecībā uz dinamiska bāzes līnijas korekcija, ko var veikt, un jūs varat pievienot tik daudz logu jūsu sākotnējai situācijai kā yo jums tas jādara, ja tam ir jēga. Jums varētu būt nedēļas nogales logs, darba diena darba laikā, apkopes logs, kas notiek nakts vidū un tā tālāk un tā tālāk.
Marks Madsens: Paldies.
Bullett Manale: Es domāju, ka atgriezīsimies pie jautājuma pirmās daļas, kas mums ir, un mēs apkopojam visu šo informāciju. Es īsti nerunāju par arhitektūru, bet mums ir back-end repozitorijs, ka jums ir pilnīga kontrole pār šo datu saglabāšanu, bet mums ir arī pakalpojums, kas darbojas nakts vidū un iet un dara visus mūsu sākotnējos aprēķinus, un šie dati tiek ņemti, apkopoti un tiem ir jēga. Un acīmredzot kopā ar jums arī ir daudz ziņojumu, kurus mēs varam izmantot, lai ziņotu par jūsu bāzes līnijām, par konkrētu metriku. Un jums pat ir iespēja salīdzināt viena un tā paša servera bāzes līnijas par vienu un to pašu metriku dažādiem laika periodiem. Jūs varat redzēt, vai ir notikušas atšķirības, vai kāda ir delta. Arī šo variantu veidu ir daudz.
Ēriks Kavanaghs: Dez.
Dezs Blanšfīlds: Viens ātrs jautājums, kas man jums ir, - tur ir plašs spektrs, ko šis rīks var darīt. Vai jūs redzat, ka to lietojat agrīnā attīstības stadijā, vai arī tas galvenokārt joprojām ir ražošanas vides rīks? Citiem vārdiem sakot, vai izstrādātāji iegūst piekļuvi un izmanto to jau agrīnā attīstības posmā un pēc tam pārbaudot integrācijas posmu? Vai arī to joprojām galvenokārt izmanto ražošanas vidē?
Bullett Manale: Es teiktu, ka lielāko daļu reižu mēs to redzam ražošanas vidē. Tas ir atkarīgs no situācijām, bet lielākoties es teiktu, ka galvenokārt ražošana un mēs to darām - un tas, jūs zināt, ir arī godīgi pieminēt, ka mums ir atšķirīgas cenas dev un testēšanas vidēm, tāpēc tas ir mazliet pievilcīgāks. Mēs redzam, ka cilvēki to izmanto šīm vidēm, bet es teiktu, ja man būtu jāsniedz jums atbilde vienā vai otrā veidā, es teiktu, ka tā galvenokārt joprojām ir ražošanas vide, kurā mēs redzam, kā cilvēki veic ieguldījumu šajā produktā .
Dezs Blanšfīlds: Protams, jā, un bija interesanti dzirdēt, ka jums ir dažādi cenu punkti, jo acīmredzami ir atšķirīga darba slodze, un jo smagāki būs darbi, kur tiks veikts viss reālais darbs. Bet es redzu daudz organizāciju, it īpaši valdībā un, protams, aizsardzībā, kur attīstība tagad iegulda tikpat lielus ieguldījumus instrumentos un sistēmās kā ražošanas vide, jo tās daudz vairāk veic sākotnēju pārbaudi. Piemēram, aizsardzībā ir komandas, kuras vada miljardiem pārbaužu, simtiem miljardu lietojumprogrammu un sistēmu un rīku testu, un pārrauga tos, pirms viņi pat sāk integrācijas testēšanu, jo viņi vēlas pārliecināties, vai ir izveidots kods un datu bāze tas sēž zem tā. Tas nonāk līdz simt miljona iterācijai vai kaut kam tamlīdz, kamēr jūs laukā šaujat pie kāda, tas neiet "sprādzienā".
Bullett Manale: Protams.
Dezs Blanšfīlds: Vecās skolas datu bāzu pasaulē, pēc manas pieredzes, domājot, ka datu bāzes vide ir kaut kas tikai palicis datos un daži no jums zina, ļoti reti tiek parādīti un ļoti reti tiek runāts, tāpēc, kad mēs nonākam pie tā brīža, kad rīki un tiek izstrādātas lietotnes, jo īpaši ar analītiskām platformām, tagad tās ir mūsu tālruņos un mūsu ierīcēs. Vai jūs redzat, ka klienti sarunu par datu bāzes veiktspēju un datu bāzes pārvaldību izvērš ikdienas diskusijās, nevis tikai ar tehnoloģijām? Un es zinu, ka jūs jau iepriekš minējāt, ka jūs galvenokārt runājat ar DBA, bet vai ir kāda tendence, kad tas notiek vispārējā leksikā, vai jūs redzat cilvēkus, kur viņi apspriež šīs tēmas, nevis tikai geeks?
Bullett Manale: Tas ir grūti pateikt. Es domāju, kā es lielākoties teicu, ka cilvēki, ar kuriem mēs saskaramies pārdošanas procesa ziņā, ir praktizētāji, kas ir DBA. Tātad, runājot par jūsu jautājumu, jūs vienkārši sakāt: "Vispārīgi runājot par IT organizācijas cilvēkiem, vai viņi kļūst labāk zināmi datu bāzēm?" Es domāju, ka tas ir jautājums, un es, iespējams, teiktu, ka atbilde ir "jā". Es droši vien to ikdienā neredzu tik daudz, pamatojoties uz to, kur atrodos, bet es domāju, ka, ja es saprotu jūsu jautājumu, es domāju, ka tā būtu mana atbilde.
Dezs Blanšfīlds: Jā, tas ir labi. Droši vien tas ir noslogots jautājums, piedodiet, jo acīmredzot jūsu dominējošās intereses jūsu pasaulē ir lietu tehniskā puse. Es esmu ziņkārīgs, ka savās ikdienas aktivitātēs es redzu, ka organizācijas ļoti agri sāk to iesaistīt sarunā. Tātad, kad viņi runā par jaunām iniciatīvām, jauniem projektiem, jaunām darba programmām, viena no lietām, kas nekavējoties rodas, ir: “Kā mēs to uzraugām, kā mēs to izsekojam, kā risinām jautājumus, kad tie rodas, pretstatā palaišanai, tiešraidē? "
Bullett Manale: Es teiktu, ka -
Dez Blanchfield: Atvainojiet, dodieties tālāk.
Bullett Manale: Es gribēju teikt, ka es redzu tendenci, par kuru, manuprāt, man vajadzētu sacīt: jūs zināt, daudz reizes pagātnē jūs saņemat: “Mums bija problēma, un tāpēc tagad mums ir nepieciešams rīks. " Un es domāju, ka mēs redzam mazliet vairāk pieņemšanas par instrumenta uzstādīšanu pirms problēmas rašanās, ja tam ir jēga. Tāpēc es teiktu, ka tas noteikti kļūst par normālu, jūs zināt: “Ei, mums ir vajadzīgs uzraudzības rīks, mums kaut kas vajadzīgs.” Un cilvēki noteikti redz šī produkta vērtību, jo, kā jūs teicāt iepriekš, vienkārši pievienojot DBA un pievienojot jaunus gadījumus, jums ir nepieciešams kaut kas, kas to pārvalda. Jums ir nepieciešams kaut kas, kas palīdz tā pārvaldībā, un tāpēc mēs arī šo produktu uztveram daudz, vai arī tas mums ir.
Dez Blanchfield: ātrs jautājums. Kur tas jādzīvo? Vai tam ir jāsēž tieši uz aizdedzināšanas LAN tīklā, datu centrā, pēc iespējas tuvāk datu bāzes videi, vai tas ir ērti novietots kaut kur, potenciāli ārā mākonī, trešās puses mākonim ar sava veida vai nu VPN tunelis, vai attāla piekļuve dažādām vidēm? Kur tam vajadzētu sēdēt, ciktāl tas attiecas uz vidi un uzraudzību?
Bullett Manale: Arhitektūras ziņā tur ir rezerves krātuve, un tā ir SQL Server datu bāze. Mums ir konsole, kas var būt gan resna, gan maza kliente; mēs piedāvājam jums abas iespējas. Un mums ir arī plāns klients, kas tiešām ir paredzēts arī mobilajām ierīcēm. Bet attiecībā uz to, kur tas patiesībā var sēdēt; tas var atrasties vidē, un visnotaļ sarežģītākā daļa no daudzās informācijas, kas mums jāvāc, dažos gadījumos vai daudzos gadījumos prasa administratīvas tiesības. Tagad mēs neliekam jums to darīt; ja vēlaties, varat savākt datus un tikai par lietām, kuras mēs nevaram apkopot, jo mums nav administratora tiesību, mēs vienkārši ļausim jums neredzēt šo informāciju, ja tā ir jūsu izdarītā izvēle.
Atkarībā no aromāta, piemēram, ja jūs runājat par AWS, dažām vidēm, tā darbojas labāk nekā citi, taču, ciktāl tas attiecas uz pašu vidi, tas ir viss, kas nepieciešams, izmantojot vai nu SA autentifikāciju, lai savāktu datus pret gadījumiem. Vai arī, ja tas ir neuzticams domēns, parasti tas ir tas, kad vēlaties to darīt, bet vairāki domēni; ja vien starp viņiem pastāv uzticība, mēs varam savākt pret tiem. Nav īsti nozīmes tam, vai tas atrodas LAN vai WAN, pati faktiskā kolekcija ir diezgan niecīga mūsu apkopotā datu apjoma ziņā. Ja mums ir pietiekams WAN savienojums, tā nav problēma. Esmu redzējis vidi, kur viņiem ir filiāles, kur viņiem ir SQL serveri visā ASV. Tas ir viens serveris katrā no šīm dažādajām vietām, un viņi to uzrauga centralizēti. Veltīgā daļa ir tikai pārliecināšanās, ka jums to nodrošina pietiekami daudz savienojumu. Cerams, ka tas atbild uz jūsu jautājumu, tas bija visā kartē.
Dezs Blanšfīlds: Pilnīgi. Paldies. Tātad, divi ātri jautājumi, kas šorīt bija radušies apmeklētājiem; viens ir: kāda ir ietekme - bieži mēs redzam, ka sistēmas uzraudzības rīki paši rada slodzi, vienkārši pārraugot lietas, tāpēc jautājums bija, piedodiet, ka tagad tas ritināja pie mana ekrāna, bet tikai to pārfrāzēja; pārraugot, vai mēs paši radām slodzi? Vai instrumenta ietekme ir mērāma, tikai vērojot vidi, vai tā ir nenozīmīga?
Bullett Manale: Vienmēr būs neliela ietekme, jo tai ir jāuzdod vaicājums SQL Server instancē, lai atgūtu datus. Jautājums, kā jūs teicāt, ir: "Vai tas ir nenozīmīgs vai tas ir nozīmīgs?" No lodziņa, uz kuru jūs norādāt, piemēram, ir maz. Mēs to darījām, kā jau teicu, jau labu laiku. Mums ir vairāk nekā 20 000 klientu, un es varu jums apliecināt, ka, ja tas radītu būtisku iespaidu uz darbību, mēs nedarbotosimies. Ņemot to vērā, mēs arī ļaujam lietotājam izlemt, ko viņi vēlas uzraudzīt. Tāpēc es domāju, ka ir svarīgi pieminēt, ka katra vide ir mazliet savādāka.
Piemēram, ja vaicājumu uzraudzības komponents ir viena no lietām, ko mēs spējam darīt, mēs varam noteikt slieksni tam, ko jūs uzskatāt par jūsu normālas robežas robežu. Tātad tā pamatā varētu būt vaicājuma izpildes laiks. Tas varētu būt balstīts uz centrālo procesoru, I / O, bet kā piemēru, pieņemsim, vienkārši teiksim, ka esmu iestatījis izpildes laiku uz nulli milisekundēm. Faktiski tas, ko es iesaku rīkam, ir apkopot visus jautājumus, kas bijuši kopš pēdējā vilkšanas intervāla, un izveidot arī šo daļu no manas vēsturiskās kolekcijas.
Tagad, kad mēs to darīsim, mēs apkoposim tik daudz vaicājumu, kādus mēs darbojāmies kastē kopš pēdējās vēlēšanas. Tagad to var izvēlēties, un lietotājs to var izdarīt. Vai mēs sakām: "Tas jums jādara"? Nē. Bet mēs arī dodam jums iespēju to darīt gadījumā, ja vēlaties datu paraugu, kas ļauj jums apkopot šo informāciju. Tātad vispārīgi runājot, jums ir līdzekļi rīks, lai to iestatītu un precīzi noregulētu, kā vēlaties, ņemot vērā to, kas jums patīk. Bet jums ir iespēja to patiešām atvērt, ja vēlaties, un apkopot daudz papildu informācijas, kas jums, iespējams, ne vienmēr ir regulāri vāc, ja tam ir jēga.
Dezs Blanšfīlds: Jā, absolūti. Es zinu, ka mēs skrienam mazliet ilgi, bet ir divi patiešām lieliski jautājumi, kurus es vēlos uzmest jums pirms iesaiņošanas. Viņi abi nāk tieši pie manis, bet es domāju, ka vislabāk ir atbildēt uz viņiem. Jautājums parasti bija šāds: "Kāds ir rīka sasniedzamības līmenis, ciktāl tas attiecas uz zināšanām par esošajām sistēmām?" Tātad, vai mēs varam to vienkārši iespraust, un tas ļauj automātiski noteikt tur esošo platformu un zināt, kas šai platformai ir parasts, un nekavējoties paņemiet, kā Marks runāja iepriekš? Dažas no sākotnējām zināšanām par platformām, ieviešot, jūs zināt, es nezinu, tā varētu būt Microsoft Dynamics. Cik plašs ir platformas zināšanu apjoms ar to, kas ir parasts un dažos no pašreizējiem rīkiem, kas tiek izmantoti uzņēmējdarbībā?
Bullett Manale: Es teiktu, ka vispārīgi runājot, kad mēs sākam vākt datus par SQL instanci, mēs strādājam ar labāko praksi, sākot ar mūsu sliekšņiem un to, kur tie noteikti. Tomēr mēs arī atzīstam, ka ikviens, ar kuru jūs runājat, ņemot vērā labāko praksi, katra vide ir atšķirīga. Tas, ko mēs sākotnēji darīsim, mēs vienkārši apkopojam datus, un to, ko mēs iesakām darīt cilvēkiem, varat izmēģināt produktu 14 dienas ilgāk, ja jums tas ir nepieciešams. Bet pēc apmēram divām dienām sāksit redzēt sākotnējos datus. Tiklīdz tam būs pietiekami daudz informācijas parauga, lai ar to varētu strādāt, tas sāks sniegt jums kontekstu ar bāzes līniju, kur diapazons atrodas, un visu šo lietu. Pēc tam, ja vēlaties, jūs varat automātiski iestatīt sliekšņus no savāktās informācijas. Lai sāktu noteikt, kas ir normāli, ir nepieciešams nedaudz sākotnējās savākšanas un aptaujas, lai jūs varētu sākt slīdēt.
Bet, manuprāt, ir vērts atzīmēt arī to, ka, mainot šos sliekšņus, to var izdarīt, ņemot vērā jūsu gadījumu grupas. Tas var būt specifisks vienam gadījumam, vai arī jūs varat to izdarīt pret visiem saviem gadījumiem, kā arī iespēju izveidot tādas lietas kā veidnes, lai varētu pateikt: “Šis ir ražošanas piemērs, taču šo es gribu tam piešķirt. " Un, kad jauns ražošanas piemērs nonāk tiešsaistē, mēs automātiski piemērojam tos sliekšņus, jo tam ir tāda paša veida aparatūra un tam parasti ir vienādas darba slodzes, tāpēc mēs to varētu arī izdarīt. Cerams, ka tas palīdzēs jautājuma risināšanā.
Dezs Blanšfīlds: Pilnīgi. Faktiski jūs faktiski atbildējāt uz citu jautājumu, kas man tikko ienāca, un tas bija: "Vai ir pieejama izmēģinājuma lejupielāde?" Ir, es uz to varu atbildēt, es zinu. Es esmu pārliecināts, ka jūs apstiprināsit, ka lejupielāde ir pieejama bez maksas, un es domāju, ka jūs teicāt, ka tas notika 14 dienu laikā no vietnes. Jūs to varat lejupielādēt un spēlēt ar to. Domāju, ka ātri vien ar to atbildēs: "Kāda veida vide ir nepieciešama, lai varētu vadīt izmēģinājumu? Vai es to varu palaist klēpjdatorā un spēlēt ar to, vai tiešām man ir nepieciešams serveris?"
Bullett Manale: Galvenais, kas tai vajadzīgs, ir krātuve, SQL Server datu bāze, kas ir 2005. gada vai jaunāka. Izņemot to, ir dažas minimālas resursu prasības, .NET prasība, un tas arī ir. Tātad, atliek tikai instalēt produktu un izveidot datu bāzi.
Dez Blanchfield: ideāls. Pēdējais jautājums, kuru es jums uzmetīšu, jo mums šobrīd ir nokavēts laiks, bet ātri man apmēram divi vai trīs cilvēki man jautāja: "Vai man ir jābūt DBA, lai es tiešām varētu piecelties un darboties ar šo un vai spēlēties ar to? ”
Bullett Manale: Nē. Es teiktu, ka, ja jūs esat DBA, jums būs dažādi rīka lietojumi. Es domāju, ka, iespējams, būs mazliet lielāka vērtība, ja esat pieredzējis DBA. Jūs redzēsit daudz padziļinātāku rīku, kuru jūs varētu izmantot. Bet arī kā jaunai DBA vai pat personai, kurai tā nav DBA, mums ir daudz ieteikumu, un šobrīd esmu šajā lapā. Šie ieteikumi tiks regulāri iesniegti, un patiesi patīkami ir ieteikumi, ja tie sniedz jums iemeslus, kāpēc ieteikumi tiek sniegti. Bet papildus tam viņiem būs arī saites uz ārēju saturu, kas sīkāk apraksta iemeslus, kāpēc šie ieteikumi tiek sniegti. Tā būs saite uz ārējām Microsoft vietnēm, emuāriem un visa cita veida materiāliem, tas ir ārējs.
Bet, lai atbildētu uz jūsu jautājumu, tas ir sava veida, jūs zināt, ja jūs esat vecākais DBA, šeit būs sīkumi, jūs, iespējams, izmantosit tādas iespējas, kuras jūs, iespējams, nebūtu par iesācēju DBA. Bet tajā pašā laikā tas ir arī sava veida mācību līdzeklis, jo, iepazīstoties ar šiem ieteikumiem, jūs sāksit izvēlēties dažas no šīm lietām pats, izmantojot šos ieteikumus.
Dez Blanchfield: fantastiski. Paldies. Man ļoti patika demonstrācijas daļa. Prezentācija bija lieliska. Demonstrācija bija fantastiska. Ātri no atmiņas jūsu vietnē ir viss resursu centrs, kuru es iesaku arī cilvēkiem apskatīt. Es atceros, ka pagājušajā naktī gāju cauri, lai iegūtu sīkāku informāciju. Jums ir daudz dažādu lietu, tikai no jūsu emuāriem un datiem un sarunām līdz pat atmiņai. Lielākā daļa jūsu produktu dokumentācijas ir pieejama arī tiešsaistē, jā?
Bullett Manale: Jā, tā ir pareiza, un es domāju, ka jūs atsaucaties uz vietni community.idera.com. Un tad es pieminēšu arī vienu lietu, par kuru jūs agrāk jautājāt: "Vai tā atpazīst vidi?" Runājot par jauniem gadījumiem vai gadījumu pievienošanu, mums ir vēl viens rīks, kas atklāj gadījumus. Un tas viss attiecas uz krājumiem un krājumu pārvaldību. Es tikai gribētu jūs norādīt šajā virzienā attiecībā uz gadījumu patiesu atklāšanu. Bet ciktāl tas attiecas uz veiktspēju un uzraudzību, visa veida lietām, par kurām mēs runājām, šeit darbosies diagnostikas pārvaldnieks.
Dez Blanchfield: fantastiski. Paskaties, lielisks pārklājums. Ļoti priecājos par jūsu prezentāciju. Patika tiešraides demonstrācija, un tas viss no manis šorīt, jo es zinu, ka laika gaitā esam aizgājuši, iespējams, 10 minūtes. Ēriks, es tev atgriezīšos.
Ēriks Kavanaghs: Labi. Es vienkārši mīlēju demonstrāciju. Esmu priecīgs, ka veicāt demonstrāciju. Es priecājos, ka mums tas bija jāizvērtē jauki un cītīgi, apskatot jautājumus un atbildes.
Bullett Manale: Lieliski.
Ēriks Kavanaghs: Tā kā tas cilvēkiem rada priekšstatu par to, ko jūs skatāties, un tas mani patiešām izbrīna, domājot, ka mēs joprojām mācāmies, kā sarunāties ar šiem datoriem, kad jūs to saprotat. Es domāju, ka šis diagnostikas līmenis ir diezgan sarežģīts, un tas katru dienu uzlabojas. Mēs iegūstam daudz plašāku ieskatu par to, kas patiesībā notiek. Bet jums tiešām ir nepieciešams, lai cilvēks, kurš skatu šo saturu, to lasītu, aizkavētu šo kognitīvo spēju aiz tā, ko jūs darāt, vai ne?
Bullett Manale: Jā, es domāju daudzos gadījumos - es vēlos, lai es jums saku, ka šī ir DBA kaste, bet notiek pārāk daudz lietu. Es domāju, ka mēs sniedzam norādījumus un palīdzam, taču dienas beigās cilvēkiem ir jāpieņem lēmumi par mūsu iesniegtajiem datiem. Es nedomāju, ka tas drīz mainīsies.
Ēriks Kavanaghs: Nu, tas ir labas ziņas tur esošajiem cilvēkiem, ļaudīm.
Bullett Manale: Tieši tā.
Ēriks Kavanaghs: Jūs vēlēsities, lai kāds to vēro, komanda, kas to vēro, un jūs uzzināsit, kā jūs dzirdējāt no Bullett šeit, aplūkojot šos ieteikumus, jūs gatavojaties uzņemt to, kas notiek. Es domāju, ka domāju no šīs vēstures, un es domāju, ka jūs esat pieskāries šim, Bullett, bet ļoti ātri, ka vēsture ļauj atpazīt nozīmīgus modeļus un pēc tam tos spēt identificēt, kad tie notiks nākotnē, vai ne?
Bullett Manale: Tas ir pareizi. Viena no lietām, ko mēs varam darīt, ir izsekot vaicājuma veiktspējai laika gaitā. Mēs acīmredzami varam apskatīt arī citas lietas, piemēram, bāzes līnijas, un redzēt, kā tās mainās, un acīmredzot saņemt brīdinājumus un tamlīdzīgas lietas, kad tas notiek, tāpēc jums noteikti ir šī spēja.
Ēriks Kavanagh: Cilvēki, tas izklausās labi. Mēs ilgi nebūtu šeit bijuši, bet es gribēju pievērsties šiem jautājumiem. Liels paldies par jūsu veltīto laiku un uzmanību. Mēs arhivējam visas šīs tīmekļa pārraides. Pārvietojieties tiešsaistē uz Techopedia.com vai InsideAnalysis.com, redzēsit saites no abām vietām.
Un ar to mēs atvadāmies. Paldies vēlreiz, ļaudis, mēs ar jums sazināsimies nākamnedēļ, vēl trīs tīmekļa pārraides nākamnedēļ, otrdien, trešdien, ceturtdien. Tātad, mēs ar jums sarunāsimies nākamnedēļ, ļaudis. Rūpēties. Labdien, līdz.
Techopedia satura partneris
Techopedia darbinieki ir saistīti ar Bloor Group, un ar viņiem var sazināties, izmantojot labās puses iespējas. Lai uzzinātu vairāk par to, kā mēs strādājam ar nozares partneriem, noklikšķiniet šeit.- Profils
- Vietne
