Nebunia indexului: cum să evităm haosul bazelor de date

2024

Cuprins:

Partener de conținut Techopedia
Partener de conținut Techopedia

De personalul Techopedia, 5 octombrie 2016

Take away : Gazda Eric Kavanagh discută indexarea bazelor de date cu Dr. Robin Bloor, Dez Blanchfield și Bert Scalzo al IDERA.

În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.

Partener de conținut Techopedia

Personalul Techopedia este afiliat cu Bloor Group și poate fi contactat folosind opțiunile din dreapta. Pentru informații despre modul în care lucrăm cu partenerii din industrie, faceți clic aici.

Profil
website

Eric Kavanagh: Doamnelor și domnilor, salut, bineveniți din nou. Este o miercuri, la ora patru est, iar cei care știți programul, știu ce înseamnă asta, este timpul pentru un alt episod din Hot Technologies. Da, întradevăr. Numele meu este Eric Kavanagh, voi fi moderatorul dvs. pentru sesiunea de astăzi: „Index Insanity: How to Evites the Chaos Database”. Sau cum m-am referit la ea în ultimul blast de e-mail, care a ieșit, „wrangling database”. Termenul cald în aceste zile, „wrangling”. Toată lumea face asta. Există un diapozitiv despre al tău cu adevărat. Și destul despre mine.

Așadar, seria Hot Technology a fost într-adevăr concepută pentru a defini un anumit spațiu, spre deosebire de Briefing Room, care este doar o prezentare individuală a analistilor live, pentru Hot Tech obținem doi analiști. Astăzi, va fi chiar propriul nostru doctor Robin Bloor și omul nostru de date Dez Blanchfield. Și vorbim despre un subiect care cred că este într-adevăr destul de emblematic pentru ceea ce se întâmplă pe piață astăzi.

Concluzia este că suntem într-o lume de complexitate în aceste zile. Într-adevăr, dacă vă gândiți în urmă cu cincisprezece ani sau douăzeci de ani, atunci era o lume cu totul diferită, mai ales în ceea ce privește tehnologia bazei de date. Bazele de date erau destul de simple. Erau doar o mână de ele; cei mai mulți dintre ei erau relaționali. Acum, avem toată această panoplie a tehnologiilor de baze de date. Scoruri literalmente de opțiuni pe masă pentru oricine dorește să construiască o aplicație sau să facă ceva cu date. Totul se schimbă și asta afectează oamenii care încearcă să gestioneze aceste sisteme. Vom discuta astăzi cu Bert Scalzo, care este un adevărat expert în domeniu; el este cel mai mare management de produse pentru IDERA, despre ceea ce puteți face pentru a obține un control la toate aceste date. Cu asta, o voi înmâna doctorului Robin Bloor ca să o ia. Robin, podeaua este a ta.

Robin Bloor: Bine, mulțumesc pentru introducerea respectivă. O cred - pentru că este un lucru cu două mâini, cred că aș vorbi doar despre optimizarea bazelor de date, în general, ca o introducere la acest spectacol Hot Tech. Am început viața - în tehnologie și analiză - am început viața făcând acest lucru pentru că obișnuiam să scriu articole despre capacitățile bazelor de date de pe platforma DEC VAX. Și din acest motiv, cheltuitorii de baze de date obișnuiau să mă informeze. Iar ceea ce mi se întâmplă este acela, de ce ai avea o bază de date? Adică, în acele zile, o mulțime de oameni obișnuiți să creeze fișiere cu valoare cheie și să le folosească pentru a avea un fel de eroare secvențială de index așa cum le numim, dar pentru a crea un fel de capacitate de bază de date și știți, de ce ați avea altceva?

Și răspunsul la asta, cred că Michael Stonebraker a dat cel mai bun răspuns în acest sens, iar el a spus: „O bază de date poate ști mai multe despre unde sunt datele și cât de repede o puteți obține, decât orice program poate ști vreodată”. Și cred că este interesant; este natura jocului. Dar în anii 19 - cam pe la 1989, pe care am început-o în analiza tehnologiei și știți, în acel moment, bazele de date erau foarte simple și bazele de date relaționale erau super simple. Aveau o capacitate atât de mică, adică, puteau stoca date, evident, și puteți face o copie de rezervă și au avut, erau conforme cu ACID, dar aveau într-adevăr optimizatoare foarte slabe. De fapt, ar fi greu de susținut că au capacitatea de optimizare.

Și mai târziu s-au îmbunătățit din ce în ce mai bine, dar, știți, atunci când o bază de date nu funcționează - deoarece acești canguri par să fie într-un fel sau altul indicând - pot exista o mulțime de motive pentru care merge lent. Și asta mă aduce la punct: bazele de date au multe funcții, dar cea mai importantă este optimizarea interogărilor. Dacă nu ar face asta, nu le-ai folosi. Este vorba despre obținerea rapidă a informațiilor, este vorba despre posibilitatea de a o face atunci când există mulți utilizatori concurenti și asta este o problemă grea. Și când vă uitați efectiv la, să le numim baze de date mature, dacă doriți - dar cu siguranță Oracle, într-o măsură puțin mai mică, Microsoft SQL Server, cu siguranță Teradata și DB2 - optimizatoarele acestor baze de date au fost de câteva decenii în constructii. Știi, nu au reușit - cineva nu s-a așezat pe el - șase tipuri pentru un proiect de doi bărbați, an, și doar au strâns unul. Nu merge așa. Capacitatea de optimizare a crescut treptat și este foarte mare. Oricum, să vorbim despre fundalul bazei de date. Ei bine, acum se vorbește despre multe baze de date NoSQL și există foarte mult entuziasm pentru baza de date grafică. Și utilizarea SQL peste Hadoop și lucruri de genul acesta. Dar, adevărul este că, dacă doriți o bază de date chiar acum, dacă doriți o funcționalitate completă, capabilă de OLTP și trafic mare de interogări, este o bază de date relațională sau nu este nimic.

Printre bazele de date relaționale, Oracle este dominant în popularitate. Cred că Microsoft SQL Server este al doilea. Ambele sunt capabile să fie utilizate pentru OLTP și pentru sarcina de lucru de interogare, dar de fapt nu puteți scăpa de amestecarea acestor sarcini. Aveți nevoie de incidente diferite pentru sarcinile de lucru OLTP și pentru sarcinile de interogare. Există alternative la SQL și grafic. Majoritatea companiilor standardizează pe o bază de date specifică, motiv pentru care - Adică, după zeci de ani de luptă împotriva tuturor celorlalți jucători, Oracle a devenit cea mai dominantă. Pur și simplu pentru că au reușit să vândă licențe corporative, astfel încât companiile ar folosi produse alternative doar în produse excepționale, Oracle pur și simplu nu le-ar face. Iar bazele de date sunt strategice prin faptul că evoluează și ele. Și știți că am făcut un pic de cercetare pentru această prezentare și este cam așa ceva - Voi ajunge la ea într-un timp, dar este interesant cum evoluează ei, în ceea ce-l privește din poziția DBA. Asta numesc trendul invizibil. Este legea lui Moore cubicată. Este cam așa: cea mai mare bază de date este, iar bazele de date noi, nu există o bază de date veche care să obțină multe mai multe date. În mod normal, o bază de date este aplicată unei noi probleme. Și cresc de fapt în ceea ce privește volumul de date. Aproape la cubul lui Moore lege. Deci legea lui Moore este un factor de zece ori la fiecare șase ani. VLDB-urile tind să crească un factor de o mie la fiecare șase ani. În 1991, 1992, marile baze de date sunt măsurate în termeni de megabyte. În anii '97 și '98, gigabytes. 2003, '4, terabytes. În 2009, '10, ați început să vedeți baze de date petabyte. Cred că există una sau două baze de date exabyte în acest moment, dar cea mai mare despre care am auzit sunt cele 200 de petabytes la timp și știți că nu primiți date la o bază de date petabyte. Dar, cel mai mult, va fi, în mod evident, noile mari companii de web 2.0, eventual, veți avea pe Facebook direcția în această direcție.

Dar, oricum, dacă te uiți la asta, aștepți ca o bază de date să treacă prin acel tip de escaladare în volum, cere multe. Și în mod remarcabil, cu siguranță până la nivelul petabyte, se pare că s-au descurcat destul de bine. Adică, vorbesc despre produsele mai vechi decât despre ceva nou. Se pare că s-au descurcat extraordinar de bine. Dacă ne uităm la performanța bazei de date, blocajele, acest lucru mă readuce la perioada în care obișnuiam să mă îngrijesc de ele și a trebuit să mă îngrijorez. Știți că aceasta este în mod fundamental defalcarea hardware-ului. Există blocaje de procesor, eventual, există blocaje de memorie, eventual, există blocaje de disc, eventual. Poate fi rețeaua care îți provoacă durere și, de asemenea, poți avea probleme cu blocarea, în funcție de ceea ce faci, dar în mod normal, deoarece programul nu știe cine să apeleze la blocare. Așadar, dacă aveți de gând să reglați o bază de date, încercați de fapt să o reglați, astfel încât să danseze între aceste cinci blocaje posibile, la fel de bine. Și nu este o problemă ușoară, deoarece cantitatea de memorie pe care ai putea să o configurezi pe orice server este crescută dramatic. Atunci procesoarele au devenit multicore, pe disc, bine putem face acum, cred că, chiar și pe serverele de mărfuri, cred că puteți face sute și sute de terabyți, un sfert din petabyte, poate, chiar și pe un server de marfă. Deci, cu toate aceste lucruri, cu care te poți juca, rețeaua poate merge cu viteză diferită, dar mai ales când ai de-a face cu baze de date, vrei să ai într-adevăr cabluri de fibre între servere și nimic altceva să funcționeze pe asta, în special în acest fel.

