Ära võtma: Host Eric Kavanagh arutas andmebaaside silumist ja profileerimist dr Robin Bloori, Dez Blanchfieldi ja IDERA-de Bert Scalzoga.
Te pole praegu sisse logitud. Video nägemiseks logige sisse või registreeruge.
Eric Kavanagh: Olgu, daamid ja härrad, kell on kolmapäeval kell 4:00 Ida-aeg ja see muidugi tähendab.
Robin Bloor: Ei saa sind kuulda, Eric.
Eric Kavanagh: Olin seal päevi tagasi, nii et sa pole üksi. Kuid seega on tänapäeva teema tõesti huvitav värk. See on selline asi, mida soovite veenduda, et teie ettevõttes toimub taustal, välja arvatud juhul, kui olete inimene, kes seda teeb, sel juhul soovite veenduda, et teete seda korralikult. Sest räägiti silumisest. Kellelegi ei meeldi vead, kellelegi ei meeldi, kui tarkvara lakkab töötamast - inimesed ärrituvad, kasutajad muutuvad ebasõbralikeks. See ei ole hea. Niisiis, kavatsesime rääkida teemast "Kiire reageerimine: andmebaaside silumine ja päästmise profileerimine".
Seal on teie enda kohta tõesti lugu, lööge mind üles, muidugi @eric_kavanagh.
See aasta on kuum. Ja silumine läheb kuumaks, ükskõik mida. See on üks neist probleemidest, mis ei kao kuhugi, hoolimata sellest, kui hästi me selle asjaga hakkama saame, on alati teemadeks, nii et peamine on, kuidas jõuda sinna, kus saate need probleemid kiiresti lahendada? Ideaalis on teil suurepärased programmeerijad, suurepärased keskkonnad, kus liiga palju ei juhtu valesti, kuid nagu öeldakse vanas ütluses: “Õnnetused juhtuvad perekonna parimal viisil.” Ja sama kehtib organisatsioonide kohta. Niisiis, see värk juhtub, see juhtub, küsimus on, milline saab olema teie lahendus sellega tegelemiseks ja nende probleemide lahendamiseks?
No kuulge dr Robin Bloorilt, siis alt meie enda Dez Blanchfieldilt, ja muidugi meie head sõpra Bert Scalzo IDERA-st. Ja tegelikult, ma annan Robin Bloorile võtmed ära, võtan selle ära. Põrand on teie oma.
Robin Bloor: OKEI. See on huvitav teema. Arvasin, et kuna Dez jätkab ilmselt silumist puudutavate tegelike võtete ja sõjalugudega, arvasin, et teen lihtsalt taustaarutelu, et peaksime saama toimuva kohta ümardatud pildi. Tegin seda pikka aega ja olin varem kodeerija, nii et see on nagu, ja mul oli selle esitlusega peaaegu kiusatus hakata avatud lähtekoodiga idee lüüriliselt vahatama, kuid arvasin, et jätan selle kellelegi teisele.
Siin on nimekiri kuulsatest vigadest ja enamik neist satub anybodys'e edetabelisse, põhimõtteliselt maksavad kõik, välja arvatud kaks viimast, vähemalt 100 miljonit dollarit. Esimene neist oli Marsi kliimaorbiiter, eksis ruumis ära ja see oli põhjustatud kodeerimisprobleemist, kus inimesed seadsid meetermõõdustiku ühikuid jalgade ja tollidega (naerab). Seal oli Ariane Five Flight 501, mis pandi üles pandud mootori ja nende arvutite vahel, mis pidid raketi käivitamisel töötama, ebakõla. Mitme arvuti rike, plahvatav rakett, uudiste pealkirjad. Nõukogude gaasijuhe 1982. aastal, mis oli suurim plahvatus planeedi ajaloos; Ma pole kindel, kas see on nii. Venelased varastasid automaatse juhtimistarkvara ja CIA sai aru, et kavatsevad seda teha, ja panid sinna vead, ning nõukogude võtsid selle kasutusele ilma testimata. Niisiis, puhus torujuhtme üles, arvas, et see on lõbus.
Morrise uss oli kodeerimiskatse, millest sai ühtäkki rapaline uss, kes läks ümber igihaljaste loomade - see põhjustas ilmselt 100 miljoni dollari väärtuses kahju; see on hinnang muidugi. Intel tegi matemaatikakiibiga kuulsa vea - matemaatikajuhised Pentiumi kiibil 1993. aastal -, mis pidi maksma üle 100 miljoni dollari. Programm Apples Maps on kõige halvem ja katastroofilisem käivitamine kõigega, mida Apple on kunagi teinud. Inimesed, kes proovisid seda kasutada, olid mõtlen, et keegi sõitis mööda 101-d ja avastasid, et Apple Map ütles, et nad asuvad keset San Francisco lahte. Nii hakkasid inimesed Apple Mapsi rakendust nimetama iLostiks. Meie kõige pikem seisak 1990. aastal - see on millegi sellise maksumuse osas lihtsalt huvitav - AT&T olid väljas umbes üheksa tundi ja pikamaakõnede maksumus oli umbes 60 miljonit dollarit.
Ja ma olin Ühendkuningriigi kindlustusfirmas ja andmebaasis, nad rakendasid andmebaasi uue versiooni ja hakkasid andmeid pühkima. Ja ma mäletan seda väga hästi, sest pärast seda kutsuti mind sinna mingisuguse andmebaasi valimisel osalema. Ja väga huvitav oli see, et nad olid võtnud andmebaasi uue versiooni ja neil oli palju teste, mida nad tegid andmebaasi uute versioonide jaoks, et see läbis kõik testid. See leidis tõeliselt varjatud viisi andmete kustutamiseks.
Nii see ikkagi on. Arvasin, et räägin impedantsi ebakõlast ja väljastatud SQL-ist. Huvitav on see, et relatsiooniandmebaasid salvestavad andmeid tabelitesse ja kooderid kipuvad manipuleerima andmetega objekti struktuurides, mis tegelikult tabelitesse väga hästi ei mahu. Ja selle tõttu saate seda, mida nimetatakse impedantsi ebakõlaks, ja keegi peab sellega mingil või teisel viisil hakkama saama. Kuid mis tegelikult juhtub, sest üks mudel, kodeerijate mudel ja andmebaasi teine mudel ei ole eriti joondatud. Saate vigu, mida lihtsalt ei juhtuks, kui tööstus oleks ehitanud asju, mis koos töötavad, mis on minu meelest lõbus. Põhimõtteliselt võib kodeerijate poolel öelda, et kui sa saad hierarhiaid, võivad need olla tüübid, tulemuseks võib olla komplektid, see võib olla kehv API võimekus, see võib olla palju asju, mis lihtsalt ajavad andmebaasi koostoime mõttes asjad välja. Kuid asi on minu jaoks kõige rohkem, tõesti huvitav; alati hämmastunud, et teil oli see SQL-tõke, mis on ka omamoodi takistus, nii et koodrid ja andmebaas töötavad üksteisega. Niisiis, SQL-il on andmete äratundmine, mis on hea, ning sellel on DML valimiseks, projitseerimiseks ja liitumiseks, mis on hästi. Selle abil saate andmebaasist välja saada palju võimalusi. Kuid sellel on asjade tegemiseks väga vähe matemaatilist keelt. Sellel on natuke seda ja teist ning ajapõhist kraami on väga vähe. Ja seetõttu on SQL andmete hankimiseks ebatäiuslik, kui soovite. Niisiis, andmebaasipoisid ehitasid andmebaasis elamiseks salvestatud protseduurid ja seal elatud salvestatud protseduuride põhjuseks oli see, et te ei tahtnud tegelikult andmeid programmi edasi-tagasi visata.
Mõni funktsionaalsus oli äärmiselt andmespetsiifiline, nii et see ei olnud lihtsalt soovituslik terviklikkus ja kaskaadide kustutamine ning muu taoline, hoolitses andmebaas kõigi äkiliste funktsioonide andmebaasi panemise eest, mis muidugi tähendas, et Rakenduse võiks jagada kodeerija ja andmebaasi enda vahel. Ja see tegi teatud tüüpi funktsioonide juurutamise töö üsna raskeks ja seetõttu ka veaohtlikumaks. See on andmebaasimängu üks külg, kuna see tähendab, et olete näiteks paljudes rakendustes osalenud, et olen olnud seotud relatsiooniandmebaasidega ja seal on tõesti kohutavalt palju koodi, mis asub salvestatud protseduurides ja mida käsitletakse koodist eraldi. istub rakendustes. Ja see näib olevat väga kummaline asi, mis pidi olema, eriti erinevate asjade tegemisel.
Arvasin, et räägin ka andmebaasi jõudlusest, kuna jõudlusvigu peetakse sageli tõrgeteks, kuid põhimõtteliselt võib teil olla kitsaskoht CPU-l, mälul, kettal, võrgus ja lukustamise tõttu võivad teil tekkida jõudlusprobleemid. Idee oleks, et kooder ei peaks tegelikult toimivuse pärast muretsema ja andmebaas toimiks tegelikult mõistlikult hästi. See peaks olema kavandatud nii, et kooder ei pea seda teadma. Kuid teil on halb andmebaasikujundus, halb programmide kujundamine, töökoormuse segamisel saate kokku üheaegsuse, mis võib samuti põhjustada jõudlusprobleeme. Saate koormuse tasakaalustamise, läbilaskevõime kavandamise, andmete kasvu - see võib põhjustada andmebaasi seiskumise või aeglustumise. See on huvitav asi, kui andmebaasid saavad peaaegu täis, aeglustuvad need. Andmekihtide väljastamine võib tekkida nii replikatsiooni kui ka replikatsiooni vajaduse ning varundamise ja taastamise vajaduse osas. Igatahes on see üldine ülevaade.
Ainus, mida ma tahaksin öelda, on see, et andmebaaside silumine võib olla ainult nii koormav ja mitte triviaalne - ja ma ütlen seda, sest kuna Ive on seda palju teinud -, ja avastate selle silmis sageli kõik olukorrad, mida ma kunagi kogesin. on see, et esimene asi, mida te kunagi näete, on jama. Ja peate proovima jama juurest edasi töötada välja, kuidas jama tekkis. Ja sageli, kui vaatate andmebaasiväljaannet, on kõik teie arvates rikutud andmed ja te mõtlete: "Kuidas kurat see juhtus?"
Igatahes annan ma edasi Dezile, kes ilmselt ütleb rohkem tarkussõnu, kui ma välja tulin. Ma ei tea, kuidas sulle palli edasi anda, Dez.
Eric Kavanagh: Lasen mööda, ootan, hoian kinni.
Automatiseeritud hääl: Osalejate read vaigistati.
Eric Kavanagh: Hea küll, riputage üks sekund, las ma annan Dezile palli.
Dez Blanchfield: Aitäh, Eric. Jah, dr Robin Bloor, teil on tõepoolest kõige õigem: see on teema, elukestev viga, kui te armu annate, vabandust, et ma ei saanud selle vastu midagi aidata. Loodetavasti näete seal minu esimest ekraani, ülaosas vabandust fondi suuruse probleemi pärast. Vigade teema on kogu päeva pikkune loeng, paljudel juhtudel minu kogemuse põhjal. See on nii lai ja lai teema, nii et keskendun kahele põhivaldkonnale, eriti kontseptsioonile, mida me peame palju veaks, kuid programmeerimise probleemiks. Ma arvan, et tänapäeval saavad vea tutvustamise iseenesest integreeritud arenduskeskkonnad, ehkki need võivad olla pikaajalised vead. Kuid sageli on tegemist koodide profileerimise juhtumiga ja funktsionaalse koodi kirjutamise võimalusega, see peaks olema viga. Niisiis, minu pealkirja slaid siin, oli mul tegelikult selle koopia väga kõrge eraldusvõimega A3, kuid kahjuks hävis see maja kolimise ajal. Kuid see on käsitsi kirjutatud märkus umbes 1945. aasta programmeerimislehelt, kus väidetavalt mõned USA Harvardi ülikooli inimesed, nende teine ehitis Mark II-nimelise masina juurde. Nad silusid ühises keeles mõnda probleemi, kuid püüdsid tõrke leida ja selgub, et kaasas oli ka midagi pisut erinevat riist- ja väidetavalt tarkvaraprobleemist.
Niisiis, linna müüt on umbes 9. septembri paikuth, 1945, Harvardi ülikooli meeskond tõmbas masina laiali, nad leidsid midagi, mida nad nimetasid “seitsmekümneks releeks” - neil päevil tehti programmeerimine füüsilises mõttes, te keerutasite koodi tahvli ümber ja nii programmeerisite selle efektiivselt masin - ja nad leidsid, et see relee number oli seitsekümmend, oli selles midagi valesti, ja selgub, et tegelik termin "bug" tekkis, kuna see oli sõna otseses mõttes koi - väidetavalt oli mingi vasktraaditüki vahele kiilunud koi ühest kohast teise. Ja lugu läheb nii, et legendaarne Grace Hopper tsiteerib minu pealkirja slaidi pealkirja “esimene tõeline juhtum, kus leiti viga” pealkirja.
Kuid nagu Robin oma esimeses slaidis varem rõhutas, ulatub vea kontseptsioon nii kaugele tagasi, kui võime ette kujutada, et inimesed arvutavad, kontseptsioonid nagu plaaster. Mõiste “plaaster” tuli tegelikust linditükist, mis oli teibitud üle perfokaardi augu. Kuid kogu selle mõte on see, et mõiste “silumine” tuli välja kontseptsioonist leida viga füüsilisest masinast.Ja sellest ajast peale oleme kasutanud seda terminoloogiat probleemidega tegelemisel, kasvõi mitte niivõrd kodeerimise probleemidena programmis, mis ei kompileeri, vaid kui programmi, mis ei tööta hästi. Ja spetsiaalselt pole seda profileeritud, leidke lihtsalt selliseid asju nagu lõputud ahelad, mis lihtsalt kuhugi ei lähe.
Kuid meil on ka stsenaarium ja ma arvasin, et panen paar naljakat slaidi sisse enne, kui olen natuke põhjalikumalt tutvunud. Siin on klassikaline koomiks, mida veebis nimetatakse XKCD-ks, ja karikaturistil on maailmast päris naljakaid vaateid. Ja need umbes ühe lapse kohta, kelle nimi oli "Little Bobby Tables" ja väidetavalt nimetasid tema vanemad seda noort poissi Robertiks); DROP-TABEL Õpilased; - ja selle kutsutud ja omamoodi: "Tere, see on teie poegade kool, kus on probleeme arvutiga" ja lapsevanem vastab: "Oh kallis, kas ta rikkus midagi?" Ja õpetaja ütleb: "Noh, mingil moel, ”ja õpetaja küsib,“ kas sa panid oma poja Robertiks tõesti nime); DROP-TABEL Õpilased; -? ”Ja vanem ütleb:“ Oh jah, väikseid Bobby-tabeleid kutsume talle. ”Igatahes jätkavad nad ütlemist, et nad on nüüd aastate õpilasrekordid kaotanud, ma loodan, et olete õnnelikud. Ja vastus on: “Noh, peaksite oma andmebaasi sisendid puhastama ja puhastama.” Ja ma kasutan seda mitu korda, et rääkida mõningatest probleemidest, mis meil koodide abil asju leida on, et sageli ei vaata kood ka andmeid .
Veel üks naljakas, ma ei tea, kas see on tõeline või mitte - ma kahtlustan, et see on võlts -, aga jällegi puudutab see ka minu naljakat luu. Keegi vahetab oma auto esiosa numbrimärki sarnase avaldusega, mis põhjustab andmebaaside kiiruskaamerate languse ja nii edasi, et jäädvustada autode numbrimärke. Ja ma viitan sellele alati nii, et ma kahtlen, kas keegi programmeerija eeldas nende koodi tabamust ja käivitamist tegeliku mootorsõiduki poolt, kuid ei alahinda seda kunagi - vihase geeki jõud.
(Naer)
Kuid see viib mind minu põhipunkti, ma arvan, ja see on see, et kunagi võiksime lihtsalt surelikena siluda ja profileerida. Kuid ma olen väga seisukohal, et see aeg on möödunud, ja minu kogemuse tõttu on see minu jaoks esimene - ja see vananeb mind kohutavalt, olen kindel; Robin on teretulnud mulle selle üle nalja viskama - kuid ajalooliselt on Ive pärit taustal, kus ta 14-aastaselt eksles linna otsas ja koputas Uus-Meremaal andmekeskuse nimega Data Com uksele ja küsis, kas Ma saaksin koolis taskuraha teenida sellega, et jõuan koju hilja bussiga, iga päev umbes 25 km pendelrännet, panin paberi ja lindid kettadraivi ning olen lihtsalt administraator. Ja kummalisel kombel andsid nad mulle tööd. Kuid aja jooksul õnnestus mul end personali komplekteerimisse ja programmeerijate leidmisse saada ning mõistsin, et armastan kodeerimist ja käisin läbi skriptide ja pakkimistööde käitamise protsess, mis päeva lõpuks on endiselt kood. Peate kirjutama skriptid ja pakkimistööd, mis näevad välja nagu miniprogrammid, ja seejärel läbima kogu protsessi, mis seisneb 3270-terminali käsitsi käsitsi kirjutamises.
Tegelikult oli minu kõige esimene kogemus teletüüpterminalis, mis oli tegelikult 132-veeruline füüsiline er. Mõelge põhimõtteliselt nagu väga vana kirjutusmasin, millel oleks paber läbi kerinud, sest neil polnud CRT-toru. Ja koodi silumine selles küsimuses oli väga ebaoluline küsimus, nii et kippusite kirjutama kogu koodi käsitsi ja tegutsema siis masinakirjutajana, tehes kõik endast oleneva, et sisselogimiseks vigu ei tekiks, kuna selle ütlemine on äärmiselt pettumust valmistav üherealine redaktor, et minna kindlale reale ja seejärel reale ning siis tippida see uuesti sisse. Kuid kord kirjutati koodi ja see oli see, kuidas me silusime ja saime sellega väga-väga hästi hakkama. Ja tegelikult sundis see meid olema väga heade programmeerimistehnikatega, sest selle parandamine oli tõelise vaevaga. Seejärel kulges teekond läbi - ja olid kõik sellega tuttavad - minu maailma 3270 terminali kogemusest Digital Equipment VT220, kus võis ekraanil asju näha, aga jälle tegid sa lihtsalt sama, mida tegid paberlindil omamoodi redigeeritud vormingus CRT-l, kuid teil oli võimalus seda hõlpsamini kustutada ja teil ei olnud seda heli „dit dit dit dit“.
Ja siis teate, Wyse-terminalid - nagu näiteks Wyse 150, ilmselt minu lemmikliides arvutiga - ja siis arvuti ja siis Mac ning tänapäeval veebipõhised GUI-id ja ID-d. Ja terve rida programme selle kaudu, programmeerimine ühes ja kokkupanijana ning PILOT ja Logo ja Lisp ning ja Fortran ja Pascal ning keeled, mis võivad inimesi käratsema panna. Kuid need on keeled, mis sundisid teid kirjutama head koodi; nad ei lasknud teil halbadest tavadest pääseda. C, C ++, Java, Ruby, Python - ja tõuseme sellest programmeerimisastmest veelgi üles, saame rohkem skriptilaadset, lähemale ja lähemale struktureeritud päringute keelele ja keeltele nagu PHP, mida tegelikult kasutatakse SQL-i kutsumiseks. Mõte teile öelda, et tulenevalt minu taustast olin ise mitmel moel iseõppinud ja need, mis aitasid mul õppida, õpetasid mulle väga häid programmeerimispraktikaid ja väga häid tavasid disaini ja protsesside kohta veendumaks, et ma ei tutvustanud lollakat kood.
Programmeerimismeetodid on tänapäeval näiteks struktureeritud päringute keel SQL, mis on väga võimas ja lihtne päringute keel. Kuid me oleme selle muutnud programmeerimiskeeleks ja ma ei usu tõesti, et SQL oli kunagi mõeldud moodsaks programmeerimiskeeleks, kuid me ei kavatsenud seda muuta. Ja see tutvustab tervet rida küsimusi, mis tekivad, kui mõelda kahest vaatenurgast: kodeerimise ja DBA seisukohast. See on väga lihtne kaasa tulla ja tutvustada vigu selliste asjade jaoks nagu lihtsalt halvad programmeerimistehnikad, laisad pingutused koodi kirjutamisel, kogemuste puudumine, klassikaline lemmikloomakoor, mis mul on näiteks SQL-i inimestega, kes hüppavad Google'i ja otsivad midagi ning leiavad veebisaidi. sain näite ja tegin olemasoleva koodi kopeerimise ja kleepimise. Ja siis kopeerida halb kodeerimine, väärkäitumine ja viia see tootmisse, sest see lihtsalt annab neile soovitud tulemusi. Teil on olnud ka muid väljakutseid, näiteks need päevad kiirustasid kõik selle poole, mida me nimetame võistluseks nulli poole: proovime teha kõike nii odavalt ja nii kiiresti, et meil on stsenaarium, kus madala palgaga töötajaid ei võeta. Ja ma ei pea seda silmas halvustavalt, kuid ma ei palganud eksperte igaks võimalikuks tööks. Kunagi oli arvutitega pistmist raketiteadus; see oli seotud asjadega, mis läksid sassi ja olid valjuhäälsed või läksid kosmosesse või insenerid olid kõrgelt kvalifitseeritud mehed ja naised, kes olid teinud kraade ja kellel oli range haridus, mis hoidis neid hullu asju tegemast.
Nendel päevadel on arenduse ja kujunduse ning andmebaaside loomiseks palju inimesi, kellel pole aastaid kogemusi, kellel pole tingimata olnud sama väljaõpet või tuge. Ja nii lõpetate stsenaariumi, kus on lihtsalt traditsiooniline amatöör versus ekspert. Ja kui see kuulus rida pole, ei mäleta ma tegelikult seda, kes pakkumise koostas, see rida kõlab: “Kui arvate, et eksperdi töölevõtmine on kallis, oodake, kuni palkate paar amatööri, kes tekitavad probleemi ja peate puhastage see ära. ”Ja nii on SQL-l see probleem ning seda on väga, väga lihtne õppida, väga lihtne kasutada. Kuid see pole minu arvates täiuslik programmeerimiskeel. Seda on väga lihtne teha, näiteks teha valitud täht ükskõik kust ja tõmmata see programmeerimiskeeleks, mis on teile mugavam, näiteks PHP, Ruby või Python, ja kasutada andmetega manipuleerimiseks programmeerimiskeelt, mis on teile põliselanike tuttav, selle asemel, et teha keerukamat päringut SQL-is. Ja me näeme seda palju ning siis inimesed imestavad, miks andmebaas töötab aeglaselt; sellepärast, et miljon inimest üritab piletit osta veebipõhises piletimüügisüsteemis, kus see teeb valitud tähe ükskõik kuhu.
See on tõesti äärmuslik näide, kuid saate sellest kõigest aru. Niisiis, selleks, et seda punkti koju tõesti lüüa, on siin näide, mida kannan palju ringi. Olen suur matemaatikafänn, ma armastan kaoseteooriat, Mandelbroti komplekte. Parempoolsel küljel on Mandelbroti komplekti ülekanne, millega kõik olid kindlasti tuttavad. Ja vasakus servas on SQL-i tükk, mis selle tegelikult muudab. Nüüd, iga kord, kui ma selle kuhugi ekraanile panen, kuulen seda: “Mu jumal, keegi muutis Mandelbroti seeria SQL-iga, kas sa oled tõsine? See on hull! ”Noh, kogu selle mõte on illustreerida seda, mida ma seal just visandasin, ja see on jah, tegelikult saate nüüd programmeerida SQL-is peaaegu kõike; see on väga tugevalt arenenud, võimas, moodne programmeerimiskeel. Kui algselt oli see päringute keel, oli selle eesmärk lihtsalt andmete üleslaadimine. Niisiis, nüüd on meil väga keerulised konstruktsioonid ja salvestatud protseduurid, programmeerimismetoodikat on ka keelele rakendatud ja seega on see väga lihtne halva programmeerimispraktika, kogemuste puudumise, koodilõigatud ja kleepitava koodi korral, madalapalgalised töötajad, kes proovivad olla kõrgepalgalised töötajad, inimesed teesklevad, et nad teavad, kuid nad peavad töökoha peal õppima.
Terve rida asju, kus koodiprofiilimist ja mida me nimetame silumiseks, mis pole mitte niivõrd vigade otsimine, mis peatavad programmide töötamise, vaid vead, mis lihtsalt kahjustavad süsteemi, ja halvasti struktureeritud kood. Kui nüüd seda ekraani vaatate ja arvate, et see on just selline armas, siis mõtlete: "Vau, kui suurepärane graafika, mulle meeldiks seda juhtida." Kuid kujutage ette, et see töötab mingil äriloogikal. See näeb välja üsna kena, kuid räägib matemaatiliselt graafiliselt esitatud kaoseteooriast, kuid kui mõelda, milleks seda võiks mõnes äriloogikas kasutada, saate pildi väga kiiresti. Ja selle tõeliseks illustreerimiseks - ja mul on kahju, et värvid on vastupidised, see peaks olema must taust ja roheline olema roheline ekraan, kuid te saate seda ikkagi lugeda.
Läksin ja vaatasin kiirelt näidet sellest, mida te võiksite teha, kui olete tõesti hull, kui teil pole mingeid kogemusi ning tulete programmeerimise teistsugusest taustast ja rakendasin CQL + -i SQL-ile, et minu nägemust reaalselt illustreerida Annan üle meie õpitud külalisele IDERA-st. See on struktureeritud päring, mis on kirjutatud nagu C ++, kuid mille kood on SQL. Ja see täidetakse tegelikult, kuid see täidetakse umbes kolme kuni viie minuti jooksul. Ja see tõmbab näiliselt tagasi ühe andmerea mitmest andmebaasist, mitmest liitumisest.
Jällegi, kogu selle mõte on see, et kui teil pole õigeid tööriistu, kui teil pole õigeid platvorme ja keskkondi, et neid asju tabada, ja nad hakkavad tootma, siis on teil 100 000 inimest, kes löövad süsteemi iga kord Päev, tund või minut, jõuate peagi Tšernobõli-elamuse juurde, kus suur raud hakkab sulama ja matma end planeedi tuuma, sest see kooditükk ei tohiks kunagi tootmisesse sattuda. Vabandage, teie süsteemid ja tööriistad peaksid selle valima enne, kui see kuskile lähedale jõuab - isegi testimisprotsessi kaudu, isegi UAT-i ja süsteemide integreerimise kaudu, see kooditükk tuleks üles tõsta ja esile tõsta ning keegi kõrvale viia ja öeldes: "Vaata, see on tõesti ilus kood, kuid võimaldab saada DBA, mis aitab teil seda struktureeritud päringut korralikult üles ehitada, sest ausalt öeldes on see lihtsalt vastik." Ja seal olevad URL-id võite minna ja vaadata - sellele viidatakse kui kõige keerulisem SQL-i päring, mille olete kunagi kirjutanud. Sest uskuge mind, see, mis tegelikult kompileerib, töötab. Ja kui te selle lõikate ja kleepite ning lihtsalt andmebaasi pilkate, on seda üsna palju vaadata; kui teil on andmebaasi jälgimiseks vajalikud tööriistad, proovige lihtsalt kolme kuni viie minuti jooksul sulada, et tagasi helistada, mis on üks rida.
Niisiis, seda kõike kokku võttes, on minu kogu kodeerimise taust mulle õpetanud, et võite anda inimestele relva ja kui nad pole ettevaatlikud, lasevad nad end jalaga maha; trikk on neile näidata, kus turvamehhanism asub. Õigete tööriistade ja käepärast oleva tarkvara abil saate pärast kodeerimise lõpuleviimist oma koodi üle vaadata, võite leida probleeme profiili profileerimise abil, võite leida tõhususevastaseid probleeme põhjustavaid tahtmatuid vigu ja nagu ma juba varem ütlesin kunagi võiksite seda teha, vaadates rohelist ekraani. Sa ei saa enam; seal on sadu tuhandeid koodiridasid, kasutusele on võetud kümneid tuhandeid rakendusi, mõnel juhul on miljoneid andmebaase ja isegi superinimesed ei saa seda enam käsitsi teha. Teil on sõna otseses mõttes vaja käepärast õiget tarkvara ja õigeid tööriistu ning teil on vaja, et meeskond neid tööriistu kasutaks, et saaksite need probleemid leida ja väga kiiresti lahendada, enne kui asja juurde jõuate, samas kui Dr. Robin Bloor tõstis esile, asjad muutuvad kas hukatuslikuks ja asjad puhkevad laiali või sagedamini hakkavad nad teile lihtsalt maksma palju dollareid, palju aega ja vaeva ning hävitama moraali ja muud, kui nad ei suuda välja mõelda, miks asjad võtavad. pikk aeg joosta.
Ja seda silmas pidades annan ma meie külalisele üle ja ootan huviga, kuidas nad selle probleemi lahendasid. Ja eriti see demo, mida ma arvan, et kohe kätte saadi. Eric, ma lähen tagasi.
Eric Kavanagh: OK, Bert, vii see ära.
Bert Scalzo: OK aitäh sulle. Bert Scalzo siin IDERA-st, meie andmebaasitööriistade tootejuht. Ja ma räägin silumisest. Ma arvan, et üks olulisemaid asju, mida Robin varem ütles - ja selle kõige õigem on silumine on koormav ja mitte triviaalne ning andmebaaside silumiseks minnes on selle suurusjärk veelgi koormavam ja mitte triviaalne - nii, et oli oluline tsitaat.
OKEI. Tahtsin alustada programmeerimisajaloost, sest palju kordi näen inimesi, kes ei silu, nad ei kasuta silurit, nad programmeerivad lihtsalt ükskõik millist keelt, mida nad kasutavad, ja sageli ütlevad nad mulle: "Noh, need silumisasjad on uued ja me pole neid veel kasutama hakanud. ”Ja see, mida ma teen, on see, et ma näitan neile seda ajaskaala diagrammi, omamoodi eellugu, vanadust, keskaega, seda, kuidas me olime programmeerimiskeelte terminid. Ja meil olid väga vanad keeled, alates 1951. aastast koos montaažikoodiga, Lisp, FACT ja COBOL. Siis jõuame järgmisse rühma, Pascals ja Cs, ja siis järgmisse rühma, C ++, ja vaatame, kus see küsimärk asub - see küsimärk on umbes paremal umbes 1978. aastast 1980. aastani. Võib-olla kuskil selles vahemikus silurid, mis on meile kättesaadavad ja nii öelda: "Kuule, ma ei kasuta silurit, see on ju üks neist uutest asjadest," siis pidi te juba programmeerimisega alustama, teate juba 1950ndatel, et see on ainus viis, kuidas saate selle nõudega ära.
Teine asi, mis selles diagrammis naljakas on, on Dez just kommentaar Grace Hopperi kohta, ma teadsin tegelikult Grace'i, nii et see on selline naljakas. Ja siis teine asi, mille üle ma naersin, on see, et ta rääkis teletüüpidest ja seal istudes minnes: "Inimene, see oli suurim hüpe, mis meil tootlikkuses läbi aegade olnud, kui kaartidelt teletüüpidesse läksime, see oli kõigi aegade suurim hüpe." , ja Ive programmeerisid kõigis siinsetes keeltes, sealhulgas SNOBOL, millest kunagi varem keegi ei kuulnud. See oli CDC, Control Data Corporation, seega arvan, et olen selle tööstuse jaoks natuke liiga vana.
Dez Blanchfield: Ma tahtsin öelda, et sa oled meid seal kohutavalt vanandanud.
Bert Scalzo: Jah, ma ütlen teile, ma tunnen end nagu vanaisa Simpson. Niisiis vaatlen silumist ja silumise erinevaid viise. Võiksite rääkida sellest, mida me kõik arvame traditsiooniliseks siluriks saamisest ja koodi lugemisest. Kuid ka inimesed hakkavad oma koodi seadistama; see on see, kuhu kleebitakse avaldused oma koodi ja võib-olla toodetakse väljundfail, jäljendifail või midagi muud, ja nii saate oma koodi kasutada. Ma arvaksin, et silumiseks on see natuke raskem viis, kuidas seda teha, kuid see loeb. Kuid ka meil on kuulus avaldus: vaatate ja inimesed panevad avaldused tegelikult sisse ja ma nägin tegelikult tööriista, kus - ja selle andmebaasi tööriista - kui te ei tea siluri kasutamist, siis vajutate nuppu ja see jääb kleepima avaldused kogu koodi jaoks teie jaoks ja kui olete valmis, siis vajutate veel ühte nuppu ja see võtab need välja. Sest see on see, kuidas paljud inimesed siluvad.
Ja silumist on kahel põhjusel: esiteks pidime leidma asju, mis muudavad meie koodi ebaefektiivseks. Teisisõnu, see tähendab tavaliselt loogikaviga või jätsime ärinõude täitmata, kuid mis see on, on see, et kood pole efektiivne; see ei tee seda, mida me eeldasime seda tegema. Teine kord, kui me läheme ja teeme silumist, on selle tõhusus ja see võib olla loogikaviga, kuid mis see on, kas ma tegin õigesti, see ei tule lihtsalt piisavalt kiiresti tagasi. Nüüd ütlen ma selle üle, kuna profileerijad on tõenäoliselt paremad selle teise stsenaariumi jaoks ja kavatsesid rääkida nii siluritest kui ka profiilijatest. Lisaks sellele on see kaug silumise kontseptsioon olemas; see on oluline, kuna palju kordi, kui istute oma personaalarvutis ja kasutate silurit, mis tabab andmebaasi, kus koodi tegelikult andmebaasis täidetakse, teete tegelikult seda, mida nimetatakse kaug silumiseks. Te ei pruugi sellest aru saada, kuid see juhtub juhtuma. Ja siis on nende siluritega väga tavaline, et neil on murdepunkte, vaatluspunkte, sisse astumist ja üle minemist ning mõnda muud tavalist, mida ma kavatsen hetkega ekraanil ekraanipildil näidata.
Profiilimine: profileerimist saab teha mitmel erineval viisil. Mõned inimesed ütlevad, et töökoormuse hõivamine ja kordus, kus see hõlmab kõike, mida loetakse profileerimiseks. Minu kogemus on olnud parem, kui proovide võtmine oleks parem. Pole mingit põhjust iga üksiku väite järele jõuda, sest mõned avaldused võivad lihtsalt nii kiiresti joosta, et te ei hooli sellest, mida tegelikult proovite näha, ja mis on need, mida näidatakse ikka ja jälle, sest need käivad liiga kaua . Nii et mõnikord võib profiilide koostamine tähendada pigem proovide võtmist kui kogu asja ajamist. Ja tavaliselt saate mingi väljundi, mida saate kasutada, nüüd see võiks olla visuaalne IDE arenduskeskkonnas, kus see võib teile anda nagu koodiridade toimivuse histogramm, kuid see võib siiski ka olgu siis, et see loob jäljendifaili.
Profilerid ilmusid esmakordselt 1979. aastal. Niisiis, ka need on olemas olnud pikka aega. Suurepärane ressursitarbimise või jõudlusprobleemide, teisisõnu selle efektiivsuse asja leidmiseks. Üldiselt on see eraldi ja silurist erinev, ehkki olen töötanud siluritega, mis teevad mõlemad korraga. Ja kuigi minu arust on profileerijad kahest tööriistast huvitavamad, kui ma leian, et silumist ei tee piisavalt inimesi, siis kindlasti mitte piisavalt inimesi, sest näib, et üks kümnest silurist profiilib. Ja see on häbi, sest profiilide koostamine võib tõesti tohutult palju kaasa aidata. Nüüd, nagu me varem rääkisime, said andmebaasikeeled SQL-i - ja omamoodi sundisid ümmarguse pingi siinse ruudukujulisse auku ja sundisid sellest saama programmeerimiskeel - ning Oracle.See on PL / SQL - see on protseduurikeel SQL - ja SQL Server, selle Transact-SQL, selle SQL-99, selle SQL / PSM - minu jaoks, selle protseduurimoodul. Postgres annab sellele uue nime, DB2 veel ühe nime, Informix, kuid mõte on selles, et kõik on sundinud 3GL-tüüpi konstruktsioone; Teisisõnu, FOR-silmused, muutuvate deklaratsioonide juures ja kõik muud SQL-i jaoks võõrad asjad on nendes keeltes nüüd SQL-i osa. Ja nii, peate saama PL / SQL-i või Transact-SQL-i siluda samamoodi nagu Visual Basicu programmi.
Nüüd andmebaasiobjektid, see on oluline, sest inimesed ütlevad: “Noh, mida ma pean andmebaasis siluma?” Ja vastus on, et noh, mida iganes andmebaasis koodina salvestada saab - kui teen T- SQL või PL / SQL - ja objektide hoidmine andmebaasis, tõenäoliselt selle salvestatud protseduur või funktsioon. Kuid ka need käivitavad: päästik on omamoodi nagu salvestatud protseduur, kuid see käivitub mingil juhul. Nüüd panevad mõned inimesed päästikutesse ühe rea koodi ja kutsuvad salvestatud protseduuri, et nad säilitaksid kogu oma salvestatud koodi ja protseduurid, kuid selle mõiste on sama: selle päästik võiks ikkagi olla see, mis kogu asja algatab. Ja siis kui Oracle, on neil midagi nimega pakett, mis on omamoodi raamatukogu moodi, kui soovite. Panite 50 või 100 salvestatud protseduuri ühte rühma, mida nimetatakse paketiks, nii et see on nagu raamatukogu. Niisiis, siin on siluri vana moodi; see on tegelikult tööriist, mis tegelikult siseneb ja kleebib kõik need silumisavaldused teie koodi enda eest. Nii et kõikjal, kus näete silumisplokki, ärge eemaldage, automaatse siluri käivitamine ja jälgimine, need kõik olid mõne tööriista külge kinni jäänud. Ja sellest väljaspool olevad read, mis on koodi vähemus, tähendavad hästi mitte-käsitsi silumismeetodit.
Ja põhjus, miks ma selle üles tõstatan, on see, et kui proovite seda käsitsi teha, kirjutate tegelikult kõigi nende avalduste sisestamiseks rohkem silumiskoodi, kui olete selle koodiga. Ehkki see võib toimida ja on parem kui mitte midagi, on see silumiseks väga keeruline viis, eriti kuna kuna selle asja käivitamiseks kulub kümme tundi ja kui sellel on probleem, on see kolmas rida? Kui ma teeksin interaktiivset silumisseanssi, oleksin juba kolm - viis minutit sellest teada saanud - hei, siin on probleem, võin loobuda. Kuid sellega pidi Ive ootama, kuni see käivitub, kuni ehituse lõpuni, ja siis tuli Ive vaadata mingit jälitusfaili, millel on arvatavasti kõik need väited, ja proovida leida nõel heinakuhjast. See on jällegi parem kui mitte midagi, kuid see poleks parim viis töötamiseks. Nüüd näeb see fail välja selline, mis eelmisest slaidist tuli; teisisõnu, ma käivitasin programmi ja selle lihtsalt on selles jälitusfailis hunnik avaldusi ning võib-olla ei pruugi ma olla võimeline sellest läbi sirvima ja leidma selle, mis mul vaja on. Nii et jällegi pole ma kindel, et see on nii, nagu te tahaksite töötada.
Nüüd on interaktiivsed silurid - ja kui olete programmide kirjutamiseks kasutanud midagi Visual Studio'i või Eclipse'i, siis on teil olnud siluri ja te kasutasite neid koos teiste keeltega - ei mõelnud te neid siin oma andmebaasiga kasutada. Ja seal on tööriistu, nagu meie DB Artisan ja Rapid SQL, siin on siin Rapid SQL, millel on silur ja vasakpoolses servas võite näha, et mul on salvestatud protseduur nimega “duplikaatide kontrollimine”. Põhimõtteliselt läheb see lihtsalt nii, et lähen ja vaatan, kas mul on tabelis mitu sama filmi pealkirjaga rida. Niisiis, andmebaas on filmide jaoks. Ja parempoolsel küljel, ülemisel kolmandikul, nägi Ive oma lähtekoodi keskelt, Ive sai neid, mida nimetatakse minu kella muutujateks ja kõnede pukseerimise salvedeks, ning siis allosas sai Ive mõned väljundid. Ja mis siinjuures oluline on, kui vaadata üle see esimene punane nool ja kui ma hiirega muutuja kohal hiirega näen, siis näen tegelikult, mis väärtus sellel muutujal sellel ajahetkel on, kui ma astun läbi koodi. Ja see on tõesti kasulik, ja siis ma võin ühe rea korraga koodist läbi astuda, ma ei pea ütlema, et käivita, ma võiksin öelda, et asta rida, lase mul vaadata, mis juhtus, astuda teisel real, lasin vaadata, mis juhtus, ja Teen seda andmebaasis. Ja kuigi ma istun oma arvutis Rapid SQL-i peal ja mu andmebaas on pilves, saan ikkagi seda kaugsilumist teha ja seda siin näha ning juhtida ja siluda samamoodi, nagu tahaksin mis tahes muu keelega.
Nüüd järgmine nool seal - näete natuke nagu noolt, mis osutab paremale, selle DBMS-väljundi poole, see on see, kus praegu asub minu kursor - ehk teisisõnu, Ive astus ja on seal, kus ma hetkel olen. Niisiis, kui ma ütlen: "Astuge uuesti", lähen järgmisele reale. Nüüd veidi allpool näete punast punkti. Noh, see on murdepunkt, mis ütleb: "Hei, ma ei taha neist joontest üle astuda." Kui tahan kõigest üle hüpata ja jõuda sinna, kus see punane punkt on, siis võin vajutada käivitusnuppu ja see võib siit edasi joosta kas või lõppu või murdepunkti, kui mingid murdepunktid on seatud, siis see peatub ja lubab mul uuesti teha. Ja see on nii oluline kui ka võimas põhjus, et seda kõike tehes muutuvad kõik, mis toimub keskel ja isegi põhjas, aga mis kõige tähtsam, keskel - ja ma näen oma muutujate väärtusi, oskan vaadake minu kõnepakkumiste jälge, teate, ja kogu see teave kuvatakse seal kui koodist läbi astudes, nii et tegelikult näen ja tunnen ning saan aru, mis toimub ja kuidas kood tegelikult täitmise ajal töötab . Ja tavaliselt leian probleemi, kui see on olemas, või kui olen piisavalt hea, et seda leida.
OK, nüüd hakkan rääkima profiiliprofiilist ja sel juhul on see profiiliprofiil, mida näen siluri kaudu. Mäletate, ma ütlesin, et mõnikord on nad eraldi ja mõnikord võivad nad koos olla? Sel juhul ja jällegi olen Im Rapid SQL-is ning näen vasakpoolses servas veergude kõrval veergu. Mis see on, see on sekundite või mikrosekundite arv, mis kulus iga koodirea täitmiseks, ja ma näen, et selgelt kulub kogu minu aeg sellele ühele FOR-ahelale, kus ma valin kõik tabelist. Ja nii, selle FOR-ahela sees toimuvad veekogudes on ilmselt midagi, mida ma peaksin vaatama, ja kui ma saan seda paremaks muuta, maksab see dividende. Ma ei saa parendusi, töötades nende liinide peal, millel on näiteks 0,90 või 0,86; seal pole palju aega veedetud. Nii sel juhul kui ka jälle Rapid SQL-is, näete, kuidas saaksin silumisse segatud profiilide koostamist teha. Rapid SQL lubab teil seda teha ka teistmoodi. Rapid SQL lubab teil öelda: “Teate mida? Ma ei taha siluris olla, tahan seda lihtsalt käivitada ja siis tahan vaadata sama tüüpi teavet graafiliselt või visuaalselt. ”
Ja näete, et ma pole enam silur ja töötab programm ja pärast täitmise lõppu annab see mulle diagrammid, et mulle asju öelda, nii et näen, et Ive sai ühe avalduse, mis näib, et see võtab suurema osa pirukast diagrammi ja kui ma vaatan, näen sellel ruudustikul alumist rida 23, seal jälle FOR-silmus: ta võtab kõige rohkem aega, tegelikult on ta seda, et tumepunane närib kogu tabelit. Ja nii, see on veel üks viis profiilide koostamiseks. Juhtumisi kutsume seda tööriista koodianalüütikuks. Kuid see on põhimõtteliselt silurist eraldatud profiilija. Mõnele inimesele meeldib seda teha esimesel viisil, mõnele meeldib seda teha teistmoodi.
Miks me silume ja profileerime? Selle põhjuseks pole see, et tahame kirjutada maailma suurima koodi ja saada töötasu - see võib olla meie põhjus, kuid see pole tegelikult põhjus, miks te seda teete - lubasite ettevõttele, et teete midagi õigesti, et teie programm on tõhus. See on see, mille jaoks silurit kasutama hakkate. Lisaks äriklientide lõpptarbijad; nad pole eriti kannatlikud: nad tahavad tulemusi juba enne klahvi vajutamist. Pidi lugema nende meelt ja tegema kõik silmapilkselt. Teisisõnu, see pidi olema tõhus. Ja nii, see on see, mille jaoks me kasutaksime profilerit. Ilma nende tööriistadeta usun nüüd, et see kutt on sul vööri ja noolega ülikonnas, kui sa lased sihtmärgile ja sul on silmad kinni. Sest kuidas te leiate, kuidas programm käivitub, vaadates lihtsalt staatilist koodi, ja kuidas te kavatsete välja mõelda, milline rida asub seal, kus see tegelikult kõige rohkem aega täitmiseks kulutaks, jälle lihtsalt staatilist koodi vaadates? Koodide ülevaade võib mõnda neist asjadest ilmneda või mitte, kuid see ei taga, et koodide ülevaade neid kõiki leiaks. Siluri ja profiiliprofiili abil peaksite need vead leidma.
OK, ma lihtsalt teen siin tõelise kiire demo. See pole minu eesmärk toote levitamiseks, vaid tahan teile näidata, kuidas silur välja näeb, sest inimesed ütlevad palju kordi: “Ma pole kunagi varem ühtegi neist näinud.” Ja see näeb ekraanil kuvatavate slaididena ilus välja, aga mis kas see näeb välja, kui see liikuma hakkab? Niisiis, siin ekraanil töötan ma meie DB Artisani tootega; meil on silur ka seal. DB Artisan on mõeldud rohkem DBA-dele, Rapid SQL rohkem arendajatele, kuid olen näinud arendajaid, kes kasutavad DB Artisanit, ja Ive - DBA-sid, kes kasutavad Rapidit. Niisiis, ärge saage toote järele. Ja siin on mul valida, kas teha silumine, kuid enne silumise käivitamist ekstraheeritakse see kood, et saaksite enne koodi käivitamist näha, kuidas see kood välja näeb. Niisiis, siin on täpselt sama kood, mis oli ekraanipildis, see on minu kontroll duplikaatide üle. Ja ma tahan seda siluda, seepärast vajutan silumist. Ja nüüd, võtab hetk aega ja ütled: “Noh, miks see võtab hetkeks?” Pidage meeles silumisest kauga: silumine toimub tegelikult minu andmebaasiserveris, mitte minu arvutis. Niisiis, see pidi üle minema ja looma sinna seansi, looma kaugsilumise asja, ühendama minu seansi selle kaugsilumisseansi külge ja seadistama suhtluskanali.
Niisiis, siin, minu nool, see on ülaosas ülaosas, on see, kus ma koodis olen. Ja kui ma vajutan sinna kolmanda ikooni, mis on samm sisse, näete, et see nool lihtsalt liikus, ja kui ma jätkan selle vajutamist, näete, et see liigub. Nüüd, kui ma tahaksin selle FOR-i ahelani täielikult minna, kuna ma tean, et selles on probleem, saan ma määrata murdepunkti. Ma arvasin, et panin selle paika. Oh tulista, mul oli üks ekraanipüüdmisklahvidest sama klahviga nagu silur, mis aga põhjustab segadust. OK, nii et seadsin sinna lihtsalt käsitsi murdepunkti, nii et selle asemel, et teha üks samm, samm, samm, samm kuni sinna jõudmiseni, võin tegelikult öelda lihtsalt: "Minge edasi ja jooksege seda asja", ja see peatub. Pange tähele, et see viis mind täiesti murdepunkti juurde, nii et olen nüüd selle ahela käitamisega kursis, näen, millele kõik mu muutujad on seatud, mis pole mingi üllatus, kuna initsialiseerisin need kõik null. Ja nüüd ma võin sellesse ahelasse astuda ja hakata uurima, mis selle silmuse sees toimub.
Niisiis, nüüd läheb see minu üüride hulgast valitud arvu järgi ja ma võin hiirega selle mehe üle hiirega vaadata ja vaadata, kas ta on kaks, kaks on suurem kui üks, nii et tõenäoliselt kavatseb selle koodi järgmine osa teha. Teisisõnu, see leidis midagi. Ma lihtsalt lähen edasi ja lasen sellel joosta. Ma ei taha siin kõike läbi vaadata; mida ma tahan teile näidata, on see, kui silur on tehtud, see lõpeb täpselt nagu tavaline programm. Ive sai murdepunkti seatud, nii et kui ma ütlesin, et jooks, läks see lihtsalt tagasi järgmisse murdepunkti. Lastes sellel lõpuni töötada, põhjustab see, mida soovin, et näeksite, et silur ei muuda programmi käitumist: kui see töötab, peaksin saama täpselt samad tulemused, kui ma oleksin seda käivitanud mitte siluri sees.
Ja sellega seoses kavatsen demo peatada ja tagasi minna, sest tahame veenduda, et meil on aega küsimuste ja vastuste jaoks. Niisiis, ma avan selle küsimuste ja vastuste jaoks.
Eric Kavanagh: Hea küll, Robin, võib-olla küsimus sinult ja siis paarilt Dezilt?
Robin Bloor: Jah, muidugi, see on minu jaoks muidugi põnev. Ive töötas selliste asjadega, kuid Ive ei töötanud kunagi andmebaasis midagi sellist. Kas saate anda mulle idee, milleks inimesed profiili kasutavad? Kuna see on sarnane, kas nad vaatavad - sest ma eeldan, et nad on - nad vaatavad jõudlusprobleeme, kas see aitab teil vahet teha, millal andmebaas võtab aega ja millal kood võtab aega?
Bert Scalzo: Tead, see on fantastiline küsimus. Ütleme, et töötan Visual Basicus ja mina, kes oma Visual Basicus töötan, helistab Transact-SQL-i või PL / SQL-i. Lubage mul teha PL / SQL, kuna Oracle ei mängi alati Microsofti tööriistadega hästi. Võib-olla profileerin oma Visual Basici koodi ja sealne profiil võib öelda: “Kuule, ma nimetasin seda salvestatud protseduuri ja see võttis liiga kaua aega.” Kuid siis võin minna salvestatud protseduuri ja saan teha talletatud andmebaasi profiili protseduuri ja öelge: “OK, sajast siin olevast avaldusest on siin viis neist, mis probleemi põhjustasid.” Ja nii võib juhtuda, et peate tegema sildirühma, kus peate kasutama mitut profiilijat.
Idee on see, kui teile kunagi öeldakse, et teie andmebaasis on toimivusprobleemid, võib andmebaasiprofiil aidata teil leida nõela heinakuhjast, mille kohta avaldused on tegelikult need, kus teil on probleem. Ma ütlen teile veel ühe asja, mis ilmnes profiilide koostamisel: kui teil on mingi kooditükk, mida kutsutakse miljon korda, kuid see võtab ainult mikrosekundi miljonit korda, kuid seda nimetatakse miljon korda, siis mida profiiliprofiil näitaks , see asi kestis selle paljude ajaühikute vahel. Ja ehkki kood võib olla ülimalt tõhus, võite vaadata ja öelda: “Oh, helistades sellele kooditükile liiga sageli. Võib-olla peaksime seda kutsuma ainult nii sageli, mitte iga kord, kui töötleme salvestust ”või midagi muud. Ja nii saate tegelikult leida, kus on tõhusad koodid, mida nimetatakse lihtsalt liiga sageli, ja see on tegelikult jõudlusprobleem.
Robin Bloor: Jah, see on imeline. Ma pole seda kunagi teinud. Muidugi näete, kui mul oli andmebaasiprobleeme, oli see nii, nagu tegeleksin ühel või teisel viisil andmebaasiga või koodiga; Ma ei saaks kunagi mõlemaga korraga hakkama. Kuid jällegi ei teinud ma seda - Ive pole kunagi tegelenud selliste rakenduste ehitamisega, kuhu meil oli protseduure salvestatud, nii et ma arvan, et Ive ei sattunud tegelikult kunagi probleemide hulka, mis mind vaenlaseks ajasid, mõttega, et peate koodi jagama andmebaas ja programm. Aga nii, tehke kõik - eeldan, et vastused on jah, kuid see on osa arendusmeeskonna tegevusest, kui proovite ühel või teisel moel midagi katkist parandada või proovite võib-olla tuua uue rakenduse. Kuid kas see sobib kõigi teiste komponentidega, mida ma keskkonnas eeldan? Kas ma eeldan, et saan selle kokku lüüa koos kõigi oma proovipakkide ja kõigi muude asjadega, mida ma teeksin, ja projektijuhtimise asjadega, siis kuidas see kõik kokku klammerdub?
Bert Scalzo: Jah, teie programmeerimis- või arendustegevuseks võib saada osa igast struktureeritud protsessist. Ja naljakas, et eelmisel nädalal oli mul üks klient, kes ehitas veebirakendust, ja nende andmebaas oli ajalooliselt olnud väike ja see, et nad olid väga head programmeerijad, ei teinud neile kunagi haiget. Noh, nende andmebaas on aastatega kasvanud ja nüüd kulub veebilehel 20 sekundit, kui ütlete: “Logi mind sisse ja anna mulle natuke andmeid näha” ja siis, kui ekraan tegelikult üles tuleb, ja nüüd on selle oma jõudlusprobleem. Ja nad teadsid, et probleemi pole üheski nende Java-s ega mujal. Kuid neil oli tuhandeid salvestatud protseduure ja seetõttu pidid nad alustama salvestatud protseduuride profileerimist, et teada saada, miks selle veebilehe ilmumiseks kulub 20 sekundit? Ja me leidsime, et neil oli kartesilane ühinenud ühe valitud avaldusega ega teadnud seda.
Robin Bloor: Vau.
Bert Scalzo: Kuid keegi ütles mulle üks kord: “Noh, kuidas nad võisid Cartesiaga ühineda ja seda mitte teada?” Ja see kõlab tõesti õudselt; Mõnikord teeb programmeerija, kes pole SQL-iga eriti rahul, midagi sellist, nagu annab mulle Cartesiuse liitumise, kuid annab mulle siis alles esimese kirje tagasi, nii et ma tean, et sain midagi ja vajan ainult esimest. Ja nii, nad ei saa aru, et nad tõid just miljard plaati tagasi või vaatavad läbi miljard plaati, sest nad said just selle, mis neid huvitas.
Robin Bloor: Vau, ma tean, see, mida nimetatakse - noh, see on see, milles Dez käis - nende inimeste osas, kes pole just nii osavad, kui nad ehk peaksid olema, teate. Kui olete programmeerija, peaksite teadma, milline on mis tahes käsu väljaandmine. Ma mõtlen, et tegelikult pole see rumaluse tase vabandus. Samuti eeldan, et olete ühel või teisel viisil lihtsalt keeleagnostik, kuna see kõik keskendub andmebaasi poolele. Kas mul on selles õigus? Kas see on täpselt sama, ükskõik, mida te kodeerimise poolel kasutate?
Bert Scalzo: Absoluutselt saate seda teha Fortranis või C või C ++. Mõnes Unixis saate seda teha isegi nende skriptikeelte jaoks; nad pakuvad tegelikult samu tööriistu. Ja siis tahan hetkeks tagasi pöörduda selle järele, mida te ütlesite, vabanduseta. Ma teen programmeerijatele ühe pausi, sest mulle ei meeldi programmeerijate bussi alla viskamine. Kuid probleem on tegelikult akadeemilises keskkonnas, sest kui hakkate õppima programmeerijaks, õpetati teile korraga mõtlemist. Teile ei õpetata komplektmõtlemist ja just see töötab struktureeritud päringukeel ehk SQL komplektidega; see on põhjus, miks meil on liit, ristmik ja miinus operaator. Ja see on mõnikord väga raske inimesele, kes pole kunagi komplektide osas mõelnud - loobuda, korraga lahti võtta töötlemisest ja töötada komplektidega.
Robin Bloor: Jah, ma olen sinuga selles suhtes. Ma mõtlen, et nüüd saan aru, et see on haridusküsimus; Ma arvan, et see on täiesti haridusküsimus, ma arvan, et programmeerijatele on loomulik, et ta mõtleb protseduuriliselt. Ja SQL pole protseduuriline, selle deklaratiivne. Tegelikult ütlete lihtsalt: "Seda ma tahan ja ma ei hooli sellest, kuidas te seda teete," kas teate? Kui programmeerimiskeeltega olete tihtipeale oma varrukad üles keeranud ja isegi loenduste haldamise pisiasjadesse lasknud, samal ajal kui teete silmust. Haige käsi ...
Bert Scalzo: Ei. Jätka.
Jah, ma tahtsin öelda, et te tõite ühe teise näite, et profiiliprofiilil oleks hea kinni püüda, selline jätkub selle korraga töötlemisega. Mõnikord ei suuda programmeerija, kellel on hea rekorditeabe loogika, aru saada, kuidas SQL-i programmi teha. Ütleme nii, et ta teeb kaks FOR-i silmust ja põhimõtteliselt teeb liitumise, kuid ta teeb seda kliendi poolel. Niisiis, ta teeb sama efekti nagu liitumine, kuid teeb seda ise ja mõni profiil püüab seda kinni pidada, sest tõenäoliselt kulutaksite rohkem aega liitumise käsitsi tegemisele kui lasete andmebaasiserveril seda teie heaks teha.
Robin Bloor: Jah, see oleks katastroof. Ma mõtlen, et sa lihtsalt viskad ringi. Thrashings on alati halb.
Igatahes, saan Dezile edasi; Olen kindel, et tal on huvitavaid küsimusi.
Dez Blanchfield: Tänan teid, jah, teen küll. Ma kavatsen teiega ühineda sellega, et ei hakka programmeerijaid bussi alla viskama. Ma mõtlen, et veetsin Ive oma elus liiga palju aastaid, et olla ise kodeerija. Igal tasandil teate, kas see on nii, nagu te ütlesite, istudes Unixi masina käsureal ja mõnel juhul olin isegi seotud paar erinevat Unixi porti ühest riistvaraplatvormist teise. Ja võite ette kujutada, milliseid väljakutseid meil seal oli. Reaalsus on aga siin selline, et vangistusega kaart saadakse igale maailma kodeerijale ja stsenaristile. See on raketiteadus, üsna sõna-sõnalt, see, et kirjutate iga kord ja alati tihedalt, on raketiteadus. Ja kuulsad lood inimestest nagu Dennis Ritchie ja Brian Kernahan, kes töötavad iseseisvalt mõne kooditüki kallal ja astuvad seejärel kohvivalmis koodi ülevaatamise vestlusele ning saavad teada, et nad on kirjutanud täpselt sama kooditüki, täpselt samasse programmi, täpselt samamoodi. Ja nad tegid seda C-s. Kuid programmeerimise puristlik tase eksisteerib väga harva.
Fakt on see, et iga päev on seal vaid 24 tundi päevas, seitse päeva nädalas ja peame lihtsalt asjad korda ajama. Ja kui rääkida mitte ainult traditsioonilistest programmeerijatest, DBA-dest ja kodeerijatest ning skriptidest ja sysadminidest, võrguadministraatoritest ja turvatöötajatest ning kõigest, mis tänapäeval toimub kodanike andmete poolel; Kuuleme, et igaüks proovib lihtsalt oma tööd teha. Ja nii et ma arvan, et kogu selle asja juures on suur kaasavõtmine see, et ma armastasin teie demonstratsiooni ja ma armastasin just seda hetke, kui jätsite meid sinna, just hetk tagasi, rääkides Robiniga tõsiasjast, et sellel on eriline roll - võib-olla mitte nii palju nišš - kuid lai ruum, millele see kehtib, kui see on koodi ja SQL-i ning andmebaaside fikseerimine. Kuid mul oli tõesti hea meel kuulda teid ütlemas, et võite seda koputada skripti abil ja leida mõned probleemid, sest teate, et tänapäeval töötasid vanus ja vanus alati kõige madalama hinnaga.
6-dollarise särgi saab kuskilt osta, kuna keegi ehitas süsteemi piisavalt odavalt, et seda 6-dollarilise särgi saamiseks toota ja tarnida ning logistiliselt tarnida ja müüa ning jaemüüki teha ja veebimakseid teha. Ja seda ei juhtu, kui olete saanud inimestele 400 000 dollarit aastas, et nad kirjutaksid koodi täiuslikul viisil; selle lihtsalt kogu arendus. Niisiis, ma arvan, et üks küsimus, mis mulle tõesti meeldib, et te meile vaid natuke rohkem mõistaksite, on see, kui lai ja ulatus on nende inimeste seas, keda praegu näete ja kes kasutavad seda tüüpi tööriistu koodi profiilimiseks ja kuvamiseks esinemisküsimuste jaoks? Algselt, ajalooliselt, kust nad pärit on? Kas need on olnud suured insenerimajad? Ja kui edasi minna, kas see on nii, siis kas olen õigesti mõelnud, et üha enam ettevõtteid rakendab seda tööriista või neid tööriistu, et proovida ja aidata koodijaid, kes teavad, kes alles teevad tööd, et töö valmis saada ja viia see uksest välja? Ja mõnikord vajame vanglast väljumise kaarti? Kas mul on õigus, kui arvasin, et ajalooliselt oli meil rohkem insenerifookus ja areng? Kas nüüd, nagu Robin ütles, oli vähem akadeemilist lähenemist ja nüüd iseõppinud ehk lõigatud ja kleepitavat koodi või lihtsalt asju üles ehitatud? Ja kas see sobib nende inimestega, kes seda toodet praegu kasutavad?
Bert Scalzo: Jah, täpselt nii. Ja ma annan teile väga konkreetse näite, me tahame lihtsalt töö ära teha, sest ärimehed ei taha täiuslikkust. See on omamoodi nagu arvutimäng: malemäng ei otsi täiuslikku vastust; see otsib vastust, mis on mõistliku aja jooksul piisavalt hea, nii et see, kuidas me programmeerime. Kuid mida ma praegu leian, on enamus inimesi selle asemel, et öelda, et nad tahavad oma üksuse testimisel profiili - just nii ma teeksin seda, sest ma ei näe seda aja raiskamisena - mis nüüd juhtub, et seda tehakse hiljem, mõnikord, integreerimistestide või stressitestide ajal, kui vedas. Kuid enamasti oli selle osa eskaleerumisest, kus tootmine läks korda, mõneks ajaks, võib-olla isegi aastaid ja nüüd ei tööta see hästi, ja nüüd on see hästi profiilitud. Ja see näib olevat praegu tavalisem stsenaarium.
Dez Blanchfield: Jah, ja ma arvan, et mõiste “tehniline võlg” on tõenäoliselt teiega enam kui tuttav; Ma tean Robini ja kindlasti olen. Arvan, et tänapäeval on tehnilise võla mõiste eriti reaalne asi, eriti arenevates lähenemisviisides arendusele ja süsteemide loomisele, eriti reaalse asjana ja arvestame sellega projektides. Ma tean, et meil on oma projektid nagu meediumlääts ja teised, kus kodeerimine toimub iga päev ja mitmesuguseid asju kogu Bloori grupis. Ja kui midagi ehitati, siis vaatame seda, vaatan seda ja vaatan alati selle vaatevinklist, mis mulle praegu maksma läheb, võrreldes sellega, kas ma saan selle purki ja viia see sinna välja ja siis vaadata ja vaadata, kas see asi laguneb. Ja pärandada see tehniline võlg, mille ma tean, et mul tuleb hiljem hiljem ring tagasi keerata ja parandada.
Ja ma mõtlen, et Ive tegi seda viimase seitsme päeva jooksul: Ive kirjutas paar tööriista ja skripti, Ive kirjutas paar tükki Pythoni keelt ja Ive kasutusele selle Mongo tagaossa, veendudes, et see oleks kena, puhas ja turvaline, kuid see teeb lihtsalt päringu, mida ma vajan, tehes teadmise, et vajan seda funktsiooni töötamiseks ja suurema mõistatuse juurde jõudmiseks; see on koht, kus mu tõeline valu on. Ja nii tekib teil see tehniline võlg ja ma arvan, et see pole nüüd lihtsalt juhuslik asi, ma arvan, et see on osa praegu areneva DNA-st. Inimesed lihtsalt - mitte eristamata - aktsepteerivad lihtsalt tehnilist võlga tavalise töömeetodina ja peavad seda lihtsalt kandma. See on koht, kus teil tekib tehniline võlg. Ja ma arvan, et suurepärane asi selles, mida te meile demos näitasite, oli see, et saate sõna otseses mõttes profiili panna ja vaadata, kui kaua midagi jookseb. Ja see on ilmselt üks minu lemmik asju. Ma mõtlen, et Ive ehitas tegelikult profileerimisriistad - varem ehitasime tööriistu Sedis, Lexis ja Orcis, et käivitada oma kood ja vaadata, kus silmused olid, enne kui sellised tööriistad olid saadaval - ja kui olete koodi loonud, et minna oma koodi üle vaatama , saate väga hästi hakkama, kui te ei pea oma koodi üle vaatama. Kuid praegu pole see nii. Kas seda silmas pidades on mõni konkreetne turusegment, mis võtab selle omaks rohkem kui ükski teine? Näha nagu mass -
Bert Scalzo: Jah, ma sain hakkama. Joonistan teile analoogia ja näitan teile, et mitteprogrammeerijad teevad seda kogu aeg. Põhjus, kui ma kunagi silurit õpetasin ja klassi või seanssi profileerin, küsin inimestelt: „OK, kui paljud siinolijad sisenevad Microsoft Wordi ja ei kasuta kunagi õigekirjakontrolli?” Ja keegi ei pane kätt üles, sest dokumentide kirjutamiseks me kõik teame, et võime ingliskeelseid vigu teha ja seetõttu kasutavad kõik õigekirjakontrolli. Ja ma ütlesin: “Noh, miks saab siis, kui kirjutad oma IDE-s nagu Visual Basic, sa ei kasuta silurit? See on sama asi, nagu õigekirjakontroll. ”
Dez Blanchfield: Jah, tegelikult on see suurepärane analoogia. Ma ei olnud sellele eriti mõelnud, pean tunnistama, et teen tegelikult mõne sarnase tööriista abil, mida ma kasutan. Tegelikult on üks, ODF, minu lemmik Eclipse'iga - lihtsalt lõigake ja kleepige sinna kood ja minge otsima asju, mis kohe esile tõstetakse, ja mõistes, et tegin mõnes klassikõnes kirjaviga. Ja kuna selle tööriistaga on nüüd huvitav, saate seda teha reaalajas, mitte tagasi tulla ja hiljem vaadata, mis on omamoodi tore seda kohe kätte saada. Aga jah, see on lihtsalt tekstitöötlusse viimise suurepärane analoogia, põhjustades selle huvitava äratuskõne, mis mõistab, et kui olete teinud mõned kirjavigu või isegi grammatikavea, eks?
Bert Scalzo: Täpselt nii.
Dez Blanchfield: Niisiis, kas näete nüüd rohkem uptick'i, ma mõtlen, et see on minu viimane küsimus, enne kui ma viskan meie küsimuste ja vastuste poole meie külastajate jaoks. Kui te annaksite selle kohta lähenemisviisi ümber mingisuguse soovituse - kui eeldada, et see on retooriline - kas on nii, et jõuate vara sisse ja rakendate selle enne arendamist, kui arenete? Või on asi nii, et valdavalt ehitad, kolid, midagi ehitavad, siis tulevad sisse ja profiilivad hiljem? Ma kahtlustan, et see juhtub varem sisenema ja veenduge, et teie koodid puhastatakse kohe. Või on see nii, et nad peaksid kaaluma seda oma lähetusejärgset osa?
Bert Scalzo: Ideaalis teeksid nad seda kohe, kuid kuna kõik asuvad saginas, kus nad lihtsalt said asjad korda teha, kipuvad nad seda tegema alles siis, kui nad satuvad jõudlusprobleemidesse, mida nad ei suuda lahendada, lisades rohkem protsessoreid ja mälu virtuaalmasinasse.
Dez Blanchfield: Jah. Tegelikult, kui ma suudan kiiresti, mainisite midagi huvitavat? Mainisite enne, et seda saab käivitada ükskõik kust ja selle tagaosas saab andmebaasidega rääkida. Nii et see sobib just sellise bimodaalse kontseptsiooniga, millest me praegu räägime, kohapealse / eelpealse pilve kohta, ka asjade väljanägemise järgi päeva lõpuks, kui see suudab tagantpoolt rääkida ja näha kood, see ei huvita tegelikult, kas pole?
Bert Scalzo: Täpselt, jah, saate seda pilves juhtida.
Dez Blanchfield: Suurepärane, sest ma arvan, et see on just see koht, kuhu meie uus vapper maailm liigub. Niisiis, Eric. Kavatsen nüüd teie juurde tagasi vaadata ja näha, et meil on siin paar küsimust ning ma soovin, et meie kohalolijad jääksid ikkagi meie juurde, ehkki oleme tunni möödunud.
Eric Kavanagh: Jah, siin on vähe inimesi, ma lihtsalt kommenteerin kiiresti: Bert, ma arvan, et metafoor, analoogia, mille annate õigekirjakontrollile, on ausalt öeldes geniaalne. See on blogi või kaks väärt, ausalt öeldes, sest see on hea viis, kuidas kujundada arutelu selle üle, mida te teete, kui väärtuslik see on ja kuidas peaks tõesti olema parim tava siluri kasutamiseks veebisaidil. regulaarselt, eks? Vean kihla, et kui keegi selle välja viskab, noogutavad pead, eks?
Bert Scalzo: Sest ma ütlen neile, et ma ütlen: „Miks ma kontrollin oma dokumentide õigekirja? Ma ei taha, et rumalad kirjavigu tekitaksid piinlik. ”Noh, nad ei taha, et rumalad kodeerimisvead tekitaksid piinlikkuse!
Eric Kavanagh: Õige. Jah, tõesti. Noh, inimesed, oleme siin tund ja viis minutit läbi põlenud, nii suured tänud teile kõigile, kes te seal oma aja ja tähelepanu eest olete. Arhiveerime kõiki neid veebivestlusi, tuleme julgelt igal ajal tagasi ja kontrollime neid. Parim koht nende linkide leidmiseks on tõenäoliselt techopedia.com, nii et lisage see siia siia loendisse.
Ja koos sellega kavatsesite hüvasti jätta, inimesed. Veelkord, suur töö, Bert, tänu meie sõpradele IDERA-st. Noh, räägi sinuga järgmine kord, tegelikult räägi sinuga järgmisel nädalal. Ole tubli! Headaega.