Zobrať: Hostiteľ Eric Kavanagh diskutoval o ladení a profilovaní databázy s Dr. Robinom Bloorom, Dezom Blanchfieldom a IDERAsom Bertom Scalzom.
Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.
Eric Kavanagh: Dobre, dámy a páni, je stredu o 4:00 východného času, a to samozrejme znamená.
Robin Bloor: Nemôžem ťa počuť, Eric.
Eric Kavanagh: Bol som tam pred pár dňami, takže nie ste sami. Ale téma je dnes skutočne zaujímavá. Je to druh veci, ktorú chcete uistiť, že sa odohráva na pozadí vašej spoločnosti, pokiaľ nie ste osobou, ktorá to robí. V takom prípade sa chcete ubezpečiť, že to robíte správne. Pretože hovorili o ladení. Nikto nemá rád chyby, nikto nemá rád, keď softvér prestane fungovať - ľudia sa rozčuľujú, používatelia sa dostanú nepriateľsky. To nie je dobré. Chceli sme teda hovoriť o „rýchlej reakcii: ladenie databázy a profilovanie záchrany“.
Skutočne je tu vaše miesto, naozaj ma udrite, samozrejme @eric_kavanagh.
Tento rok je horúci. A ladenie bude horúce, bez ohľadu na to. Jeho skutočne bude jedným z týchto problémov, ktoré nikdy nezmiznú, bez ohľadu na to, ako dobre sa k tomu dostaneme, vždy to budú problémy, takže kľúčom je to, ako sa dostanete na miesto, kde môžete tieto problémy rýchlo vyriešiť? V ideálnom prípade máte skvelých programátorov, skvelé prostredie, v ktorých sa príliš nedarí, ale ako sa hovorí staré príslovie: „Nehody sa stali v najlepších rodinách.“ A to isté platí aj pre organizácie. Takže, toto sa stane, stane sa to, otázkou je, aké bude vaše riešenie pre riešenie a riešenie týchto problémov?
Robin Bloor, potom náš vlastný Dez Blanchfield zdola a samozrejme náš dobrý priateľ, Bert Scalzo, z spoločnosti IDERA. A v skutočnosti, ja idem odovzdať kľúče Robinovi Bloorovi, zober ich. Podlaha je na vás.
Robin Bloor: OK. Toto je zaujímavá téma. Myslel som si, že pretože Dez bude pravdepodobne pokračovať v skutočných technikách a vojnových príbehoch o ladení, myslel som si, že Id len robí diskusiu na pozadí, aby sme mali získať úplne zaoblený obraz toho, čo sa deje. Urobil som to dlho a býval som kóder, takže je to podobné, a bol som takmer v pokušení touto prezentáciou začať voskovať text o myšlienke open source, ale myslel som, že to nechám na niekoho iného.
Tu je zoznam slávnych chýb a väčšina z nich sa dostane na špičkový zoznam v akejkoľvek krajine, v podstate všetko okrem posledných dvoch stojí najmenej 100 miliónov dolárov. Prvým z nich bol Mars Climate Orbiter, ktorý sa stratil vo vesmíre, a to kvôli problému s kódovaním, keď si ľudia zamieňali metrické jednotky s (smiechom) nôh a palcov. Pri lietadle Ariane Five Flight 501 došlo k nesúladu medzi motorom, ktorý bol nasadený, a počítačmi, ktoré mali pri spustení raketu spustiť. Viacnásobné zlyhania počítača, vybuchujúca raketa, hlavné správy. Sovietsky plynovod v roku 1982 bol vyhlásený za najväčší výbuch v histórii planéty; Nie som si istý, či to je. Rusi ukradli nejaký automatizovaný riadiaci softvér a CIA si uvedomila, že to urobia a vložia do nej chyby a Sovieti ju implementovali bez testovania. Takže vyhodili do povetria potrubie, ktoré bolo zábavné.
Morrisov červ bol kódovacím experimentom, ktorý sa zrazu stal dravým červom, ktorý obchádzal všadeprítomné škody - zjavne spôsobil škodu v hodnote 100 miliónov dolárov; to je samozrejme odhad. Spoločnosť Intel urobila slávnu chybu s matematickým čipom - matematickou inštrukciou na čipe Pentium v roku 1993 - ktorá mala stáť viac ako 100 miliónov dolárov. Program Mapy jabĺk je pravdepodobne najhorším a naj katastrofálnejším spustením všetkého, čo spoločnosť Apple kedy urobila. Ľudia, ktorí sa pokúsili použiť ho, boli, myslím, niekto, kto šiel okolo 101, a zistili, že mapa Apple hovorí, že sa nachádzali uprostred San Francisco Bay. Ľudia sa preto začali odvolávať na aplikáciu Apple Maps ako iLost. Najdlhší výpadok v roku 1990 - z hľadiska nákladov na niečo také zaujímavé - bol AT & T mimo prevádzky asi deväť hodín a pri diaľkových hovoroch to stálo asi 60 miliónov dolárov.
A ja som bol v poisťovni UK a v databáze, implementovali novú verziu databázy a začalo to vymazávanie údajov. A pamätám si to veľmi dobre, pretože som bol následne pozvaný, aby som sa kvôli tomu zúčastnil výberu databázy. A bolo veľmi zaujímavé, že vzali novú verziu databázy a mali veľa testov, ktoré urobili pre nové verzie databázy, ktoré prešli všetkými testami. Našlo sa skutočne nejasný spôsob vymazania údajov.
Takže to je všetko. Myslel som, že Id hovorí o nesúlade impedancie a vydaní SQL. Je zaujímavé, že v relačných databázach sa ukladajú údaje do tabuliek a kódovače majú tendenciu manipulovať s údajmi v objektových štruktúrach, ktoré skutočne veľmi dobre mapujú do tabuliek. A z tohto dôvodu získate, čo sa nazýva nesúlad impedancie, a niekto s tým musí nejakým spôsobom riešiť. Čo sa však skutočne deje, pretože jeden model, kódovací model a databáza iný model nie sú nijako zvlášť zarovnané. Dostanete chyby, ku ktorým by sa jednoducho nestalo, keby priemysel postavil veci, ktoré spolupracujú, čo je podľa mňa veselé. Takže v podstate, na strane kódovačov, keď získate hierarchie, môžu to byť typy, môžu to viesť k množinám, môže to byť zlá schopnosť rozhrania API, môže to byť veľa vecí, ktoré jednoducho vyhodia veci z hľadiska interakcie s databázou. Ale to, čo je pre mňa najviac, naozaj zaujímavé; vždy ma prekvapilo, že ste mali túto bariéru SQL, ktorá je tiež istým druhom impedancie takým spôsobom, že kodéry a databáza navzájom spolupracujú. Takže SQL má rozpoznávanie údajov, čo je v poriadku a má DML na výber, projektovanie a pripojenie, čo je v poriadku. Môžete s tým vyhodiť veľa možností, ako získať údaje z databázy. Má však veľmi malý matematický jazyk na vykonávanie vecí. Má to niečo z toho a toho a má veľmi málo času. Z tohto dôvodu je SQL nedokonalým prostriedkom na získanie údajov. Takže, chlapci z databázy zostavili uložené procedúry, aby mohli žiť v databáze, a dôvodom existencie uložených procedúr bolo to, že ste naozaj nechceli hádzať údaje späť a späť do programu.
Pre niektoré funkcie bola mimoriadne špecifická pre dáta, takže nejde len o referenčnú integritu a kaskádové vymazania a podobné veci. Databáza sa starala o všetky funkcie náhleho vloženia do databázy, čo samozrejme znamenalo, že funkčnosť pre aplikáciu je možné rozdeliť medzi programátor a databázu samotnú. A to spôsobilo, že implementácia niektorých druhov funkcií bola veľmi náročná, a preto náchylnejšie k chybám. To je jedna strana databázovej hry, pretože to znamená, že ste sa napríklad dostali do mnohých implementácií, že som bol zapojený do relačných databáz. Je to naozaj hrozné množstvo kódu, ktorý sa nachádza v uložených procedúrach, ktoré sa spracúvajú oddelene od kódu, ktorý sedí v aplikáciách. A zdá sa, že sa to muselo stať veľmi zvláštnou vecou, ktorá mala byť dosť inteligentná pri vykonávaní rôznych vecí.
Myslel som, že Id tiež hovorí o výkone databázy, pretože chyby výkonu sa často považujú za chyby, ale v zásade môžete mať problémové miesto v CPU, v pamäti, na disku, v sieti a problémy s výkonom môžu byť kvôli uzamknutiu. Ide o to, že kódovač sa skutočne nemusí zaujímať o výkon a databáza by v skutočnosti fungovala primerane dobre. Mal byť navrhnutý tak, aby ho kódovač nemusel vedieť. Získate však zlý návrh databázy, dostanete zlý návrh programu, dostanete súbežné miešanie pracovnej záťaže, čo môže tiež viesť k problémom s výkonom. Získate vyrovnávanie záťaže, získate plánovanie kapacity, rast údajov - to môže spôsobiť zastavenie alebo spomalenie databázy. Je to zaujímavá vec, keď sa databázy takmer naplnia, spomaľujú sa. A môžete mať problém s dátovými vrstvami, pokiaľ ide o replikáciu a potrebu replikácie a potrebu zálohovania a obnovy. To je všeobecný prehľad.
Jediné, čo by som chcel povedať, je to, že ladenie databázy môže byť iba také náročné a netriviálne - a hovorím to preto, že som to urobil veľa - a často budete pri ladení, ktoré som kedy zažil, objaviť jeho všetky situácie. je prvá vec, ktorú ste kedy videli, je neporiadok. A musíte sa pokúsiť prejsť z neporiadku, aby ste zistili, ako k neporiadku došlo. A často, keď sa pozeráte na problém s databázou, všetko, čo sa pozeráte na, je poškodené údaje a myslenie: „Ako sa to do pekla stalo?“
Každopádne odovzdám Dezovi, ktorý pravdepodobne povie viac slov múdrosti, ako som vyšiel. Neviem, ako ti môžem dať loptu, Dez.
Eric Kavanagh: Dokážem to prejsť, čakať, vydržať.
Automatizovaný hlas: Účastnícke linky boli ignorované.
Eric Kavanagh: Dobre, počkajte jednu sekundu, dovoľte mi dať Dezovi loptu.
Dez Blanchfield: Ďakujem, Eric. Áno, Dr. Robin Bloor, ste skutočne najpravdepodobnejší: toto je téma, celoživotný miláčik, ak mi odpustíte slovnú hračku, prepáčte, že by som v tom nemohol pomôcť. Dúfajme, že tu uvidíte moju prvú obrazovku, ospravedlňujeme sa za problém s veľkosťou písma v hornej časti. Témou chýb je celodenná prednáška, v mnohých prípadoch podľa mojich skúseností. Je to taká široká a široká téma, takže sa zameriam na dve kľúčové oblasti, konkrétne na koncept toho, čo považujeme za chybu, ale za problém programovania. Myslím si, že v týchto dňoch sa zavedenie chyby samo osebe stáva integrovaným vývojovým prostredím, hoci to môžu byť dlhotrvajúce chyby. Ale často je to skôr prípad profilovania kódu a je možné napísať kód, ktorý funguje, to by mala byť chyba. Takže, môj titul snímok tu, som vlastne mal kópiu tohto vo veľmi vysokom rozlíšení A3, ale bohužiaľ to bolo zničené v pohybe domu. Je to však rukou písaná poznámka o programovom liste z roku 1945, kde údajne niektorí ľudia na Harvardskej univerzite v USA, ich druhá zostava stroja s názvom Mark II. Ladili nejaký problém spoločným jazykom, ale snažili sa nájsť chybu, a ukázalo sa, že prišlo niečo mierne odlišné od toho, čo bol hardvér a pravdepodobne softvérový problém.
Mestský mýtus je teda okolo 9. septembrath, 1945 tím na Harvardskej univerzite roztrhával stroj, narazili na niečo, čo nazývali „štafeta sedemdesiat“ - v tom čase sa programovanie robilo vo fyzickom zmysle, kód ste obtočili okolo dosky a takto ste efektívne naprogramovali stroj - a zistili, že toto relé číslo sedemdesiat, bolo s tým niečo zlé, a ukázalo sa, že sa objavil skutočný termín „chyba“, pretože to doslova bol mol - pravdepodobne medzi nimi prechádzal kúsok medeného drôtu z jedného miesta na druhé. A príbeh hovorí, že legendárny Grace Hopper ako tento nadpis, pre môj titulný snímok, „prvý skutočný prípad nájdenia chyby“, cituje bez úvodzoviek.
Ako však Robin zdôraznil už vo svojom prvom snímke, koncept chyby siaha až do minulosti, ako si vieme predstaviť, že ľudia robia výpočet, pojmy ako záplata. Pojem „náplasť“ pochádza zo skutočného kúsku pásky, ktorý sa nalepí cez otvor na diernej karte. Ide však iba o to, že pojem „ladenie“ vychádza z tohto pojmu nájdenia chyby vo fyzickom stroji.A od tej doby sme používali túto terminológiu pri skúmaní problémov, či už to nie je problém s kódovaním v programe, ktorý sa nezkompiluje, ale ako program, ktorý nefunguje dobre. A konkrétne nebol profilovaný len nájsť veci, ako sú nekonečné slučky, ktoré jednoducho nikam nevedú.
Máme však aj scenár a ja som si myslel, že Id vložil pár vtipných snímok skôr, ako som sa dostal do trochu podrobnejších detailov. Tu je klasická karikatúra s názvom XKCD na webe a karikaturista má celkom vtipné názory na svet. A to o dieťati nazývanom „Malé Bobby tabuľky“ a pravdepodobne jeho rodičia pomenovali tohto mladého chlapca Roberta); DROP TABLE Študenti; - a jej meno, a akési „Ahoj, toto je tvoja škola synov, ktorá má nejaké problémy s počítačom,“ a rodič odpovie: „Ach, drahý, niečo zlomil?“ A učiteľ hovorí: „Dobre, Svojím spôsobom, “a pýta sa učiteľ,„ ste skutočne pomenovali svojho syna Roberta); DROP TABLE Študenti; -? “A rodič hovorí:„ Ó, áno, malé Bobby tabuľky, ktoré mu nazývame. “Každopádne hovoria, že teraz stratili záznamy študentov, dúfam, že ste šťastní. Odpoveď znie: „Dobre, mali by ste vyčistiť a dezinfikovať vstupy do svojej databázy.“ A používam toľkokrát, aby som hovoril o niektorých problémoch, ktoré máme pri hľadaní vecí v kóde, že kód často často nepozerá ani na údaje. ,
Ďalší vtipný, neviem, či je to skutočné alebo nie - mám podozrenie, že je to spoof - ale opäť sa dotýka aj mojej vtipnej kosti. Niekto mení poznávaciu značku na prednej časti svojho vozidla na podobné vyhlásenie, ktoré spôsobuje, že databázy klesajú v rýchlostných radaroch a tak ďalej, ktoré zachytávajú poznávacie značky automobilov. A vždy to hovorím tak, že pochybujem, že každý programátor očakával zásah a spustenie svojho kódu skutočným motorovým vozidlom, ale nikdy to nepodceňoval - silu nahnevaného geeka.
(Smiech)
Myslím si však, že to ma vedie k môjmu kľúčovému bodu, a to je to, že raz za čas sme mohli ladiť a profilovať kód ako smrteľníkov. Ale som veľmi toho názoru, že ten čas už prešiel a podľa mojich skúseností anekdoticky, môj prvý - a teraz ma strašne starnú, som si istý; Robin si vítaný, aby si ma za to pobavil - ale historicky Ive pochádzam z prostredia vo veku 14 rokov putujúcich po konci mesta a klepaním na dvere dátového centra s názvom „Data Com“ na Novom Zélande s otázkou, či V škole by som si mohol zarobiť vreckové tým, že každý deň odídem z autobusu domov, asi 25 km dochádzky, vložím papier do pások a pásky do páskových jednotiek a budem len obyčajným správcom. A napodiv, dali mi prácu. Ale časom sa mi podarilo dostať sa do personálneho obsadzovania a nájsť programátorov a uvedomil som si, že milujem kódovanie a prešiel procesom spúšťania skriptov a dávkových úloh, ktoré sú na konci dňa stále kódom. Musíte napísať skripty a dávkové úlohy, ktoré vyzerajú ako mini programy, a potom prejsť celý proces sedenia ručne na 3270 termináli.
V skutočnosti bola moja prvá skúsenosť na teletypovom termináli, ktorý bol v skutočnosti fyzickým stĺpcom s 132 stĺpcami. V podstate uvažujte ako o veľmi starom písacom stroji s papierom, ktorý ním prechádza, pretože nemajú CRT trubicu. A ladiaci kód bol veľmi netriviálnym problémom, takže ste mali tendenciu písať celý svoj kód ručne, a potom ste sa správali ako pisárka, robíte maximum, aby ste sa nedostali k chybám, aby ste sa mohli vkradnúť, pretože je veľmi frustrujúce musieť to povedať editor jedného riadku, ktorý prejde na určitý riadok a potom riadok a potom ho zadá späť. Ale raz za čas sme napísali kód a takto sme odladili, a dostali sme veľmi, veľmi dobrý názor. A v skutočnosti nás to prinútilo mať veľmi dobré techniky programovania, pretože opraviť to bolo skutočným problémom. Cesta však prešla - a všetci to boli oboznámení - išla od zážitku z terminálu 3270 v mojom svete k digitálnemu zariadeniu VT220, kde ste mohli vidieť veci na obrazovke, ale znova ste robili to isté, čo ste urobili na papierovej páske v akomkoľvek formáte ed len na CRT, ale mohli ste ich ľahšie vymazať a nemali ste zvuk „dit dit dit dit“.
A potom viete, terminály Wyse - ako je Wyse 150, pravdepodobne moje najobľúbenejšie rozhranie k počítaču vôbec - a potom počítač a počítač Mac a v súčasnosti moderné GUI a ID, ktoré sú založené na webe. A množstvo programov prostredníctvom toho, programovanie v jednom a assembleri a PILOT a Logo a Lisp a a Fortran a Pascal a jazyky, ktoré by mohli ľudí zvrhnúť. Ale to sú jazyky, ktoré vás prinútili napísať dobrý kód; nedovolili vám uniknúť zlým praktikám. C, C ++, Java, Ruby, Python - a my sa dostávame ďalej do tejto programovacej fázy, dostávame viac skriptov, dostávame sa bližšie a bližšie k Structured Query Language a jazykom ako PHP, ktoré sa v skutočnosti používajú na vyvolanie SQL. Zmyslom je povedať, že pochádzajúc z môjho pozadia, som sa učil mnohými spôsobmi a tí, ktorí mi pomohli učiť sa, učili mi veľmi dobré programovacie postupy a veľmi dobré postupy týkajúce sa návrhu a procesov, aby som sa ubezpečil, že som nezaviedol buggy. code.
Programovacie metódy v týchto dňoch, napríklad, štruktúrovaný dotazovací jazyk, SQL, je to veľmi silný a jednoduchý dotazovací jazyk. Ale spoločnosť Weve sa zmenila na programovací jazyk a ja neverím, že jazyk SQL bol niekedy navrhnutý ako moderný programovací jazyk, ale sklonil sa k nemu. A to predstavuje celý rad problémov, pretože keď uvažujeme z dvoch hľadísk: z hľadiska kódovania az pohľadu DBA. Je to veľmi ľahké prísť a predstaviť chyby týkajúce sa vecí, ako sú len zlé programovacie techniky, lenivé úsilie pri písaní kódu, nedostatok skúseností, klasický mazanec, ktorý mám napríklad s ľuďmi SQL, ktorí na serveri Google skočia a niečo hľadajú a nájdu webovú stránku, ktorá je dostal príklad a urobil kópiu a vloženie existujúceho kódu. A potom replikovať zlé kódovanie, zanedbávať správne postupy a uvádzať ich do výroby, pretože sa im jednoducho darí, aby dosiahli požadované výsledky. Máte iné výzvy, napríklad, v dnešnej dobe sa všetci ponáhľali k tomu, čo nazývame preteky na nulu: snažíme sa robiť všetko tak lacné a tak rýchlo, že máme scenár, v ktorom nezamestnávajú nízko platených zamestnancov. A nemyslím to nenápadným spôsobom, ale najímam odborníkov na každú možnú prácu. Kedysi bolo s počítačmi nič spoločné s raketovou vedou; podieľalo sa na veciach, ktoré sa rozbili a boli veľmi nahlas, alebo šli do vesmíru, alebo inžinieri boli vysokokvalifikovaní muži a ženy, ktorí absolvovali tituly a absolvovali prísne vzdelanie, ktoré im bránilo robiť bláznivé veci.
V dnešnej dobe existuje veľa ľudí, ktorí sa dostávajú do vývoja a dizajnu a databázy, ktorí majú dlhoročné skúsenosti, ktorí mali nevyhnutne rovnaké školenie alebo podporu. A tak skončíte scenárom len tradičného amatérskeho verzus experta. A pokiaľ ide o slávnu líniu, v skutočnosti si nepamätám, kto cenovú ponuku vytvoril. Čiara hovorí: „Ak si myslíte, že jeho drahé najímanie expertov na prácu robí, počkajte, kým si najmete niekoľko amatérov, ktorí spôsobujú problém, a musíte vyčistite to. “A tak má tento problém SQL a jeho veľmi, veľmi ľahké sa ho naučiť, jeho veľmi ľahké použitie. Podľa môjho názoru to však nie je dokonalý programovací jazyk. Je veľmi ľahké robiť veci ako vybrať hviezdu odkiaľkoľvek a všetko presunúť do programovacieho jazyka, ktorý vám vyhovuje, napríklad s PHP a Ruby alebo Python, a na manipuláciu s údajmi použiť programovací jazyk, s ktorým ste sa natívne zoznámili, namiesto komplexnejšieho dotazu v SQL. A my to vidíme veľa a potom sa ľudia pýtajú, prečo databáza beží pomaly; je to preto, že milión ľudí sa snaží kúpiť lístok z online predajného systému lístkov, z ktorého vyberie hviezdu odkiaľkoľvek.
Teraz je to naozaj extrémny príklad, ale z toho všetkého vyvodzujete pravdu. Takže, aby som to skutočne udrel, je tu príklad, ktorý veľa nosím. Som veľký fanúšik matematiky, milujem teóriu chaosu, milujem sady Mandelbrot. Na pravej strane je stvárnenie sady Mandelbrot, s ktorou som si istý, že všetci boli oboznámení. A na ľavej strane je kúsok SQL, ktorý to vlastne robí. Teraz zakaždým, keď to niekde umiestnim na obrazovku, začujem toto: „Ó môj bože, niekto vykreslil sériu Mandelbrot pomocou SQL, vážne? To je šialené! “Celkom to je ilustrovať to, čo som tam len načrtol, a to je áno, v skutočnosti teraz môžete programovať takmer všetko v SQL; je to veľmi rozvinutý, výkonný a moderný programovací jazyk. Keď to bol pôvodne dopytovací jazyk, bol navrhnutý tak, aby iba zvýšil údaje. Takže teraz sme dostali veľmi zložité konštrukty a dostali uložené procedúry, dostali sme metodiku programovania aplikovanú na jazyk, a tak je to veľmi ľahké pre zlú prax v programovaní, nedostatok skúseností, vystrihnutie a prilepenie kódu, nízko platení pracovníci, ktorí sa snažia byť vysokoplatní zamestnanci, ľudia predstierať, že vedia, ale musia sa o práci učiť.
Celá škála vecí, v ktorých je profilovanie kódu a čo nazývame ladenie, čo nie je toľko nájdenie chýb, ktoré zastavia fungovanie programov, ale chyby, ktoré len poškodzujú systém a zle štruktúrovaný kód. Keď sa teraz pozriete na túto obrazovku a myslíte si, že je to proste jej druh roztomilý a myslíte si: „Páni, aký veľký grafický nápad, idem to spustiť.“ Ale predstavte si, že to beží na nejakej obchodnej logike. Vyzerá to celkom elegantne, ale hovorí sa o matematicky graficky vykreslenej teórii chaosu, ale keď premýšľate o tom, na čo by sa mohla potenciálne použiť v nejakej obchodnej logike, získate obraz veľmi rýchlo. A aby som to naozaj ilustroval - a je mi ľúto, že farby sú obrátené, má to byť čierne pozadie a zelené ako zelená obrazovka, ale stále to môžete prečítať.
Išiel som a rýchlo som sa pozrel na príklad toho, čo by si mohol urobiť, keby si bol naozaj blázon a nemal vôbec žiadne skúsenosti a prišiel z iného prostredia programovania a aplikoval rád C ++ na SQL, aby som naozaj ilustroval môj názor, predtým Odovzdám nášmu učenému hosťovi z IDERA. Toto je štruktúrovaný dotaz, ktorý je napísaný ako C ++, ale je kódovaný v SQL. A v skutočnosti sa vykonáva, ale vykonáva sa po dobu troch až piatich minút. A údajne odtiahne späť jeden riadok údajov z viacerých databáz, viacerých pripojení.
Opäť platí, že ak nemáte správne nástroje, ak nemáte správne platformy a prostredia, ktoré tieto veci dokážu zachytiť, dostanú sa do výroby, a potom máte 100 000 ľudí, ktorí zasiahnu systém každý deň alebo hodinu alebo minútu, veľmi skoro skončíte s černobyľskou skúsenosťou, keď sa veľké železo začne topiť a zahrabať sa do jadra planéty, pretože tento kus kódu by sa nikdy nemal dostať do výroby. Ospravedlňte ma, vaše systémy a nástroje, mali by ste to vyzdvihnúť skôr, ako sa dostane kamkoľvek blízko - dokonca aj počas testovacieho procesu, dokonca aj prostredníctvom integrácie UAT a systémov, by sa mal tento kód vyzdvihnúť a zvýrazniť a niekto by mal byť odložený stranou a „Pozrite, to je skutočne pekný kód, ale umožňuje získať databázu DBA, ktorá vám pomôže správne zostaviť tento štruktúrovaný dotaz, pretože úprimne povedané, je to škaredé.“ A adresy URL môžete ísť a pozrieť sa - nazýva sa to najzložitejší dotaz SQL, aký ste kedy napísali. Pretože mi verte, že sa skutočne kompiluje, beží. A ak to vystrihnete a vložíte a zosmiešate databázu, je to niečo, čo by ste mali sledovať; Ak máte nástroje na sledovanie databázy, skúste roztaviť po dobu troch až piatich minút, zavolať späť čo je jeden riadok.
Takže, aby som to zhrnul, moje celé pozadie v kódovaní ma naučilo, že môžete dať ľuďom zbraň, a ak nie sú opatrní, budú sa strieľať do nohy; trik je ukázať im, kde je bezpečnostný mechanizmus. So správnymi nástrojmi a správnym softvérom na dosah ruky, po dokončení kódovania si môžete skontrolovať svoj kód, môžete nájsť problémy profilovaním kódu, môžete nájsť efektívne nezamýšľané chyby, ktoré sú problémami s výkonom, a ako som už povedal vyššie, , raz za čas, môžete to urobiť pri pohľade na zelenú obrazovku. Už nemôžete; Existujú stovky tisíc riadkov kódu, sú tu nasadené desiatky tisíc aplikácií, v niektorých prípadoch existujú milióny databáz a dokonca aj super ľudia to už nemôžu robiť ručne. Doslovne potrebujete správny softvér a správne nástroje na dosah ruky a potrebujete tím, aby tieto nástroje používal, aby ste tieto problémy mohli nájsť a veľmi rýchlo ich vyriešiť skôr, ako sa dostanete k veci, zatiaľ čo Dr. Robin Bloor zdôraznil, že to buď bude katastrofálne, a veci vyhodia do povetria alebo bežnejšie, jednoducho vás začnú stáť veľa dolárov a veľa času a úsilia a ničia morálku a veci, keď nedokážu zistiť, prečo sa veci berú dlhá doba na spustenie.
S týmto vedomím sa chystám odovzdať nášmu hosťovi a teším sa, až budem počuť, ako vyriešili tento problém. A najmä demo, ktoré podľa mňa mali dostať. Eric, idem späť.
Eric Kavanagh: Dobre, Bert, zober to.
Bert Scalzo: Dobre ďakujem. Bert Scalzo tu od spoločnosti IDERA, produktový manažér našich databázových nástrojov. A ja budem hovoriť o ladení. Myslím si, že jedna z najdôležitejších vecí, ktorú Robin povedal skôr - a to je úplne pravda, je to, že ladenie je náročné a netriviálne, a keď idete do databázy, jeho ladenie je ešte závažnejšie a netriviálne - takže bol dôležitý citát.
OK. Chcel som začať s históriou programovania, pretože mnohokrát vidím ľudí, ktorí nie sú ladení, nepoužívajú ladiaci program, jednoducho programujú pomocou ľubovoľného jazyka, ktorý používajú, a mnohokrát mi povedia: „Dobre, tie debuggerove veci sú nové a my sme ich ešte začali používať. “A tak to, čo robím, im ukážem tento časový rozvrh, akýsi predhistória, vek, stredný vek, druh toho, kde sme boli podmienky programovacích jazykov. A my sme mali veľmi staré jazyky, ktoré sa začali v roku 1951 so zostavovacím kódom, a Lisp, FACT a COBOL. Potom sa dostaneme do ďalšej skupiny, Pascals a Cs a potom do ďalšej skupiny, C ++, a pozrieme sa, kde je ten otáznik - ten otáznik je približne v rokoch 1978 až 1980. Niekde v tomto rozsahu sme mali debuggery, ktoré máme k dispozícii, a tak povedzme: „Hej, ja nepoužívam debugger, pretože to je jedna z tých nových vecí,“ potom musíte začať programovať, viete, už v 50. rokoch 20. storočia, to je jediný spôsob, ako získať preč s týmto tvrdením.
Teraz je ďalšou vecou, ktorá je na tomto diagrame vtipná, Dez, práve urobil komentár k Grace Hopperovi, vlastne som Graceho poznal, takže je to trochu vtipné. A potom som sa zasmial, že hovoril o teletypoch a sedel som tam a pokračoval: „Človeče, to bol najväčší skok, aký sme kedy dosiahli v produktivite, keď sme prešli od kariet k teletypom, to bol ten najväčší skok vôbec.“ Takže , a ja som tu naprogramoval všetky jazyky, vrátane SNOBOL, o ktorom doteraz nikto nepočul, bolo to CDC, Control Data Corporation, takže myslím, že som pre toto odvetvie príliš starý.
Dez Blanchfield: Chcel som povedať, že si nás tam strašne starol.
Bert Scalzo: Áno, hovorím ti, cítim sa ako starý otec Simpson. Pozerám sa teda na ladenie a na rôzne spôsoby vykonávania ladenia. Dalo by sa hovoriť o tom, čo si všetci myslíme ako o tradičnom vstupe do debuggeru a prechode kódom. Ľudia však budú tiež používať svoj kód; to je miesto, kde nalepíte vyhlásenia do svojho kódu a možno vytvoríte výstupný súbor, sledovací súbor alebo niečo podobné, a tak svoj kód vybavíte. To by som považoval za ladenie, ktoré je trochu ťažšie, spôsob, ako to urobiť, ale to sa počíta. Ale tiež sme dostali slávny výrok: pozeráte sa a ľudia skutočne vkladajú výroky a ja som vlastne videl nástroj, kde - a jeho databázový nástroj - kde, ak neviete, ako používať debugger, stlačíte tlačidlo a bude to držať výroky v celom kóde pre vás a potom, keď ste to urobili, stlačili ste ďalšie tlačidlo a vysunuli ich. Pretože to je to, ako veľa ľudí ladí.
A dôvod, prečo ladíme, je dvojaký: v prvom rade musíme nájsť veci, vďaka ktorým je náš kód neúčinný. Inými slovami, zvyčajne to znamená logickú chybu alebo nám chýbala obchodná požiadavka, ale čo to je, kód nie je účinný; nerobí to, čo sme očakávali. Inokedy ideme a robíme ladenie, je to pre efektívnosť a to by mohla byť logická chyba, ale čo to je, je to, že som urobil správnu vec, jednoducho sa nevrátil dosť rýchlo. Teraz hovorím o tomto bode, pretože profilovatelia pravdepodobne lepšie pre tento druhý scenár a hovorili o debuggeroch aj profiloch. Okrem toho existuje táto koncepcia vzdialeného ladenia; je to dôležité, pretože ak ste veľa času na svojom osobnom počítači a používate debugger, ktorý zasiahne databázu, v ktorej je kód v databáze skutočne vykonaný, skutočne robíte to, čo sa nazýva vzdialené ladenie. Možno si to neuvedomujete, ale to sa deje. A potom je veľmi bežné, že tieto debuggery majú body prerušenia, sledovacie body, krok za krokom a niektoré ďalšie bežné veci, ktoré im za chvíľu ukážem na snímke obrazovky.
Teraz profilovanie: profilovanie môžete vykonať niekoľkými rôznymi spôsobmi. Niektorí ľudia budú hovoriť, že pracovné zaťaženie zachytáva a prehráva, kde zachytáva všetko, čo sa počíta ako profilovanie. Moja skúsenosť bola lepšia, ak sa uskutočnil odber vzoriek. Nie je dôvod chytiť každé jedno vyhlásenie, pretože niektoré výkazy sa môžu spustiť tak rýchlo, že vám to nebude záležať, čo sa naozaj snažíte vidieť, no, ktoré sú tie, ktoré sa neustále objavujú znova a znova, pretože sú príliš dlhé , Takže niekedy môže profilovanie znamenať odber vzoriek skôr ako spustenie celej veci. A zvyčajne získate nejaký druh výstupu, ktorý môžete použiť, teraz, ktorý by mohol byť vizuálny vo vnútri vývojového prostredia IDE, kde vám môže poskytnúť ako histogram výkonnosti rôznych riadkov kódu, ale mohol by tiež stále je to, že vytvára sledovací súbor.
Profiléri sa prvýkrát objavili v roku 1979. Títo boli tiež už dlho. Skvelé pre nájdenie spotreby zdrojov alebo problémov s výkonom, inými slovami, že vec efektívnosti. Všeobecne povedané, je to oddelené a odlišné od debuggeru, hoci som pracoval s debuggermi, ktoré robia obidva súčasne. A zatiaľ čo podľa mňa sú profilovatelia zaujímavejší z týchto dvoch nástrojov, ak mám pocit, že nie je dostatok ľudí na ladenie, potom rozhodne nie je dosť profilov ľudí, pretože sa zdá, že jeden z desiatich debuggerov bude profilovať. A to je škoda, pretože profilovanie môže skutočne urobiť obrovský rozdiel. Teraz, ako už bolo povedané, databázové jazyky, teraz ste dostali SQL - a tak nejako prinútili kruhový kolík do štvorcovej diery a prinútili ho stať sa programovacím jazykom - a Oracle.To je PL / SQL - to je procedurálny jazyk SQL - a SQL Server, jeho Transact-SQL, SQL-99, SQL / PSM - pre, myslím, jeho procedúrový uložený modul. Postgres mu dáva iné meno, DB2 a ešte ďalšie meno, Informix, ale ide o to, že každý si vynútil konštrukty typu 3GL; inými slovami, FOR slučky, v deklaráciách premenných a všetky ostatné veci, ktoré sú cudzie pre SQL, sú teraz súčasťou SQL v týchto jazykoch. Preto musíte byť schopní ladiť PL / SQL alebo Transact-SQL rovnako ako program Visual Basic.
Teraz, databázové objekty, je to dôležité, pretože ľudia povedia: „Dobre, aké veci musím ladiť v databáze?“ A odpoveď znie, dobre, čokoľvek môžete uložiť do databázy ako kód - ak robím T- SQL alebo PL / SQL - a Im ukladanie objektov do databázy, pravdepodobne uložená procedúra alebo uložená funkcia. Ale tiež spúšťa: spúšť je niečo ako uložená procedúra, ale spúšťa sa pri nejakej udalosti. Teraz niektorí ľudia vo svojich spúšťačoch vložia jeden riadok kódu a zavolajú uloženú procedúru, aby si zachovali všetok uložený kód a procedúry, ale je to rovnaká koncepcia: jej spúšť môže byť to, čo iniciuje celú vec. A potom ako Oracle majú niečo, čo sa nazýva balík, ktorý je akosi ako knižnica. 50 alebo 100 uložených procedúr ste umiestnili do jedného zoskupenia, ktoré sa nazýva balík, takže je to ako knižnica. Takže tu je debugger starou cestou; Toto je vlastne nástroj, ktorý skutočne vstúpi a prilepí všetky tieto ladiace príkazy vo vašom kóde. Takže všade, kde vidíte blok ladenia, neodstraňujte, spustite a sledujte automatické ladenie, všetky boli zaseknuté nejakým nástrojom. A riadky mimo toho, čo je menšina kódu, je to metóda manuálneho ladenia.
A dôvod, prečo to uvádzam, je, že ak sa to snažíte urobiť ručne, v skutočnosti napíšete viac ladiaceho kódu, ktorý vložíte do všetkých týchto príkazov, ako ste s týmto kódom. Takže, hoci to môže fungovať, a hoci je to lepšie ako nič, je to veľmi zložitý spôsob ladenia, najmä od tej doby, čo, ak to trvá 10 hodín, kým sa táto vec spustí, a kde má problém, je v riadku tri? Keby som robil interaktívnu ladiacu reláciu, vedel by som to na riadku tri - päť minút do toho - hej, tu je problém, môžem skončiť. Ale s týmto, musím počkať, až to začne bežať, až do jeho dokončenia a potom sa musím pozrieť na nejaký stopový súbor, ktorý pravdepodobne obsahuje všetky tieto výroky, a skúsiť nájsť ihlu v kupce sena. Opäť je to lepšie ako nič, ale nebol by to najlepší spôsob práce. Teraz by to vyzeralo, že tento súbor bude vyzerať ako ten, ktorý pochádza z predchádzajúcej snímky; inými slovami, spustil som program a práve som v tomto sledovacom súbore dostal veľa príkazov a možno, ale možno nebudem schopný sifónovať a nájsť to, čo potrebujem nájsť. Takže opäť si nie som istý, či je to spôsob, akým by ste chceli pracovať.
Teraz, interaktívne debuggery - a ak ste na písanie programov použili niečo ako Visual Studio alebo Eclipse, youve mali debuggery a použili ste ich vo svojich ďalších jazykoch - jednoducho si nemyslím, že ich tu použijete vo svojej databáze. A existujú nástroje, ako je náš DB Artisan a Rapid SQL, toto je Rapid SQL tu, ktoré majú debugger, a vidíte na ľavej strane, mám uloženú procedúru s názvom „check for duplicates.“ V podstate to bude len ísť a pozerať sa a uvidíme, či mám v tabuľke viac riadkov s rovnakým názvom filmu. Databáza je teda určená pre filmy. A vy ste mohli vidieť na pravej strane, v hornej tretine, som dostal svoj zdrojový kód uprostred, dostal som, čo sa nazýva moje sledovacie premenné a moje zásobníky zásobníkov, a potom v spodnej časti som dostal nejaké výstupy. A čo je tu dôležité, ak sa pozriete na prvú červenú šípku, keď prejdem kurzorom na premennú, v skutočnosti vidím, aká hodnota je v tejto premennej v danom okamihu, keď Im prechádzal kódom. A to je skutočne užitočné, a potom môžem krokom prejsť jeden riadok naraz pomocou kódu, nemusím hovoriť spustiť, mohol by som povedať krok za riadkom, dovoľte mi pozrieť sa, čo sa stalo, prejsť na ďalší riadok, dovoľte mi zistiť, čo sa stalo, a Robím to v databáze. Aj keď na svojom počítači sedím na Rapid SQL a moja databáza je v cloude, stále môžem robiť vzdialené ladenie a vidieť ho, ovládať odtiaľto a ladiť rovnako ako v akomkoľvek inom jazyku.
Teraz, nasledujúca šípka - vidíte trochu ako šípka smerujúca doprava, smerom k tomuto výstupu DBMS, to je miesto, kde sa momentálne nachádza môj kurzor - inými slovami, Ive vystúpila a to je miesto, kde sa momentálne nachádzam. Takže, keď poviem: „Znovu vstúpte“, idem na ďalší riadok. Teraz pod ňou uvidíte červenú bodku. No, to je bod prerušenia, ktorý hovorí: „Hej, nechcem prekračovať tieto riadky.“ Ak chcem len skočiť cez všetko a dostať sa na miesto, kde tá červená bodka, môžem stlačiť tlačidlo spustenia a bude to odtiaľto buď koniec alebo bod prerušenia, ak sú stanovené nejaké body prerušenia, potom sa zastaví a dovoľte mi znova vykonať krokovanie. A dôvod, prečo je to všetko dôležité a silné, je, že keď robím toto všetko, čo sa deje v strede a dokonca aj v spodnej časti - ale čo je najdôležitejšie v strede - sa zmení a vidím hodnoty z mojich premenných, vidím pozri moje sledovanie zásobníka hovorov, viete, a preto sa všetky tieto informácie zobrazujú ako Im prechádzajúci kódom, takže v skutočnosti vidím a cítim a chápem, čo sa deje a ako kód v skutočnosti funguje v čase vykonávania , A zvyčajne nájdem problém, ak existuje, alebo ak som dosť dobrý na to, aby som ho chytil.
Dobre, teraz budem hovoriť o profilovanom nástroji, av tomto prípade je to profilový nástroj, ktorý vidím cez debugger. Pamätáte si, že som niekedy povedal, že sú oddelené a niekedy môžu byť spolu? V tomto prípade a znova, Im v Rapid SQL, a vidím, že existuje okraj, na ľavej strane, vedľa čísel riadkov. A čo to znamená, je to počet sekúnd alebo mikrosekúnd, ktoré potrebovali na vykonanie každého riadku kódu, a vidím, že je zrejmé, že všetok svoj čas trávim v tejto jednej slučke, kde vyberiem všetko z tabuľky. Takže to, čo sa deje vo vnútri tejto slučky FOR pravdepodobne je niečo, na čo sa musím pozrieť, a ak to dokážem zlepšiť, vyplatí dividendy. Nebudem mať žiadne vylepšenia prácou na tých linkách, ktoré majú rád 0,90 alebo 0,86; nie je tam veľa času. Teraz, v tomto prípade a znova, som v Rapid SQL, vidíte, ako môžem robiť profilovanie zmiešané s mojím ladením. Teraz je pekné, že Rapid SQL vám to umožňuje robiť aj iným spôsobom. Rapid SQL vám umožňuje povedať: „Vieš čo? Nechcem byť v debuggere, chcem to len spustiť a potom sa chcem pozrieť na graficky alebo vizuálne ten istý druh informácií. “
A vidíte, že Im už nie je v debuggere a beží program a po dokončení vykonávania programu mi dáva grafy, ktoré mi povedia veci, takže vidím, že som dostal jedno vyhlásenie, ktoré vyzerá, akoby zabralo väčšinu koláča. graf a keď sa pozriem, vidím na tejto mriežke smerom dole, riadok 23, opäť je tu slučka FOR: HES zaberá najviac času, je to vlastne, že tmavo červená žuvanie všetkých koláčových grafov. Toto je ďalší spôsob, ako robiť profilovanie. V našom nástroji náhodou nazývame tento „analytik kódu“. Ale v podstate je to len profiler oddelený od debuggeru. Niektorí ľudia to radi robia prvým spôsobom, iní ľudia to radi robia druhým spôsobom.
Prečo robíme ladenie a profilovanie? Nie je to preto, že by sme chceli napísať najväčší kód na svete a získať zvýšenie mzdy - to by mohol byť náš dôvod, ale to nie je dôvod, prečo to robíte - sľúbili ste obchodu, že urobíte niečo správne, že váš program bude efektívny. To je to, čo budete používať debugger. Okrem toho koncoví podnikatelia; nie sú príliš trpezliví: chcú výsledky ešte predtým, ako stlačia kláves. Mali čítať svoju myseľ a robiť všetko okamžite. Inými slovami, musí byť efektívny. A na to by sme profiler použili. Teraz, bez týchto nástrojov, naozaj verím, že ste tento chlapík v obleku s lukom a šípom a vy strieľate na cieľ a ste so zaviazanými očami. Pretože ako zistíte, ako sa program spúšťa len pri pohľade na statický kód a ako zistíte, ktorý riadok je miestom, kde by skutočne strávil najviac času na vykonanie, znova len pri pohľade na statický kód? Kontrola kódu môže alebo nemusí odhaliť niektoré z týchto vecí, ale neexistuje žiadna záruka, že by ich kontrola všetkých našla. Pomocou debuggeru a profilovača by ste mali byť schopní nájsť všetky tieto chyby.
OK, ja tu budem robiť skutočné rýchle demo. Nie je to môj úmysel tlačiť produkt, chcem vám iba ukázať, ako vyzerá ladiaci program, ktorý spôsobí, že ľudia mnohokrát povedia: „Nikdy som jedného z nich nevidel.“ A vyzerá to pekne na snímkach obrazovky, ale čo vyzerá to, keď je v pohybe? Takže tu na mojej obrazovke Im spustím náš produkt DB Artisan; máme tu tiež debugger. DB Artisan je určený skôr pre DBA, Rapid SQL je skôr pre vývojárov, ale videl som vývojárov, ktorí používajú DB Artisan, a Ive som videl DBA, ktorí používajú Rapid. Nenechajte sa teda chytiť produktu. A tu mám na výber vykonanie ladenia, ale predtým, ako spustím ladenie, vyberiem tento kód, aby ste videli, ako vyzerá, skôr ako ho spustím. Toto je presne ten istý kód, aký bol na snímke obrazovky. Toto je moja kontrola duplikátov. A chcem to odladiť, takže stlačím ladenie. A teraz to chvíľu trvá a poviete: „Dobre, prečo to trvá chvíľu?“ Pamätajte si vzdialené ladenie: ladenie sa skutočne deje na mojom databázovom serveri, nie na mojom počítači. Takže tam muselo ísť a vytvoriť reláciu, vytvoriť vzdialenú ladiacu vec, pripojiť moju reláciu k tejto vzdialenej ladiacej relácii a nastaviť komunikačný kanál.
Takže teraz, tu je môj šíp, je to hore hore, za prvým riadkom, to je miesto, kde som v kóde. A ak tam stlačím tretiu ikonu, čo je krokom, uvidíte, že sa šípka práve pohla, a ak ju stále stlačím, uvidíte, že sa neustále pohybuje. Ak by som chcel ísť celú cestu k tejto slučke FOR, pretože viem, že to je problém, môžem nastaviť bod prerušenia. Myslel som, že som to stanovil. Oh, strieľaj, mal som jeden z mojich klávesov na snímanie obrazovky mapovaných na ten istý kľúč ako debugger, čo spôsobuje zmätok. Dobre, tak som tam manuálne nastavil bod prerušenia, takže teraz namiesto toho, aby som urobil krok, krok, krok, krok, kým sa tam nedostanem, môžem skutočne povedať: „Choďte do toho a spustite túto vec“ a zastaví sa. Všimnite si, že ma to posunulo až na miesto, kde je zlom, takže teraz som v konte spustenia tejto slučky, vidím, na čo sú nastavené všetky moje premenné, čo nie je prekvapujúce, pretože som ich všetky inicializoval nula. A teraz môžem vstúpiť do tejto slučky a začať sa zaoberať tým, čo sa deje vo vnútri tejto slučky.
Takže, teraz to bude robiť vybrané počty z mojich nájomných a môžem prejsť kurzorom nad tým chlapom a pozerať sa, hm, dva, dva sú väčšie ako jeden, takže pravdepodobne urobí ďalší kus tohto kódu. Inými slovami, niečo našlo. Len sa do toho pustím a nechám to bežať. Nechcem tu robiť všetko; čo ti chcem ukázať je, keď sa vykoná ladiaci program, skončí rovnako ako normálny program. Mám nastavený bod prerušenia, takže keď som povedal, že je spustený, jednoducho sa vrátil na ďalší bod prerušenia. Im nechať to bežať až do konca, pretože to, čo chcem, aby ste videli, je to, že ladiaci program nemení správanie programu: keď je hotovo spustený, mal by som získať presne rovnaké výsledky, ak by som ho nespustil vnútri debuggeru.
A s tým musím pozastaviť ukážku a vrátiť sa, pretože sa chceme uistiť, že máme čas na otázky a odpovede. A tak to otvorím pre otázky a odpovede.
Eric Kavanagh: Dobre, Robin, možno otázka od teba a potom pár od Deza?
Robin Bloor: Áno, určite to považujem za fascinujúce. Ive pracoval s takými vecami, ale nikdy som s ničím podobnými v databáze nepracoval. Môžete mi dať predstavu o tom, na čo ľudia používajú profiler? Pretože to vyzerá tak, že sa pozerajú - pretože predpokladám, že sú - pozerajú sa na problémy s výkonom, pomôže vám to rozlíšiť, kedy databáza trvá nejaký čas a kedy nejaký kód trvá nejaký čas?
Bert Scalzo: Vieš, to je fantastická otázka. Povedzme, že pracujem v jazyku Visual Basic a ja v rámci svojho jazyka Visual Basic budem volať Transact-SQL alebo PL / SQL. Dovoľte mi vykonať PL / SQL, pretože spoločnosť Oracle nehrá dobre vždy s nástrojmi spoločnosti Microsoft. Mohol by som profilovať svoj kód jazyka Visual Basic a profil tam môže hovoriť: „Hej, zavolal som túto uloženú procedúru a trvalo to príliš dlho.“ Ale potom môžem ísť do uloženej procedúry a môžem urobiť databázový profil na uloženej procedúre Postupujte a povedzte: „Dobre, zo 100 tvrdení, ktoré sú tu, je tu päť, ktoré spôsobovali problém.“ A tak možno budete musieť urobiť tím značiek, v ktorom budete musieť použiť viac profilov.
Ide o to, že ak sa niekedy dozviete, že problém s výkonom je vo vašej databáze, databázový profil vám môže pomôcť nájsť ihlu v kupce sena, o ktorých tvrdeniach sa v skutočnosti jedná, kde máte problém. Hovorím vám ďalšiu vec, ktorá sa objavila s profilovaním: ak máte kúsok kódu, ktorý sa nazýva miliónkrát, ale každý miliónkrát to trvá len mikrosekundu, ale miliónkrát sa to nazýva, čo by profiler ukázal , tá vec bežala toľkých časových jednotiek. Aj keď môže byť kód veľmi efektívny, mali by ste vyzerať a povedať: „Ooh, príliš často volali na tento kúsok kódu. Možno by sme to mali nazývať iba tak často, ako vždy, keď spracúvame záznam, “alebo tak niečo. A tak môžete skutočne nájsť, kde sa nachádza efektívny kód, ktorý sa volá príliš často a v skutočnosti je to problém s výkonom.
Robin Bloor: Áno, to je úžasné. Nikdy som to neurobil. Vidíte, samozrejme, keď som mal problémy s databázou, bolo to, akoby som sa tak či onak zaoberal databázou alebo kódom; Nikdy by som sa s nimi nemohol vyrovnať naraz. Ale opäť som to neurobil - nikdy som sa nikdy nezúčastňoval vytvárania aplikácií, kde sme mali uložené procedúry, takže myslím, že som sa nikdy nestretol s problémami, ktoré ma používali, aby som sa divoko divil, myšlienka, že by si kód rozdelil medzi databáza a program. Ale urobte všetko - predpokladám, že odpovede budú áno, ale je to súčasť činnosti vývojového tímu, keď sa nejakým spôsobom snažíte opraviť niečo, čo je rozbité alebo sa možno pokúšať spojiť novú aplikáciu. Je to všetko prispôsobené všetkým ostatným zložkám, ktoré by som v prostredí očakával? Môžem očakávať, že to dokážem pripnúť na všetky svoje testovacie balíčky a na všetky ostatné veci, ktoré by som robil, a na veci súvisiace s mojím projektovým riadením?
Bert Scalzo: Áno, môže sa stať súčasťou každého štruktúrovaného procesu, aby ste sa mohli venovať programovaniu alebo vývoju. A je to smiešne, minulý týždeň som mal zákazníka, ktorý zostavoval webovú aplikáciu, a ich databáza bola historicky malá, a preto skutočnosť, že nemali veľmi dobrých programátorov, im nikdy neublížila. Ich databáza sa v priebehu rokov rozrástla a teraz na webovej stránke trvá 20 sekúnd, keď poviete: „Prihláste sa a dajte mi nejaké údaje, ktoré chcete vidieť“, a keď sa obrazovka skutočne objaví, a tak teraz jej problém s výkonom. A vedeli, že problém nebol v žiadnej z ich Java ani na iných miestach. Mali však tisíce uložených procedúr, a preto museli začať profilovať uložené procedúry, aby zistili, prečo je potrebné, aby táto webová stránka vyšla 20 sekúnd? Skutočne sme zistili, že sa v jednom zo svojich vybraných vyhlásení pripojili karteziánski členovia a nevedeli sme to.
Robin Bloor: Wow.
Bert Scalzo: Ale niekto mi raz povedal: „Dobre, ako by sa mohli pripojiť karteziánske vzťahy a nevedieť to?“ A to znie naozaj hrozne; niekedy programátor, ktorý nie je veľmi spokojný s SQL, urobí niečo, ako keď mi dá karteziánske pripojenie, ale potom mi vráti iba prvý záznam, takže viem, že niečo mám a potrebujem iba prvý. A tak si neuvedomujú, že práve priviedli späť miliardu záznamov alebo si prezreli miliardu záznamov, pretože dostali ten, o ktorý sa zaujímali.
Robin Bloor: Wow, viem, to sa hovorí - dobre, to je to, o čom sa Dez deje, pokiaľ ide o ľudí, ktorí nie sú tak kvalifikovaní, ako by možno mali byť, viete. Ak ste programátor, mali by ste vedieť, aké dôsledky má vydanie akéhokoľvek príkazu. Myslím tým naozaj nie je ospravedlnenie tejto úrovne hlúposti. Tiež predpokladám, že ste v tomto smere nejakým jazykom agostickí, pretože sa to všetko zameriava na databázovú stránku. Mám v tom pravdu? Je to to isté, čo používate na kódovacej strane?
Bert Scalzo: Absolútne to môžete urobiť vo formáte Fortran alebo C alebo C ++. V skutočnosti, na niektorých Unixoch to môžete dokonca urobiť pre svoje skriptovacie jazyky; v skutočnosti poskytujú rovnaké nástroje. A potom sa chcem vrátiť na chvíľu späť za to, čo ste povedali, bez ospravedlnenia. Dám programátorom jednu prestávku, pretože nemám rád hádzať programátorov pod autobus. Problém je však v skutočnosti v akademickom prostredí, pretože keď sa chystáte naučiť, ako byť programátorom, učil ste rekordné myslenie. Neučíte sa množinové myslenie a to je to, čo Structured Query Language alebo SQL pracuje so sadami; Preto máme spojenie, križovatku a mínus operátora. A to je niekedy veľmi ťažké pre osobu, ktorá nikdy nemyslela na súbory, prestať, púšťať rekordné spracovanie a pracovať so súpravami.
Robin Bloor: Áno, som s tebou. Myslím tým, že sa dostávam teraz, je to otázka vzdelávania; Myslím si, že je to úplne vzdelávací problém, myslím si, že je prirodzené, že programátori premýšľajú procedurálne. A SQL nie je procedurálne, je to deklaratívne. V skutočnosti len hovoríte: „To je to, čo chcem, a je mi jedno, ako to robíte,“ viete? Zatiaľ čo pri programovacích jazykoch ste si často rukávy zrolovali a vy ste sa dostali do markantných bodov, keď ste dokonca spravovali počty, zatiaľ čo robíte slučku. Ruka -
Bert Scalzo: Nie, OK, pokračujte.
Áno, chcel som povedať, že ste uviedli jeden ďalší príklad, že by profiler dobre chytil ten druh záznamu, ktorý pokračuje v tomto spracovaní záznamu v čase. Niekedy programátor, ktorý je dobrý v rekordnej logike, nemôže zistiť, ako vykonať program SQL. Povedzme, že robí dve slučky FOR a v podstate robí spojenie, ale robí to na strane klienta. HES robí rovnaký efekt ako pripojenie, ale robí to sám a profil by to chytil, pretože by ste pravdepodobne skončili trávením času viac manuálne, ako necháte to urobiť za vás databázový server.
Robin Bloor: Áno, to by bola katastrofa. Myslím, že by si sa len tak hádzal. Thrashings vždy zlé.
Každopádne prejdem na Dez; Určite mám nejaké zaujímavé otázky.
Dez Blanchfield: Ďakujem, áno, áno. Idem sa k tebe pripojiť v programátoroch, ktoré nevyhadzujú pod autobus. Myslím tým, že som strávil príliš veľa rokov v mojom živote tým, že som sám programátorom, na všetkých úrovniach, viete, či je to, ako ste povedali, sediaci na príkazovom riadku stroja Unix, av niektorých prípadoch som sa dokonca podieľal na niekoľko rôznych portov Unixu z jednej hardvérovej platformy na druhú. A viete si predstaviť výzvy, ktoré sme tu mali. Realitou sú však heres, ktoré dostanú kartu z väzenia pre všetkých kódovačov a scenárov na svete. Je to raketová veda, doslova písať skutočne pevne zakaždým, keď je to raketová veda. A slávne príbehy ľudí, ako Dennis Ritchie a Brian Kernahan, pracujú nezávisle na nejakom kóde a potom sa obrátia na konverzáciu kódu na kávu a zistia, že napísali presne ten istý kúsok kódu, presne v rovnakom programe, presne v rovnakom programe rovnakým spôsobom. A urobili to v C. Ale táto puristická úroveň programovania existuje veľmi zriedka.
Faktom je, že na dennej báze je len 24 hodín denne, sedem dní v týždni, a my musíme len urobiť veci. A tak, pokiaľ ide o nielen tradičných programátorov, DBA a kódery a skripty, sysadmin a sieťových administrátorov a bezpečnostných pracovníkov, a všetko, čo sa v týchto dňoch až po údaje o občanovi týka; počujeme, všetci sa snažia robiť svoju prácu. A tak si myslím, že skvelým jedlom z tejto celej veci je to, že som miloval vaše demo a miloval som to s sebou, ktoré ste nám tu pred chvíľou nechali, keď som sa porozprával s Robinom o skutočnosti, že to má konkrétny - možno nie toľko výklenok - ale široký priestor, na ktorý sa vzťahuje, pokiaľ ide o opravu kódu a SQL a databáz. Ale bol som veľmi nadšený, keď som vás počul, že ste to mohli strčiť do skriptu a nájsť nejaké problémy, pretože viete, že v dnešných dňoch a veku vždy pracovali na čo najnižších nákladoch.
Dôvodom, prečo si niekde môžete kúpiť košeľu s výškou 6 dolárov, je to, že niekto vybudoval systém dostatočne lacný na to, aby skutočne vyrábal a odosielal a logisticky dodával a predával a predával a maloobchodoval a prijímal platby online, aby získal košeľu s výškou 6 dolárov. A to sa nestane, ak dostanete ľuďom zaplatené 400 000 dolárov ročne, aby kód napísali dokonale; je to len celý vývoj. Takže v tomto bode si myslím, že jedna z otázok, ktoré vás naozaj milujú, aby ste nám iba poskytli ďalšie informácie, je to, čo je šírka a dosah typu ľudí, ktorých v súčasnosti vidíte a ktoré používajú tieto nástroje na profilovanie kódu a vzhľad pre problémy s výkonom? Pôvodne, historicky, odkiaľ pochádzajú? Boli to veľké inžinierske domy? A potom, v budúcnosti, mám pravdu, keď si myslím, že stále viac a viac spoločností implementuje tento nástroj alebo tieto nástroje, aby sa pokúsili pomôcť kodérom, ktorí vedia, ktorí práve robia veci, aby dokončili prácu. a dostať ich von zo dverí? A niekedy potrebujeme kartu s odchodom z väzenia? Mám pravdu v tom, že sme sa historicky viac zameriavali na vývoj a vývoj? To už bolo čoraz menej, ako povedal Robin, akademický prístup a teraz jeho samouk, alebo rozbaľovací a vkladací kód, alebo len veci stavali? A to sa zhoduje s typom ľudí, ktorí teraz berú výrobok?
Bert Scalzo: Áno, presne. A ja vám dať veľmi konkrétny príklad, my len chceme, aby si prácu, pretože podnikatelia nechcú dokonalosti. Je to ako počítačová šachová hra: šachová hra nehľadá dokonalú odpoveď; hľadá odpoveď, ktorá je dosť dobrá v primeranom čase, a teda aj to, ako programujeme. Ale čo teraz zistím, je, že väčšina ľudí namiesto toho, aby povedala, že chce v rámci testovania jednotky profilovateľa - takto by som to urobil, pretože to nevidím ako stratu času - čo sa teraz deje, je to, že sa to robí neskôr, niekedy počas integračného testovania alebo stresového testovania, ak mali šťastie. Ale vo väčšine prípadov je to jeho eskalácia, keď sa niečo stalo vo výrobe, chvíľu to bežalo, možno dokonca aj roky, a teraz to nefunguje dobre a teraz ho dobre profiluje. A to sa zdá byť teraz bežnejším scenárom.
Dez Blanchfield: Áno, a myslím si, že termín „technický dlh“ je pravdepodobne o niečo viac, ako poznáš; Poznám Robina a určite som. Myslím si, že v súčasnosti, najmä v agilných prístupoch k rozvoju a budovaniu systému, je koncept technického dlhu veľmi skutočný a my to v projektoch skutočne zodpovedáme. Viem, myslím, že sme dostali naše vlastné projekty ako Media Lens a ďalšie, kde sa každý deň odohrávalo kódovanie a rôzne veci naprieč skupinou Bloor. A kedykoľvek niečo stavali, tak sa na to pozeráme, pozerám sa na to a vždy sa pozerám na to, čo ma bude stáť, aby som to napravil hneď teraz, v porovnaní s tým to môžem dostať len do plechovky a dostať to tam, a potom sledovať a uvidíme, či to bude zlomiť. A zdedím tento technický dlh, o ktorom viem, že musím krúžiť späť neskôr a opraviť ho.
A myslím tým, že som to urobil za posledných sedem dní: napísal som niekoľko nástrojov a skriptov, napísal som pár kúskov jazyka Python a nasadil som ho na zadnú časť Mongo, aby som sa ubezpečil, že je pekný, čistý a bezpečný, ale dostane iba dotaz, ktorý potrebujem, pretože viem, že potrebujem túto funkciu, aby som sa dostal k väčšej hádanke; to je miesto, kde je moja skutočná bolesť. A tak vám vznikol tento technický dlh, a myslím si, že to teraz nie je len príležitostná vec, myslím si, že je to súčasť DNA, ktorá sa teraz vyvíja. Ľudia jednoducho - nie neúprimne - jednoducho akceptujú technický dlh, ktorý je normálnym modus operandi typu emisie, a jednoducho mu musia vzniknúť. Je to miesto, kde vám vznikne technický dlh. A myslím si, že na tom, čo ste nám ukázali v ukážke, bolo skvelé, že ste mohli doslova profilovať a pozerať, ako dlho trvá beh. A to je asi jedna z mojich obľúbených vecí. Myslím tým, že som skutočne zostavil profilovacie nástroje - my sme stavali nástroje v Sed, Lex a Orc na spustenie nášho kódu a na zistenie, kde boli slučky, predtým, ako boli tieto nástroje k dispozícii - a keď si postavil kód, aby si skontroloval svoj vlastný kód , budete veľmi dobrí, keď nemusíte kontrolovať svoj vlastný kód. Teraz to však tak nie je. Existuje preto určitý trhový segment, ktorý to zaberá viac ako ktorýkoľvek iný? Vidieť ako omša -
Bert Scalzo: Ó, áno, ja som pre vás pripravil analógiu a ukážem vám, že to neprogramátori robia stále. Pretože ak niekedy učím debugger a profilovajúcu triedu alebo reláciu, opýtam sa ľudí: „Dobre, koľko ľudí tu chodí do programu Microsoft Word a zámerne nikdy nepoužívajú kontrolu pravopisu?“ A nikto nevyzdvihuje ruku, pretože píšu dokumenty, všetci vieme, že vieme robiť anglické chyby, a preto každý používa kontrolu pravopisu. A ja som povedal: „No, ako to, že keď píšete v IDE ako Visual Basic, nepoužívate debugger? Je to to isté, je to ako kontrola pravopisu. “
Dez Blanchfield: Áno, v skutočnosti je to veľká analógia. Naozaj som o tom nepremýšľal, musím priznať, že s niekoľkými nástrojmi, ktoré používam, skutočne robím niečo podobné. V skutočnosti jeden, ODF, môj najobľúbenejší program Eclipse je len vystrihnúť a prilepiť kód a ísť hľadať veci, ktoré sa hneď zvýraznia a uvedomím si, že som pri nejakom triednom hovore urobil preklep. A teraz je to zaujímavé s nástrojom, ako je tento, môžete to urobiť v reálnom čase, na rozdiel od návratu a pozerania sa naň neskôr, čo je celkom pekné chytiť ho vopred. Ale áno, to je veľká analógia, keď vložíte do textového procesora, spôsobíte jeho zaujímavé budenie, len si uvedomíte, že ste urobili nejaké preklepy alebo dokonca gramatickú chybu, však?
Bert Scalzo: Presne tak.
Dez Blanchfield: Takže teraz vidíte viac upticku, myslím, myslím, že posledná otázka odo mňa, predtým ako hodím na naše otázky a odpovede, pre našich účastníkov. Ak by ste chceli dať nejaký druh odporúčaní v súvislosti s týmto prístupom - predpokladám, že je to rétorika - je to tak, že sa do toho dostanete čoskoro a implementujete ho ako rozvíjajúci sa skôr, ako sa vyvíjate? Alebo je to tak, že sa prevažne staviate, pohybujú sa, stavajú niečo, čo potom prídu a profilujú to neskôr? Mám podozrenie, že je to v prípade skorého vstupu a uistite sa, že vaše kódy sa vopred vyčistia. Alebo je to tak, že by mali zvažovať túto časť svojho post-nasadenia?
Bert Scalzo: V ideálnom prípade by to robili vopred, ale pretože všetci sa nachádzajú v rušnom svete, v ktorom práve robia veci, nerobia to skôr, než narazia na problém s výkonom, ktorý nedokážu vyriešiť pridaním ďalších CPU a pamäte. na virtuálny stroj.
Dez Blanchfield: Jo. Takže ste vlastne spomenuli niečo zaujímavé, ak dokážem rýchlo? Už ste spomenuli, že sa dá spustiť odkiaľkoľvek a môžete hovoriť s databázou na zadnom konci. Je to teda pohodlné s akýmsi bimodálnym poňatím, o ktorom hovoríme teraz, s cloudom v premise / mimo premise, podľa vzhľadu vecí, na konci dňa, ak môže hovoriť so zadným koncom a vidieť kód, to je jedno, naozaj?
Bert Scalzo: Presne tak, áno, môžete to spustiť v cloude.
Dez Blanchfield: Výborne, pretože si myslím, že to je miesto, kam smeruje náš nový statočný svet. Takže, Eric. Teraz sa k tebe vrátim a uvidím, že sem dostal pár otázok a ja chcem, aby naši účastníci zostali s nami, aj keď išlo o hodinu.
Eric Kavanagh: Áno, je tam pár ľudí, len urobím rýchly komentár: Bert, myslím, že metafora, analógia, ktorú dávaš použitiu kontroly pravopisu, je úprimne brilantná. Je to hodné blogu alebo dvoch, úprimne povedané, pretože je to dobrý spôsob, ako načrtnúť kontext toho, čo robíte, aké cenné to je a ako by skutočne malo byť najlepším postupom používať debugger na pravidelne, však? Stavím sa, že keď vyhodíte tú hlavu, prikývne vám hlava, nie?
Bert Scalzo: Absolútne, pretože im hovorím: „Prečo v mojich dokumentoch vykonám kontrolu pravopisu? Nechcem sa trápiť hlúpymi pravopisnými chybami. “No, nechcú sa trápiť hlúpymi chybami kódovania!
Eric Kavanagh: Správny. Ano, naozaj. Ľudia, zhoreli sme tu hodinu a päť minút, takže vám všetkým ďakujem za váš čas a pozornosť. Všetky tieto webové rozhovory archivujeme, neváhajte sa kedykoľvek vrátiť a skontrolovať ich. Najlepším miestom na nájdenie týchto odkazov je pravdepodobne techopedia.com, takže tento zoznam pridajte priamo sem.
A s tým ťa chceli rozlúčiť, ľudia. Ešte raz, skvelá práca, Bert, vďaka našim priateľom z IDERA. Nabudúce sa s tebou rozprávam, vlastne s tebou budúci týždeň. Dávajte pozor! Zbohom.