Factorii de performanță a bazei de date. Vreau să spun, las în afară despre ce va fi vorba, pentru că știu că Dez va vorbi despre asta, dar proiectarea proastă a bazelor de date înseamnă o bază de date slab performantă. Proiectarea proastă a programării poate însemna aruncarea unui SQL foarte stupid la o bază de date, ceea ce va dura mult mai mult. Amestecul de concurență și volumul de muncă, o prea mare concurență va cauza probleme de blocare. Se amestecă volumul de muncă, atunci când aveți întrebări mari cu întrebări foarte mici, scurte și clare, care cauzează probleme. Există o problemă de echilibrare a sarcinii. Majoritatea bazelor de date au grijă de asta, dar dacă nu ai un produs sofisticat, atunci știi, adăugând doar câteva servere, nu este tot ce faci dacă de fapt vrei să crești dimensiunea unui cluster. De fapt, trebuie să echilibrați încărcarea înainte de a obține performanțele optime. Trebuie să faceți planificarea capacității. Absolut. Mai ales acum în aceste zile, când volumul de date crește mai mult decât se obișnuia pentru bazele de date. Și există probleme întregi de straturi de date cu privire la modul în care ingerați datele, la modul în care mutați datele. Nereptarea datelor la o bază de date la timp poate fi o problemă de performanță mai târziu, deoarece am trecut de la baze de date care funcționează în Windows, la douăzeci și patru la șapte cu trei sute șaptezeci și cinci de funcționare și nu există ferestre unde să puteți încetini baza de date în jos sau este puțin probabil să existe în zilele noastre.

Problema Oracle DBA. La asta mă gândeam. Am fost în DBA-ul Oracle cu Oracle 7 și îmi aduc aminte cum să pot face asta. Și dacă te uiți acum la Oracle, este într-o manieră, este mult mai capabilă. Are indexări de hărți de bit și lucruri de genul acesta, dar de fapt am luat timpul să mă uit și să văd câți parametri de reglare există de fapt într-o bază de date Oracle. Și există peste trei sute cincizeci de parametri de ajustare și există încă o sută de parametri ascunși, despre care ar putea ști DBA-urile de specialitate, dar DBA-urile Oracle normale nu știu. Și asta înseamnă că ajustarea acestui tip de bază de date este un lucru dificil. Nu este deloc un lucru simplu. Trebuie să aveți o idee pentru asta, trebuie să o faceți de mult timp și trebuie să știți exact care este problema pe care credeți că o rezolvați, deoarece reglarea începe atunci când performanța devine slabă, dar s-ar putea să nu fie performanța tuturor. S-ar putea să fie performanța unor interogări specifice care contează și este posibil să o puteți remedia prin fixarea anumitor date și memorie, sau poate fi necesar să o remediați prin indexare sau poate fi necesar să începeți să faceți partiționarea într-un mod diferit. Puteți face multe lucruri, este ideea. Prin urmare, nu o vor face în cap - DBA-urile au nevoie de instrumente. Voi transmite acum lui Dez care va spune despre indexare, cred.

Eric Kavanagh: Bine Dez, ia-o.

Dez Blanchfield: Mulțumesc, Robin, și îmi place pagina de întâmpinare . Cred că ai aruncat mănușa acolo pentru ca eu să mă apropii chiar și de la distanță de ceva atât de interesant. Însă am folosit o imagine a micii noastre galaxii, așa cum mi s-a transformat provocarea de astăzi pentru administratorii bazelor de date, deoarece aceasta este imaginea mentală pe care tind să o conjurez când intru într-un mediu și nu mai sunt în lumea administrării bazelor de date sau a proiectării bazelor de date la acel nivel. Dar, ca și tine, Robin și cu mine am avut mulți ani în care suntem implicați în lumea bazelor de date, fie ca administrator sau dezvoltator, sau în cele din urmă arhitect, și atunci ne-am dat seama că pot face lucruri mai bune pentru a câștiga o crustă. Dar are tendința de a simți că te uiți la această galaxie de date și mai mult chiar astăzi, când plecăm, așa cum ai subliniat, am trecut de la megabytes la petabytes și exo-scale într-o perioadă foarte scurtă de timp, în marea schemă a lucrurilor. Dar sintagma pe care o am în minte este că indicii bazei de date sunt acum o artă neagră și nu sunt într-adevăr genul de chestii în care simpli muritori ar trebui să se descurce, pentru aplicații de afaceri de tip business și tipul de a te formula vorbeau doar despre. Dar, am vrut să trec printr-o scurtă expunere a tipului de istorie pe care l-am avut cu lumile bazelor de date și să aduc contextul în care vom trage o concluzie, iar apoi să parcurgem câteva materiale cu astăzi cu prietenii noștri IDERA, pentru că cred că există o mulțime de gândiri diferite despre cum să obțineți ajustarea performanței bazelor de date și unul dintre ei aruncă staniu. Pentru o mulțime de magazine pe care le întâlnesc, în mod invariabil nu ajung la punctul de a face reglarea performanței la nivelul bazei de date și, în special, la nivelul indexului, până când nu au parcurs traseul greu de gândit că pot arunca un tuner. .

Mulți oameni fac doar o minte abordare a fierului, în mintea mea, și am o poză cu The Flash aici, pentru că dacă ați vizionat vreodată filme vechi sau cu siguranță cele mai recente emisiuni TV cu The Flash, ca în Flash Gordon vechiul personaj, iar acum după ce este numit „Flash”, el tinde să treacă foarte, foarte repede și invariabil energia lui se scurge. Și acest lucru se întâmplă când arunci fier mare la performanța bazei de date. In mod invariabil, în experiența mea, puteți pune în joc performanță, muncă asiduă, puteți să vă optimizați sistemele de operare și să le reglați într-un anumit punct. Vă puteți asigura că aveți CPU multicore, multitreading pentru a face ca aplicația să ruleze mai repede, puteți arunca o mulțime de memorii RAM la ea, puteți avea planuri de rezervă cu un randament ridicat, puteți trece de la hard disk-uri la hard disk-uri în cache la starea solidă și o gamă de stocare performantă. Și chiar acum, oamenii aruncă lucruri precum flash și NVMe la motoarele lor de baze de date, crezând că vor obține acest timp de conectare cu două performanțe. Și invariabil obțin un câștig. Însă, totul revine la aceleași probleme de bază ale reglării performanței. O mulțime de conexiuni de rețea cu latență scăzută, astfel încât grupurile să funcționeze rapid. Și de infrastructură de bază de baze de date, așa că ai mai mult de o singură mașină care face toată munca. Dar tindeți să reveniți la aceeași problemă de performanță de bază, iar aceasta este citirea datelor. Scrierea de date este, în mare parte, o provocare destul de liniară și dacă nu sunt făcute corect.

Și atunci avem provocarea în lumea de azi: Nu toate bazele de date sunt create egale. Există baze de date și „baze de date” de la cotație la ofertă. Și atunci când ne gândim la motoarele de baze de date, oamenii se gândesc adesea la bănuții tradiționali, obișnuiți, așa cum erau în lumea SQL. Știți, avem Oracle și Microsoft SQL Server și există câteva persoane în jurul său în lumea open source cu MySQL, care este acum deținută de Oracle, dar este încă open source. Și atunci avem suspecții atât de obișnuiți, motoarele NoSQL, care au încă o problemă în ceea ce privește indexarea și gestionarea performanței și nu voi intra în ele într-o mulțime de detalii, dar există un număr din ce în ce mai mare. lucrurile apar în fiecare zi și arată și se simt ca motoare de baze de date din punct de vedere al dezvoltatorilor și din punct de vedere al performanței, dar sunt fiare foarte, foarte diferite și au propria lor nișă în lume pentru a le sculpta fie. performanță în memorie sau scară liniară pe disc. Dar așa arată lumea în baza de date. Aceasta este 2016, aceasta este versiunea a trei a hărții, de către o gamă de oameni care produce această hartă peisagistică în curs a aspectului bazelor de date și de aici - nici măcar un arhitect de baze de date supraumane sau un administrator de baze de date ar putea avea sens. din ea. Literalmente sute și sute și sute de mărci diferite, modele, producători de baze de date, compatibile în mod invariabil SQL. Și interesant este că toți revin la aceeași provocare. Reglarea performanței și a performanței în jurul motorului bazei de date și, în special, prin modul în care datele sunt indexate.

Așa că haideți să acoperim rapid indexarea bazelor de date, deoarece este un subiect interesant și trebuie să intrați mai detaliat în ea cu demo-ul, cred. Dar, cred că este destul de bine acceptată și practica standard a industriei că reglarea performanței indexului bazei de date este locul în care lumea începe și se încheie în măsura în care asigurarea accesării datelor dvs. într-un format rapid și rapid. Dar ce este indexarea bazei de date? Dacă ne gândim la indexare sub forma cu care suntem obișnuiți ca oameni de zi cu zi, gândiți-vă la o pagină de index dintr-o carte. Dacă doriți să găsiți ceva într-o carte - în special aprecierile unei enciclopedii, sau ceva de genul unui material de referință de o anumită formă - dacă căutați ceva ca această pagină, unde caut lucruri precum subiectul barajelor într-o enciclopedie. Vreau să găsesc orice referire la baraje, capătul de apă și o mare suprafață de construcție, creată în general de om. Voi merge în spate, o voi găsi într-o listă alfabetizată, ordonată, de la A la Z, de la stânga la dreapta și voi găsi D. Voi găsi cuvântul „baraje” și îl pot vedea pe paginile 16, 38, 41 există o referire la ele și apoi pot merge la acele pagini, pot scana ochii în jos și voi găsi referința la cuvântul „baraj”. În esență este același concept într-o bază de date, dar acum este o știință a rachetelor în multe feluri. Atât de mult, încât, în mod efectiv, fiecare administrator al bazei de date pe care l-am cunoscut vreodată, consideră indexurile ca fiind unicul instrument cel mai critic pentru ajustarea performanței în orice lume a bazelor de date, indiferent de experiența lor în măsura în care aruncă staniu la ea sau indiferent de caz.

În general, când vorbim despre indexarea bazelor de date, există o serie de abordări comune. Și cu cât indexurile bazei de date sunt mai complexe, cu atât abordarea indexării datelor este mai complexă. Dar, în esență, când vă gândiți la indexarea datelor - imaginați-vă că avem un fișier care are o listă de nume; acestea nu pot fi sortate în ordine alfabetică. Să ne imaginăm că sunt douăzeci. Dacă vom sorta - dacă vom căuta datele din acea listă, de sus în jos, și să zicem că este o listă de nume. Dacă aleg un nume aleatoriu și încep să derulez acea listă, de sus în jos, într-un format liniar și este o listă neordonată, există două criterii la care mă gândesc ca timp mediu de căutare și timpul meu maxim de căutare - și Am o dactilografie în a doua linie, ar trebui să fie „timpul maxim de căutare”, îmi pare rău - dar timpul meu mediu de căutare este, în esență, N plus unul, împărțit la două, iar asta este în medie, îmi ia cincizeci la sută din timp pentru a scana din partea de sus a listei, până în partea de jos a listei pentru a găsi orice lucru aleatoriu în acea listă. Iar cea de-a doua linie, sub linie, ar trebui să fie „timpul maxim de căutare”. Dar timpul maxim de căutare este în esență numărul de articole și asta este că dacă am o listă de douăzeci de lucruri, cel mai mult timp îmi poate lua a căuta ceva în acea bază de date înseamnă a merge de sus în jos, adică să zicem 20 de elemente din acest exemplu simplificat. Și este un proces foarte lent și nu există cu adevărat nicio modalitate de a ajusta performanța. Și apoi, există alte tipuri de modalități de a lua respectivele date și de a crea un index, care este în mod efectiv o scurtă listă de indicatori până unde se află datele reale, cum ar fi binarul, arborele B, bitmap, hashing, clusterul și non-clusterul, și apoi există diferite tipuri de date, cum ar fi spațial, filtrat, XML și text complet.

Binary este unul foarte frecvent utilizat pentru lucrurile în care datele se acordă. B-tree este probabil cel mai comun într-un sens general, din punct de vedere istoric, prin faptul că este o modalitate comună de a structura un index la orice formă de date și permite înregistrările, selecțiile, iar inserțiile și ștergerile sunt relativ ușoare pe măsură ce deplasați indicatoarele în jurul referire la indicatoare, puncte. Există și alte tipuri, cum ar fi bitmap-ul, unde tipurile de date se preocupă ca dacă avem o gamă asociată de o anumită formă. Hashing funcționează foarte bine pentru obiecte mari, în special bloguri și imagini. Și puteți vedea că există o serie de abordări științifice diferite, abordări matematice, pentru indexarea datelor. Pentru simplul muritor, sunt o provocare interesantă despre care să vorbim la acest nivel. Când vorbești despre asta la nivel de performanță pentru un administrator de baze de date, ei devin într-adevăr un om de știință al rachetelor și oamenii fac diplome în ele și știu că doctorul Robin Bloor a făcut cu siguranță asta, și au scris cărți despre acesta pentru IBM și alte mărci mari în ultimele două decenii. Și așa, părerea mea este că am trecut de fapt o perioadă în care, știi din când în când, personal aș fi capabil să stau în fața unui sistem și aș fi capabil să îl desprind și să-ți arăt exact unde s-au aflat problemele de performanță la o linie de comandă sau la un instrument de pornire a interfeței grafice pentru utilizator și începeți să vă delimitați în date și să vă spun unde au fost problemele și să construiți indexuri sau subindexuri sau indexuri primare și secundare în acel date și începe să-l folosească pentru a găsi lucruri. Dar când vă gândiți la acel peisaj pe care vi l-am arătat, unde avem sute și sute de mărci, modele și modele, precum și producători și tipuri de baze de date, suntem bine și cu adevărat trecuți de acea vreme acum, unde o ființă umană poate face sensul tipurilor de motoare de bază pe care le avem. În special, chiar dacă ne întoarcem doar la aprecierile Oracle, în zilele noastre, mărci predominante în platformele relaționale de baze de date.

Numărul de baze de date cu care trebuie să se ocupe fie de la o platformă proprie, cum ar fi un ERP, HR sau un sistem de finanțe, fie că este o platformă gătită acasă din diverse motive, numărul de baze de date și tabele de baze de date și înregistrări pe care le încheiem. Afacerea este doar astronomică și fizic nu o poți face manual. Și acum am avut o complicație suplimentară, când odată, un server de baze de date ar putea sta doar sub biroul tău. Știți, ca un copil mic după școală, am fost să merg și să lucrez la software-ul bazei de date pe, inițial, sistemele Apple IIes și apoi DOS, bazate pe PC, cum ar fi dBase II, dBase III, au trecut printr-o eră cu mainframe și mijlocul interval și chiar VAX și PDP și fișier jurnal pe care. Și cum ar fi Saber, și apoi în cele din urmă când au apărut unele dintre bazele de date SQL. Dar zilele acestea, când ne gândim la motoarele bazei de date, arată ca în colțul din stânga jos. Un server de baze de date nu mai este doar o mașină care stă pe podea sub un birou; Este vorba despre sute de mașini care rulează copii ale motoarelor bazei de date și clustere și fac o scară până la sute și sute de terabyți de date, dacă nu petabytes de date, care sunt mii de terabyți. Și chiar până la extremă, așa cum a menționat medicul Robin Bloor, că unele cazuri specifice de utilizare - companii aeriene, în special agenții guvernamentale - pot ajunge la exabytes. Sunt încă destul de nișe, dar sute de terabyți și chiar zeci de petabytes nu mai sunt neobișnuite, în special din boom-ul dotcom până în prezent, așa cum numim companiile web 2.0, like-urile Facebook, Google, Yahoo si asa mai departe.

De asemenea, avem complicația acum că lucrurile se îndreaptă către serviciul extern. Avem la dispoziție o platformă și un software de infrastructură ca o abordare de furnizare a infrastructurii. Și în special serviciul platformei, unde nu putem cumpăra doar pentru Oracle și platforma lor cloud, baze de date și servere. Așadar, acest lucru ne permite să facem o dezvoltare foarte rapidă a aplicației și doar să conectăm o bază de date înapoi la servere. Nu trebuie să ne gândim la ce se află sub capotă. Dezavantajul este că de multe ori nu ne gândim la modul în care proiectăm și punem în aplicare baza de date până când nu începe să doară și performanța devine o problemă, iar apoi ajungem să trebuie să căutăm instrumentul potrivit pentru a diagnostica de ce durează baza noastră de date și unde sunt problemele de performanță. Și invariabil o readuce la acea problemă comună a modului în care am indexat aceste date și tipurile de indici pe care i-am folosit pentru aceste date și care ne readuce la cerințele de performanță supraumană. Și cineva care are acces la sistemele potrivite și la instrumentele potrivite de performanță ajustează motoarele și începe să găsească un punct fierbinte și să se uite unde sunt interogările, unde se mișcă datele, tipurile de interogări, modul în care sunt structurate interogările, cine face interogările și dacă întrebările sunt puse în coadă și trebuie să fie memorate în cache. Ce replică căutați?

Și deci suntem bine și cu adevărat - după părerea mea - într-un moment în care chiar și cei mai buni guru ai bazelor de date din lume, în esență arhitecții bazelor noastre de date și administratorii bazelor de date și bazele de performanță, din punctul meu de vedere trebuie foarte mult să înceapă să utilizeze instrumentele potrivite pentru a oferi o ajustare optimă a indexului de performanță pentru orice motor de bază de date. Deoarece amploarea cu care avem de-a face și viteza cu care se mișcă lucrurile, pur și simplu nu o putem face de mână și încercând să facem asta invariabil poate introduce alte probleme de performanță, deoarece este posibil să nu avem experiență în acel spațiu. încercăm să rezolvăm o problemă. Și cred că acolo suntem pe punctul de a-i înmâna lui Bert și urmează să vorbim despre cum au rezolvat această problemă variată și despre tipul de lucruri pe care le poate face instrumentul lor face, în special pentru lumea Oracle. Și cu asta acolo, Bert, voi trece pe la tine.

Bert Scalzo: Mulțumesc. Bine ați venit tuturor, numele meu este Bert Scalzo, lucrez pentru IDERA. Sunt senior manager de produse pentru unele dintre produsele noastre din baza de date. Voi demonstra unele dintre cele de azi. Vreau însă să vorbesc despre indexuri, pentru că sunt de acord cu tot ce au spus aici, în special ultimul slide, că indexurile sunt atât de complexe acum, încât ai nevoie de un instrument și sper să te conving. Deci, design-ul indexului Oracle, nu este atât de ușor pe cât era pe vremuri. Mulți oameni nu vor fi siguri de ei înșiși când vor privi opțiunile și îmi place acest lucru spunând că am scos din istorie, „în aceste chestiuni, singura certitudine, este că nimic nu este sigur”. simțiți-vă despre indexuri în aceste zile, pentru că chiar dacă credeți că știți răspunsul ar trebui să indice X, Y sau Z, nu puteți fi sigur până nu îl încercați, deoarece acei optimizatori se comportă diferit în funcție de modul în care vă așteptați. Și deci există o mulțime de încercări și erori cu designul indexului. Acum, pe vremurile bune, dacă aveai nevoie de un index, în general, erau doar două întrebări sau o singură întrebare. A fost unic sau nu a fost unic? Și s-ar putea să vă gândiți la alte lucruri de genul: „Câți indici pot avea maxim pe un singur tabel?”, Deoarece prea mulți indici încetinesc inserțiile, actualizările și ștergerile. S-ar putea să fi fost și tu în sistemul tău de baze de date, ai avut restricții cu privire la câte coloane ar putea fi într-un indice cu mai multe coloane, deoarece uneori erau limite bazate pe dimensiunea paginii sau a blocului motorului bazei de date, dar în realitate era destul de simplu înapoi în vremurile bune. L-ai indexat sau nu l-ai făcut. Și într-adevăr, totul era într-un copac B. Am putea permite duplicatele sau nu, și asta a fost despre asta. Viața era bună, viața era simplă.

Ei bine, astăzi, viața nu este atât de bună sau atât de simplă. Am pus semnul Ghostbuster roșu prin modul în care obișnuiam să îl facem, deoarece acum avem B-tree versus bitmap, versus bitmap join. Și voi explica ce sunt unele dintre acestea într-o clipă. Gruparea și non-clusterul, unic sau duplicat, înainte sau invers ordine, bazat pe funcții, partiționat sau nu partiționat. Dacă există o partiționare implicată, este o compartimentare globală sau locală? Voi explica și asta. Și apoi există și ceva numit tabel organizat indexat. Și, de fapt, am mai părăsit aici o jumătate de duzină, pentru că cred că am ajuns aici destul de mult, care ar trebui să vă convingă că indexurile sunt mult mai dure decât v-ați fi putut crede. În acest diapozitiv special, voi începe în partea din stânga sus a diagramei și am un tabel. Și primul lucru pe care trebuie să-l decid este, în funcție de versiunea bazei de date și de vânzătorul bazei de date, permit tabelele de obiecte sau sunt doar relaționale? O să merg pe partea dreaptă și voi spune că construim o masă relațională. Acum, următoarea întrebare pe care trebuie să mi-o pun este: este într-un grup? Și mulți dintre voi care ați făcut Oracle de ceva timp vă vor aminti că grupurile au fost din nou pentru Oracle 6 zile. Probabil că nu mai sunt foarte folosite astăzi, dar permiteți-mi să cobor în prima ramură.

Dacă aveam de gând să-mi pun tabela într-un cluster, ar trebui să am un indice grupat pe acel tabel. Acum, în Oracle, când ați grupat o tabelă, în principiu, stocați rândurile sau rândurile erau aproape unul de altul, unde valorile erau similare. Și deci, trebuie să aveți un indice grupat și acel indice grupat ar putea fi nepartitionat. Cu alte cuvinte, nu existau într-adevăr metode de partiționare pentru modul în care ai face un tabel grupat. Era strict nepartitionat. Și pentru că era fără partiție, era global. Voi explica ce este global într-un minut. Și a fost întotdeauna B-tree. Cu alte cuvinte, când am coborât pe acea filială, era destul de simplu, nu am avut multe opțiuni. Acum, dacă am făcut un indice non-grupat pe un tabel grupat, care a fost permis în unele versiuni, din nou a fost nepartitionat; când nu este partiționat, atunci singura ta alegere este globală. Și deci, ai posibilitatea de a alege B-tree sau bitmap. Din nou, depindea de versiunea dvs. de bază de date. Dar acum, să revenim la masa relațională și să începem să coborâm din nou pe partea dreaptă și acum vom avea doar o masă simplă, veche, obișnuită, relațională: relațională. Va fi într-un spațiu de masă. Mai întâi cobor pe partea dreaptă aici. Deci organizare, grămadă. Următoarea întrebare pe care trebuie să mi-o pun este „Vreau să partiționez acest tabel sau nu?” Acum, uneori te-ai despărțit pentru că te-ai gândit: „Hei, optimizatorul va fi mai inteligent despre cum poate optimiza interogările. ”Dar o mulțime de DBA-uri vă vor spune că motivul pentru care faceți acest lucru este în scopuri administrative. Dacă aveți o tabelă de o sută de miliarde de rânduri, dacă o împărțiți în partiții sau găleți, atunci când doriți să adăugați date la ultima găleată, puteți arunca și indexa doar câteva milioane de rânduri. Puteți introduce aceste date și apoi puteți reconstrui acel index doar pe acea găleată.

Deși a fost o tehnică bună pentru unii, tehnici de optimizare, cum ar fi eliminarea partițiilor, valoarea sa reală a fost posibilitatea de a administra sau de a face sarcini administrative pe piese mai mici. Când merg la grămada organizațională, prima întrebare a fost „Am împărțit-o sau nu?” Să mergem la stânga, nu mă voi despărți de masă. Acum, poate părea ciudat când îți spun acest lucru, dar ai putea avea o tabelă care nu este partiționată și atunci nu poți diviza indexul așa cum te-ai obișnuit sau poți împărți indexul. Opreste-te si gandeste. Masa dvs. are practic o găleată, așa cum v-ați gândit întotdeauna, și totuși, indicele dvs. va avea mai multe găleți. Când se întâmplă asta, unde există o nepotrivire între numărul de găleți și tabel și numărul de găleți din index, asta înseamnă ceea ce înseamnă global. Și deci, dacă tabelul nu este partiționat și dacă indexul este partiționat, este considerat global, pentru că există o nepotrivire. Acum, dă-mi voie să mă întorc la grămada organizației mele și să cobor în locul partiției. Acum, dacă am un tabel de partiții și să zicem că tabelul are patru găleți, patru partiții, indexul meu ar putea avea patru găleți, astfel încât indicele meu să se potrivească cu designul tabelului meu. Și așa s-a terminat, mult peste cap, pe partea dreaptă. Asta ar fi considerat local. Un index local înseamnă practic că partiționarea tabelului și a indexului se face la fel și are același număr de găleți. Și apoi odată ce am indexul local, acesta ar putea fi un arbore B sau un mapă de biți, iar această săgeată verde care genul acesta se ridică, îți arată că, chiar dacă este un arbore B, încă mai pot fi făcute alegeri. Ar putea fi bazat pe funcții. Și, de asemenea, dacă este o hârtie de bit, există diferite tipuri de hartă. Există ceva numit index index de aderare. Dacă faceți depozitare de date, acesta este un fel de index foarte popular pentru schema sau designul stelelor. Ceea ce se întâmplă este că indexul are ID-urile pentru ceea ce indică în tabel, dar va avea și ID-uri de rând pentru tabelele părinte, astfel încât atunci când sunteți - trebuie să stabiliți designul schemelor și să căutați la un tabel de fapt, acel index din tabelul de fapt vă indică datele care vă interesează și vă indică fiecare rând din dimensiunile dvs., astfel încât trebuie să aveți un singur index.

Și, de fapt, acest lucru a luat naștere din cauza Red Brick, care era o bază de date cu mulți ani în urmă - o mulțime de oameni poate să-și amintească asta. Și uite, dacă te uiți la această imagine - și ții minte că nu am pus totul în această imagine, deoarece imaginea ar fi mult mai mare - mai există probleme suplimentare, pe care le am în text aici în partea superioară dreaptă . Este un indice de ordine inversă? Și ați putea spune: „De ce aș dori un index de ordine inversă? Asta nu are niciun sens. ”Dacă vă aflați într-un mediu încorporat în Oracle, dacă faceți clustere de aplicații reale, dacă vă mențineți indexurile în ordine, deci neinversate, dacă aveți multe prelucrări care lovesc. aceleași valori sau aceleași valori ale indexului, ceea ce s-ar întâmpla este că ai avea zone fierbinți din arborele tău B. În sensul că ai avea conținut și, eventual, blocarea pentru a încerca și accesa acele chestii și ai face asta pe nodurile dintr-o rețea. Ei bine, dacă introduceți un index de ordine inversă, acum puteți anula asta. Puteți spune: „Ei bine, valorile similare sunt în diferite părți ale copacilor, așa că nu am nodurile mele separate în competiție pentru zonele fierbinți din copac”. Și apoi observați că unicul nu funcționează cu unele dintre opțiuni. . Dacă te uiți, am numerotat trei, cinci, opt și unsprezece, așa că există unele cazuri în care nu pot avea un index unic. De asemenea, există unele cazuri în care nu pot avea un indice invers și atunci există probleme suplimentare precum logarea sau nicio înregistrare și paralel și non-paralel. Pot atribui lucruri unei zone specifice din memorie.

Și acest lucru lasă în continuare o mulțime de caracteristici în Oracle. Aș spune că atunci când te uiți la Oracle 12, probabil că din nou ar putea adăuga la această imagine o jumătate de duzină de lucruri. Indexarea este într-adevăr complexă și sunt de acord cu vorbitorul anterior, pentru a naviga prin aceasta și a face o alegere bună, aveți nevoie de un instrument. Aveți nevoie, poate, de o poză de genul acesta și un fel de metodologie despre cum ați alege lucrurile și sperăm că instrumentul vă va ajuta să ajungeți acolo. Și atunci va fi proces și eroare. Le spun mereu oamenilor că se indexează, „uită-te înainte de a sări”. Și atunci poți vedea micuțul câine aici, sare fără să se uite, va sfârși în apă cu rechinul sau tipul care se pregătește să sară în apă și el se va impala. Trebuie să vă gândiți la indexarea dvs., deoarece crearea unui index nu înseamnă întotdeauna că lucrurile se îmbunătățesc. De fapt, crearea unui index poate încetini lucrurile. Iar performanța interogărilor poate fi mai bună pentru o ordine de amploare cu o alegere față de alta. Și vă voi da un exemplu bun. Dacă faceți o schemă de design de stele, iar pe tabelele dvs. de dimensiuni utilizați indexuri de bitmap într-un caz, iar în alt caz, spuneți: „Voi folosi indexuri B-tree”, aveți hartă de bit față de B- copac. Pot să vă spun că o soluție va fi o ordine de mărime sau, eventual, mai multe ordine de mărime mai rapid decât cealaltă. Dar rețineți ce funcționează într-un mediu, cum ar fi într-un mediu de stocare a datelor, probabil că nu este o alegere bună într-un mediu OLTP.

De exemplu, dacă ar trebui să luați o tabelă tranzacțională și să puneți indici bitmap pe o tabelă tranzacțională, este costisitor să calculați și să resetați mapele de bit, aceste șiruri lungi și, astfel, într-un tabel OLTP, este posibil să atingeți tabelul atât de puternic încât bitmap-ul indexul poate deveni corupt și încetinește sistemul, deoarece nu sunt destinate doar actualizărilor. Sunt excelente pentru acces rapid, dar nu sunt bune pentru actualizări. Cred că indexul ia încercare și eroare. În realitate, nu există nici o regulă de aur - există prea multe variabile diferite în această ecuație - și în final va trebui să analizați execuția sau să explicați planurile din baza de date pentru a vedea dacă faceți sau nu selecții bune. Și uneori, analiza planului poate fi aproape o știință pentru sine. Nu voi acoperi asta astăzi - acesta este un alt subiect - dar nu luați design-ul indexului de la sine. Există motive legitime pentru care există toate aceste tipuri de index nebune pe care vi le-am arătat în imaginea anterioară și despre care vorbește vorbitorul anterior. Acestea nu au fost create doar pentru că era o caracteristică îngrijită de a pune pe lista de verificare undeva pentru un furnizor de baze de date; există cazuri de utilizare sau scenarii în care acești indici sunt importanți și vor face o diferență semnificativă. Acum, cu asta, vă voi arăta câteva exemple de diferite tipuri de indexuri într-unul din instrumentele noastre. Permiteți-mi să ridic ecranul, astfel încât să puteți vedea. Bine, așa că aici stau înăuntru - permiteți-mă să minimizez această aplicație. Stau în interiorul VMware și rulez un Windows Server 2012 VM.

Și puteți vedea, am aproape toate instrumentele cunoscute de om. În calitate de manager de produse, trebuie să fiu la curent cu concurența mea, deci nu este doar ce instrumente am, ci ce fac concurenții mei? Și avem acest instrument numit DBArtisan, pe care l-am folosit deja, dar merg - așa că îl voi aduce. Și ceea ce puteți vedea este un instrument cu adevărat drăguț, pentru că în loc să folosiți, spuneți un manager de întreprindere pentru Oracle și un SQL Management Studio pentru SQL Server și MySQL Workbench pentru MySQL și alte douăsprezece baze de date pe care le acceptăm, bine, am toate bazele de date încorporate într-un singur instrument. Există DB2, există MySQL, Oracle, Postgres, SQL Server și Sybase, și asta este - Am doar șase baze de date în acest lucru special pentru că nu pot - instrumentul acceptă douăsprezece baze de date, dar marea mea VM, rulând șase baze de date concomitent și încercând pentru a face o demonstrație, este cam la fel de mult ca facilitarea hardware-ului meu. Așadar, permiteți-mă să mă întorc în Oracle și, dacă observați, toate aceste lucruri sunt la fel. Dacă vreau să-mi măsoară performanța în DB2, sunt aceleași alegeri pe care le-aș avea în Oracle. Acum, sub coperte, facem multe lucruri diferite, astfel încât să nu trebuie să știți ce se întâmplă, dar vă oferim o interfață consistentă, astfel încât să puteți fi un expert cu mai multe platforme de baze de date. Și asta ar include lucrul cu indexuri, subiectul acestei discuții.

Permiteți-mi să vin aici și să mă apuc să încep mai întâi, să mă uit la câteva tabele și am o bază de date pentru filme care are doar câteva tabele. Și dacă mă uit la un tabel anume, cum ar fi tabelul pentru clienți, atunci când îl aduc aici, pot vedea designul mesei mele, aici sunt coloanele din tabelul meu și aici informații despre fiecare coloană. Am proprietăți pentru tabel, dar rețineți că am o filă aici pentru indexuri și pot vedea aici sunt indexurile de pe tabelă. Observați că unul dintre acești indici este indicele PK, cheia mea principală. Acești alți par să fie doar indexuri pentru îmbunătățirea accesului la interogare, poate căutăm prin nume sau prenume sau ne uităm la telefoane și coduri poștale. Și dacă aleg un anumit index, cum ar fi acest cod poștal aici, și fac dublu clic pe el, acum pot vedea asta, hei, este un indice non-unic și iată câteva dintre celelalte tipuri, hartă de biți, non-unică, unic, indiferent dacă este sau nu sortat, indiferent dacă este sau nu acea înregistrare, indiferent dacă este sau nu ordine inversă, indiferent dacă este o bază de funcții. Oh, iată o distracție pe care nu am acoperit-o. Puteți avea indici invizibili. Și ai spune: „Ei, de ce naiba aș vrea să fac un indice invizibil?” Ei bine, îți voi da un exemplu bun. Vă aflați în sistemul de producție și aveți o problemă de performanță și nu sunteți sigur că crearea indexului va rezolva problema, deci nu doriți să creați indexul și să încetiniți producția, dar cumva sau altul doriți fi capabil să-l testezi. Puteți crea indexul în producție ca fiind invizibil, ceea ce înseamnă că nu multe coduri ale aplicației, apelând la optimizator, vor folosi acel index. A fost creat, este valabil, dar nu va fi folosit. Apoi puteți lua o întrebare cu care credeți că ar putea ajuta acest index sau o serie de întrebări și puteți să adunați un indiciu și să spuneți: „Hei, optimizator, există un indice invizibil acolo pe care vreau să-l folosești și să lași Știu dacă am îmbunătățit lucrurile. ”Și acum am testat ceva în producție, dar nu am rupt aplicațiile în producție care rulau. Aceasta este utilizarea unui indice invizibil. Sună mut când auzi prima dată despre asta, dar are un folos.

Putem, de asemenea, să definim dacă sunt paralele și câte cazuri sunt paralele. Acum, într-un mediu de cluster de aplicații non-cluster sau non-real, astfel încât non-rack, paralel ar însemna cât de multe sub-procese pot interoga întrebarea mea pentru a încerca și procesele de lucru, pentru a încerca să obții ceva mai repede sau mai repede. . Și instanțele paralele ar fi, dacă mă aflu într-un adevărat cluster de aplicații, să spun că am zece noduri, câte dintre noduri am voie să împărțesc munca? Poate este patru din cele zece și pe fiecare dintre ele, patru subprocese. Acesta este un exemplu. Și atunci avem compresie cu cheie. Puteți comprima efectiv indexuri? Da sau nu. Și atunci, desigur, aveți parametrii de stocare pe care îi puteți specifica pe indexuri. Acum, nu le-am acoperit pentru că sunt cu adevărat mai mult un parametru de stocare decât o problemă de index. Și apoi, în sfârșit, avem dacă să facem sau nu aceste partiții sau nepartitionate. Lasă-mă aici pentru o secundă. Voi merge la o schemă diferită. Aceasta este o schemă cu stele și, de exemplu, acest tabel de perioadă este un tabel cu dimensiuni. Dacă ați făcut vreodată o schemă de stele, de obicei aveți o dimensiune de timp, deci în această bază de date și în această schemă stelară, perioada este o dimensiune de timp. Acum, știu că va arăta amuzant, vei spune: „Gee, uită-te la toate acele coloane - a auzit vreodată tipul despre normalizare?” Ei bine, când te afli într-un depozit de date sau un design de schemă stelară, tu de obicei, nu aveți tabele pe care ar trebui să le privească o persoană obișnuită și să spună: „Gee, acestea nu sunt foarte bine proiectate”. Dar așa o faceți într-un mediu de depozitare a datelor.

Acum, uită-te ce se va întâmpla pentru că, bine, sunt toate aceste coloane, uită-te la asta, am un index pe fiecare singură coloană. Acum, într-un mediu OLTP care ar fi un nu-nu. Mi-ar încetini toate operațiunile. Într-un mediu de stocare a datelor, le-aș arunca în timpul ciclurilor mele de încărcare. Încărc fără aer sau indexuri și aș recrea indexurile. Și dacă aș despărți tabelul meu, atunci în loc să trebuiască să renunț la indexul pentru fiecare găleată din tabel, aș putea doar să arunc indexul pe găleată sau găleți în care vor fi introduse date în timpul acelui ciclu de încărcare a lotului. Apoi recreați doar porțiunea index pentru acele găleți. Și deci asta îl face foarte ușor de gestionat. Și dacă mă uit - așadar, iată o coloană numită „Steagul sărbătorilor” și practic este un da sau nu. Observați că acesta este un index de hartă de biți, iar pentru majoritatea dintre voi veți spune: „Ei bine, asta are sens.” Da sau nu, Y sau N, există doar două valori care au sens. Și pentru că atunci când citiți documentația pentru indexuri de hartă de bit, ei vă spun întotdeauna să alegeți ceva cu cardinalitate scăzută.

Acum permiteți-mă să intru într-una din tabelele mele, așa că aici avem ordinele mele. Și acestea sunt ordinele mele pe zi. Și veți vedea acum, că din nou am destul de multe coloane și, din nou, voi avea mai mult de câțiva indici. Și chiar aici, avem ceva numit codul prețului universal. Acest lucru a fost pentru un magazin cu amănuntul, așa că știți acele mici coduri de bare atunci când cumpărați ceva din magazin, acesta este codul de preț universal. Acum, există milioane de coduri de preț universal. Acum, pentru această companie specială care vindea lucruri, acestea aveau probabil 1, 7 - 2 milioane de coduri de preț universal, așa că va trebui să vă așteptați că acesta nu va fi un indice bitmap, deoarece 1, 7 milioane de valori distincte sună ca o cardinalitate ridicată. Dar, în realitate, într-un mediu de stocare a datelor, doriți ca acesta să fie un map de biți. Acum, permiteți-mi să explic de ce. Ei bine, pot exista 1, 7 milioane de valori distincte pentru acest cod de preț universal, numărul de rânduri din acest tabel de ordine este în sute de milioane până la miliarde de rânduri. Indicele meu este cardinalitatea scăzută în comparație cu dimensiunea sau cardinalitatea tabelului. Asta face ca cardinalitatea să fie scăzută. Acest lucru face ca indicele de bitmap să fie util, deși este contraintuitiv cu 1, 7 milioane de valori distincte pe care le-ați alege aici. Acum, dacă știam că vreau să folosesc un index de aderare a bitmap-ului, în prezent produsul nu acceptă asta, primesc asta pentru următoarea versiune, dar aici ar fi o altă alternativă. Și într-o schemă de stele, amintiți-vă, indexul de bitmap ar fi pe tabelul de fapt și că un index din arborele B ar arăta către rândul din tabelul de facturi și apoi către fiecare rând care a fost evident în tabelul de dimensiuni pentru acel fapt . Și deci, aveți o altă opțiune acolo. Și așa, hai să vedem, vreau să ies din tabele acum și vreau doar să-ți arăt rapid că am aceleași informații, sub indexuri și că voi face același lucru de bază.

Acum, motivul pentru care am adus asta este acela că poate observați, nu există chei primare aici. Tastele primare sunt realizate cu o restricție de cheie, astfel încât acestea sunt de fapt acoperite de definițiile de constrângere. Aceștia ar fi indexuri care nu fac parte din constrângere. Acum s-ar putea să spuneți: „Ei bine, așteptați un pic, care ar putea părea o cheie străină, iar o cheie străină este o constrângere”, dar cheile străine și majoritatea bazelor de date nu creează automat un index în coloana de cheie străină, chiar dacă este recomandabil, și acolo te duci - am din nou toate aceleași alegeri. Și dacă vreau să mă schimb doar pentru a fi comprimat, pot face asta.

Acum, compresia funcționează numai pe un indice B-tree. Ceea ce permite este, atunci când te uiți la diferitele noduri din arborele B, permite compresia unora dintre valori. Chiar nu este compresie precum compresia tabelelor, este o compresie a ceea ce este stocat în arborele B în nodurile non-frunze. Nu economisește o tonă de spațiu, dar poate face diferența. Și cu asta am observat asta, mă apropii destul de mult de timp, așa că ceea ce vreau să fac este să vreau să mă întorc și să nu mai împărtășesc. Și, avem produsul nostru acolo pentru o încercare de paisprezece zile pe idera.com. Este un produs destul de bun, mai ales dacă lucrați cu mai multe platforme de baze de date. Dacă lucrați cu două sau trei baze de date diferite, acest instrument vă va ușura viața mult mai ușor. Avem instrumente care să vă ajute la designul și selecția indexului, avem un instrument numit DB Optimizer. Nu am putut acoperi asta astăzi, asta ar fi prea mult. Și dacă vrei să mă contactezi, există adresa mea de e-mail, este sau poți să mă prinzi la e-mailul meu privat și am bloguri, am un site web și bloguri și un profil LinkedIn. Așadar, nu ezitați să mă informați cu privire la orice, chiar dacă nu are legătură cu produsul, dacă doriți doar să vorbiți pe baze de date, sunt un geek la inimă și îmi place să mă gândesc la tehnologie.

Eric Kavanagh: Bine, bine, Dez, Robin, sunt sigur că aveți fiecare două întrebări cel puțin, mai avem câteva minute aici. Dez, ce crezi?

Dez Blanchfield: Am o întrebare grozavă pe care trebuie să ți-o pun, aceasta a stat în spatele minții mele. Care este cel mai nebun scenariu pe care l-ai văzut? Ți-am citit blogul, te urmăresc îndeaproape, tu - ești, probabil ești unul dintre puținii oameni care au trăit în aproape toate probabilitățile și cred că dr. Robin Bloor este al doilea pe care l-am întâlnit în viata mea Dar, știți, probabil că ați văzut fiecare scenariu nebun, care sunt unele dintre cele mai nebune scenarii pe care le-ați văzut, pe care le-ați întâlnit și ca niște oameni care pur și simplu nu au putut face față, ați reușit să mergeți și efectuați trucuri de minte Jedi cu acest întreg DBArtisan?

Bert Scalzo: Am avut odată un client care, în proiectarea bazei de date, s-a gândit foarte mult la modul în care ar gândi în proiectarea unui aspect de fișiere, și așa, când - normalizați o bază de date, primul lucru pe care încercați să îl faceți este să scăpați de grupuri repetate. Ei bine, aveau o coloană și o făceau lungă, sau BLOB sau CLOB, iar în ea ar pune valoare, numărul unu, punct și virgulă, valoarea numărul doi, punct și virgulă, numărul valorii, punct și virgulă și vor avea mii de valori. acolo, dar aveau nevoie să caute pe acea coloană și sunt de genul: „De ce se întâmplă acest lucru atât de lent?” Și eu sunt ca: „Ei bine, nu poți crea un index pe ceea ce ai făcut, ci doar nu este permis. ”Așa că le-am arătat, folosind planurile, că ceea ce trebuiau să facă era să normalizeze tabelul. Nu pentru că normalizarea este un exercițiu academic care îmbunătățește lucrurile, ci pentru că doreau o interogare pe acest domeniu, ceea ce însemna că doreau să o poată indexa și nu o puteți indexa pe un grup care se repetă, sau cel puțin nu ușor . Și deci este probabil cel mai rău lucru pe care l-am văzut vreodată.

Dez Blanchfield: Da, este interesant cât de des întâlniți, cred că provocarea cu bazele de date, oamenii uită că este o știință. Și există oameni care fac diplome și doctorate în întregul spațiu, scriu lucrări pe el și ai scris un swag întreg, inclusiv manualele TOAD și alte lucruri din memorie. Tendința către „date mari” de tip „quote-on-quote” acum - văd o mulțime de oameni care uită de fundamentele arhitecturii bazei de date și tehnologiei bazelor de date, știința bazelor de date, dacă doriți. Ce vedeți în domeniu în ceea ce privește îndepărtarea de platformele tradiționale de baze de date și tradiționalul bazelor de date, gândindu-ne că am făcut cuie eficient la sol și a fost doar un caz de ajustare a performanței și de scalare. Vedeți că mulți oameni se raportează și aveți o experiență în care stau doar acolo și au un moment „a-ha”, cum ar fi un moment eureka, unde își dau seama, aceste chestiuni de date mari sunt de fapt doar un fel de baze de date cu adevărat mari? Este un lucru acolo și oamenii vă răspund înapoi și un fel de: „Am uitat, ce știam și ne puteți readuce din partea întunecată?”

Bert Scalzo: Ei bine, nu, iar acest lucru este oribil să trebuiască să recunoască, dar furnizorii de baze de date relaționale au băut și Kool-Aid. Dacă vă amintiți, nu știu, acum un deceniu, am început să introducem date nestructurate în baze de date relaționale, ceea ce era un lucru ciudat de făcut, iar datele, bazele de date relaționale, adaugă acum tipul NoSQL chestie. De fapt, în Oracle 12, CR2 - știu că nu este încă, dar dacă te uiți la versiunea beta, dacă ești în programul beta, acceptă ascuțirea. Și deci, acum ai o bază de date relațională care nu a adăugat conceptul de la ascuțirea NoSQL. Și deci, momentul „a-ha” pare să fie mai mult pentru persoanele relaționale care merg „a-ha”. Nimeni nu o va face din nou, nici măcar managerii bazelor de date, așa că avem trebuie să trec și să mă alătur părții întunecate.

Dez Blanchfield: Așa că spuneți o trecere la o mulțime de date dezordonate, dacă înțeleg corect, fiind introduse în ceea ce numim acum platforme de date mari, ceea ce este cam amuzant, pentru că sunt nu este atât de vechi, dar asta nu înseamnă atunci că se concentrează asupra a ceea ce fac cu baza lor de date relațională pentru a obține mai multă bătaie de cap?

Bert Scalzo: Nu, de obicei, dacă au o nevoie în - asta ar fi citat o „mare nevoie de tip de date”, ei descoperă că în loc să fie nevoiți să mergeți pe cealaltă platformă de baze de date și să facă ceva într-un non -în mod relațional, furnizorii de baze de date le oferă acum aceleași tehnici non-relaționale din baza lor de date relațională, pentru a face aceste lucruri. Adică, un exemplu bun ar fi dacă aveți date nestructurate, cum ar fi un tip de date JSON sau un alt tip de date complex care are semnificație încorporată în datele în sine, furnizorii de baze de date nu numai că acceptă asta, dar vă vor oferi ACID respectarea datelor nestructurate. Bazele de date relaționale au cuprins tehnicile și tehnologiile mai noi și astfel, din nou, „a-ha” pare să nu fie mai mult, „Hei noi, dezvoltatorii de aplicații, am dezvăluit ceva și trebuie să-l învățăm din nou”, este „Hei, o facem acum acum, cum pot să o fac așa în baza de date relațională în mod tradițional și să o fac așa cum fac în această bază de date aici? ”Și asta devine tot mai răspândit, și așa cum am spus, furnizorii de baze de date înșiși permit acea.

Dez Blanchfield: Corect, cine sunt suspecții tradiționali din acest spațiu pentru instrumentul DBArtisan și asta? Am făcut unele teme despre ceea ce ai scris recent și din memorie ai scris ceva, cred că a fost unul dintre blogurile tale, în ceea ce privește performanța extremă a bazelor de date din lumea Oracle. Nu-mi amintesc când a fost, cred că a fost cândva din memorie sau de la sfârșitul anului trecut, ai fi scris acest lucru. Și mi s-a părut că este tradiționalul, obișnuit suspect pentru tipul de subiect despre care vorbim astăzi, unde oamenii vor merge la un mediu de baze de date foarte mare și vor căuta ceea ce numiți câștiguri extreme în aceasta. Cine sunt suspecții obișnuiți că vedeți acolo, care preia DBArtisan și îl utilizează bine?

Bert Scalzo: Ei bine, avem o mulțime de clienți, de fapt, azi am fost cu o agenție guvernamentală foarte mare, care - probabil au aproape aproape 1000 de exemplare ale software-ului nostru, deoarece le permite oamenilor să se concentreze pe ceea ce „ faci, și nu cum să faci. Și este în regulă, vreau să spun, toată lumea ar trebui să știe să facă ceva, dar productivitatea obține „ceea”. Dacă afacerea îmi cere să fac o sarcină, asta este tot ceea ce le interesează. Când am primit o bifă pentru a spune când s-a finalizat sarcina? Nu ce tehnică sau ce tehnologie am folosit pentru a ajunge acolo. Și deci, instrumentul nostru le permite să se concentreze asupra a ceea ce și le permite să fie mult mai productivi, și acesta este într-adevăr avantajul uriaș, iar așa cum am spus, unele baze de date oferă un instrument doar pentru platforma lor de baze de date. O oferim pentru douăsprezece platforme de baze de date. Am același flux de lucru, aceeași interfață grafică de utilizator, aceleași navigații. Dacă știți cum să acordați un privilegiu unui utilizator sau cum să creați un tabel sau să creați un index într-o bază de date, puteți face acest lucru în toate cele douăsprezece, deoarece este același aspect și același flux de lucru. Aceasta are o valoare uriașă pentru clienții noștri.

Dez Blanchfield: Da, cred, oamenii doresc să obțină mult mai mult din cauza resurselor lor umane. Și zilele de a avea un specialist individual în Oracle, Ingres și DB2 au dispărut. Oamenii sunt așteptați să fie Jack-ul tuturor meseriilor, așa că cred că acest lucru le-a salvat absolut viața.

Doar un ultim lucru rapid înainte să-l predau doctorului Robin Bloor. Ați menționat că există o descărcare gratuită timp de paisprezece zile, ce face - dacă o să merg înainte și o să fac asta, apropo, o voi pune în laboratorul tehnologic Bloor și voi face acest lucru Ridică-mă și pune mâna pe el - nu am avut nicio șansă să fac asta până astăzi. Ați menționat un proces de paisprezece zile, ați spus că îl rulați pe un VM pe computer, presupun că este un laptop. Care sunt, care este configurarea la nivel de intrare pentru ca cineva să pună mâna pe cap și să arate procesul de paisprezece zile, chiar înainte de a-i înmâna lui Robin întrebările sale?

Bert Scalzo: Orice mediu Windows, deci Windows 7, mașină virtuală cu un procesor și patru direcții de memorie. Nu suntem un instrument foarte gras sau scump. Dacă doriți să rulați serverul dvs. de bază pe aceeași mașină virtuală sub același Windows, da, va trebui să adăugați mai multe, dar dacă rulați baza de date pe un server de baze de date sau pe o mașină virtuală separată, VM trebuie să se încarce și rulează produsul nostru este foarte ușor: un procesor, patru instrumente de memorie, aproape orice versiune de Windows - și acceptăm atât instalări de treizeci și două și șaizeci și patru de biți. Dar trebuie să instalați clientul furnizorului de baze de date. Așadar, dacă ați dorit să vă conectați la Oracle, trebuie să instalați clientul net SQL, pentru că este ceea ce cere Oracle pentru a putea vorbi cu o bază de date.

Dez Blanchfield: Sună destul de simplu. Cred că un lucru din acest lucru, mai mult decât orice, sper că oamenii vor lua departe, în afară de realizarea faptului că acest instrument își va salva viața, este că ar trebui să-l descarce și să se joace cu el, având în vedere că oferiți o probă gratuită de paisprezece zile. Și poate rula pe laptopul lor actual fără să instaleze nimic în plus, pentru că, dacă fac deja administrarea bazelor de date, lucrează deja cu baze de date, au toate aceste instrumente la locul lor și dacă funcționează pe un VM local sau pe desktop local, se pare că este nedureros să instalați și să vă jucați. Așa că le recomand oamenilor să facă asta.

Robin, sunt sigur că ai întrebări și Eric, probabil că ai câteva din public, deci Robin, ce zici să-ți trec și apoi să mă întorc la Eric?

Robin Bloor: Da, bine, bine, am lucruri de spus, adică am găsit întotdeauna această zonă fascinantă pentru că a fost - mi-am tăiat dinții pe ea. Însă adevărul este că, probabil, din 1998, în jurul anului 1999, am fost la curent cu ceea ce Oracle este capabil de fapt. Și, știam că Sybase și Microsoft SQL Server, ambele sunt destul de simple în comparație cu ceea ce ar putea face Oracle. M-ai făcut să râd când tu - Adică, mi-am acoperit gura, când ai început să vorbesc despre ascuțire. Oracle a făcut asta înainte. Oracle a introdus la un moment dat în timp, s-au enervat de ideea relațională dintre obiecte, așa că au introdus capacitatea de a crea un fel de notare de obiecte și de stocare a obiectelor în Oracle și am vorbit cu unul dintre inginerii lor, ceva de genul la câțiva ani după ce au introdus-o și am întrebat câți oameni au folosit-o, iar el a spus că cred că doi clienți au încercat-o și asta a fost. Și cred că același lucru se va întâmpla dacă încep să încerce și să facă lucruri în trend NoSQL. Știi, cred că este o greșeală, adică sunt interesat de gândurile tale. Cu siguranță, - beau Kool-Aid. Se simt de parcă ar trebui să poată face afirmații similare marilor baze de date NoSQL precum Cassandra, dar știți, are vreun sens pentru dvs.?

Bert Scalzo: Nu, ai lovit unghia chiar pe cap. Pentru mine, aș face, dacă voi face relațional, voi alege un furnizor relațional precum un Oracle sau un SQL Server sau un DB2 sau un Postgres, dar dacă voi face ceva care nu este relațional, în spațiul de date mare sau în spațiul NoSQL, voi alege instrumentul potrivit pentru treaba potrivită. Și nu cred că asta ar fi, în mod firesc, să mergem mai întâi la furnizorul meu de baze de date relaționale. Și apoi, adăugați celălalt rid pe el, adică ce este disponibil în cloud? Atâția oameni care doresc să-și scoată bazele de date de la premisă. Apoi, trebuie să vă uitați la furnizorul dvs. de cloud și să spuneți: „Bine, ce furnizor, ce baze de date aveți disponibile pentru mine care se potrivesc nevoilor mele și cât de vândute sunt, și sincer care este tariful sau taxa pentru utilizarea acestei baze de date în nor pe oră sau pe zi. Și per gigabyte sau terabyte? ”Și ceea ce veți găsi este poate unele dintre bazele de date relativ mai noi precum Mongo sau Cassandra, poate că tarifele lor sunt mai ieftine, deci dacă veți face date mari de tip multi-petabyte, s-ar putea trebuie - doar din punct de vedere al costurilor - trebuie să ia în considerare bazele de date NoSQL din cloud, deoarece acestea pot fi cel mai eficient mod de a face acest lucru.

Robin Bloor: Da, corect. Adică, genul meu - lucrul despre bazele de date relaționale din experiența mea - care este suficient de lung pentru a avea cicatrici, asta este sigur - există foarte mult bun simț că dacă începeți să îl aplicați și - înțelegeți ce este relațional de fapt, Vreau să spun, îmi amintesc că am făcut o consultație cu un client o dată și m-au condus într-o cameră și au făcut un fel de diagramă de entitate și au creat o a treia formă normală, un model cum ar fi sistemele primare ale companiei. Avea două sute patruzeci de mese și au spus: „Ei, ce crezi despre asta? Vom construi o bază de date pentru asta ”și mi-am spus„ Ce crezi despre asta? ”Am spus:„ Nu cred că va merge. ”Și este exact corect, știi, pentru că se terminau în vederea creării unei structuri particulare în cadrul unirilor cu 11 poziții. Și asta este lucrul de înțeles despre relațional. Așa că sunt cam interesat în ceea ce privește cât de mult design rău întâlnești. Adică, nu am nicio problemă cu DBArtisan - face lucruri foarte sensibile și faptul că puteți afișa de fapt pe mai multe platforme, cred, este minunat - dar cât de mult vă întâmpinați acolo unde este problema în cazul în care oamenii ar fi putut rezolva ei înșiși tot felul de dureri de inimă dacă ar ajunge la o schemă de stele, mai degrabă decât să primească fulg de zăpadă despre asta, știi?

Bert Scalzo: Ei bine, nu vreau să par, presumpt sau arogant, dar aș spune mai des decât nu. În mod clar, majoritatea bazelor de date cu care mă implic acolo, au probleme sau probleme. Ceea ce este bun, deoarece instrumentele noastre, precum instrumentul nostru de optimizare a bazelor de date, le pot ajuta să rezolve aceste probleme și, dar ceea ce este cu adevărat amuzant pentru mine, este că multe dintre probleme sunt aceleași probleme simple de mai multe ori. Lucram doar cu un client, a doua zi, care avea o interogare de unsprezece drumuri și sunt ca: „Bine, de ce nu ai folosit o clauză cu?” Și sunt ca: „Ei bine, nu am Nu știu ce este asta. ”Și apoi am spus:„ Și uitați-vă la sub-selecțiile voastre aici pe corelați și necorelați ”, i-am spus, „ În unele cazuri, aveți în cazul dvs. clauza la cel mai profund nivel, Am spus: „Asta, mutați-l la nivelul potrivit, nu-l încorporați mai adânc decât trebuie, veți confunda optimizatorul.” Și cu câteva modificări, a luat ceva care se desfășura aproximativ două ore și l-am redus la zece minute și a fost doar - în acest caz nu am făcut altceva decât să îmbunătățim SQL-ul scris de ei. Cred că problema este că multe universități și o mulțime de oameni care învață programarea într-un mediu non-academic, o învață ca procese înregistrate în timp sau proces orientat pe rând și relațional este un set orientat de natură, și deci tu trebuie să gândească în seturi pentru a scrie un SQL bun.

Robin Bloor: Da, cred că este exact corect. Și trebuie să înțelegeți, sunt lucruri de genul, oamenii ar trebui să știe ABC-uri de astfel de lucruri. Nu contează. Nu veți putea face lucruri raționale dacă nu vă dați seama că, chiar și o bază de date bine proiectată, bine modelată, unirile vor dura timp, felurile vor avea timp. O fac pentru că lumea nu a găsit niciodată o modalitate de a-i face pe cei să meargă repede. Au găsit modalități de organizare a datelor, astfel încât acestea să meargă mai repede decât altfel și o mulțime de entuziasmul pe care trebuie să-l spun pentru bazele de date NoSQL este pur și simplu că evită să facă uniri. Ei încep doar să construiască bazele de date cu aceeași răspândire de date din ele, pentru că dacă vă alăturați oricăreia dintre bazele de date NoSQL, ele suge puternic. Nu crezi?

Bert Scalzo: Oh, absolut. Și trebuie să râd pentru că, am început să mă întorc înainte de bazele de date relaționale și să mă întorc când Ingres era RTI, Relational Technology Institute și nu aveam SQL, aveam limbaje relaționale pre-SQL. Cred că în Ingres, pe atunci, se numea Quel. Așa că ați obținut din aceste vechi paradigme ale bazelor de date, cum ar fi rețeaua și o grafică superioară sau ierarhică, și treceți prin paradigmele relaționale după câteva decenii, iar acum pentru mine se simte că ne vom întoarce la aproape o ierarhie. Este aproape ca am revenit.

Robin Bloor: Da, corect. Mai bine să vă transmiteți lui Eric, consum prea mult timp, dar am primit întrebări din partea publicului, Eric?

Eric Kavanagh: Da, avem câteva. Mergem un pic aici, dar o să vă arunc câteva. Am avut câteva întrebări în jurul indexurilor invizibile. O întrebare a fost: „Cineva trebuie să folosească instrumentul dvs. pentru a le vedea?” O altă întrebare a fost: „Ei bine, și dacă ești orb?”

Bert Scalzo: Este unul bun.

Eric Kavanagh: Întrebare curioasă, de asemenea, doar FYI.

Bert Scalzo: Nu, nu trebuie să aveți instrumentele noastre. Aceasta este o caracteristică Oracle, indexul invizibililor. Practic, în dicționarul de date, Oracle păstrează doar o bucată de metadate care spune: „Optimizatorul, ignoră acest index. Este aici, dar dacă nu sunteți instruiți fizic printr-un indiciu în, un indiciu de optimizare din comanda SQL, nu folosiți acest lucru. ”Și, nu, nu trebuie să aveți instrumentele noastre și, în orice privință, este un index simplu, îl puteți vedea în orice instrument, doar optimizatorul va spune: „O vom ignora în procesarea normală a interogărilor”. Trebuie să îl direcționați dacă doriți să se obișnuiască. Este foarte util pentru scenariul pe care l-am descris care este, dacă doriți să construiți un indice în producție, dar să nu riscați să spargeți rapoartele sau lucrurile care sunt deja în curs, dar ați dorit să le testați, puteți face acest lucru. Pentru asta este cel mai util.

Eric Kavanagh: Asta-i lucruri bune, apoi a fost o altă întrebare bună aici. Ce zici de unele dintre aceste noi baze de date in memorie? Cum schimbă tehnologia bazei de date în memorie în ceea ce privește indexarea? "

Bert Scalzo: Băiete, ei bine, acum este bine, mă bucur că cineva a pus această întrebare, va trebui să mergem încă o jumătate de oră. Nu, memoria, depinde de furnizorul bazei de date. Acum, în mod normal, eu nu vorbesc decât laudele a ceea ce face Oracle pentru că este uimitoare tehnologia pe care au construit-o, dar când te sfâșiești pe sub copertine și te uiți la ce se află în memorie în Oracle, în Oracle baza de date, ceea ce este în realitate, este încă păstrat rând store store pe disc, și va primi încărcarea în memorie a coloanelor încărcate, iar dacă nu există o memorie suficientă pentru a ține întreaga tabelă, aceasta va reveni la porțiuni; nu se va potrivi în memorie, pentru a-l face în magazinul de rânduri și, astfel, puteți efectua o selecție împotriva tabelului și pentru jumătate din tabel, utilizați o indexare care lovește rândurile tradiționale la masă, iar pentru cealaltă jumătate din selectează că se va derula și pur și simplu preia totul dintr-o căutare în memorie și, deci, este diferit modul în care SQL Server, de exemplu, l-a implementat cu tehnologia lor Hekaton, știi și SQL 2014, și a fost îmbunătățit în SQL 2016, dar, în anumite privințe, a lor este o versiune mai adevărată a memoriei în memorie și, însă, fiecare implementare are pro și contra, dar trebuie să te uiți sub copertă și să realizezi. Pentru că, am avut un client care mi-a spus: „Oh, acest tabel este în memorie - o să întocmesc doar indexurile” și sunt ca: „Masa este mai mare decât memoria pe care o aveți pe server, deci la un moment dat o parte din interogare a ajuns să apară pe disc. "

Eric Kavanagh: Aceasta este o descriere bună; asta e chestii bune. Păi, oameni buni, vom mai avea câteva transmisiuni web cu acești tipi în restul acestui an, reveniți oricând auziți despre Bert că este prezentat pentru că știm că știe lucrurile lui. Este întotdeauna distractiv să vorbești cu experții. Arhivăm toate aceste transmisii web pentru vizualizare ulterioară. Iată din nou informațiile de contact ale lui Bert și vom încerca să săpăm linkul respectiv pentru descărcare și să îl trimitem și prin e-mail, dar puteți oricând să vă trimiteți un e-mail cu adevărat: avem mai multe transmisiuni web aliniate pentru asta an și noi facem ed ed-ul chiar acum, așa că, oameni buni, dacă există vreun subiect despre care doriți cu adevărat să auziți despre anul viitor, nu fiți timizi: Aveți grijă, oameni buni, vă vom vorbi data viitoare. Pa! Pa.