Indeks sindssyge: hvordan man undgår databaser kaos

Af Techopedia Staff, 5. oktober 2016

Takeaway: Værten Eric Kavanagh diskuterer databaseindeksering med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bert Scalzo.

Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved hjælp af indstillingerne til højre. For info om, hvordan vi samarbejder med branchepartnere, klik her.

• Profil
• Internet side

Eric Kavanagh: Mine damer og herrer, hej, og velkommen igen. Det er en onsdag klokken fire østlige, og de af jer, der kender programmet, ved hvad det betyder, det er tid til en anden episode af Hot Technologies. Ja bestemt. Mit navn er Eric Kavanagh, jeg vil være din moderator til dagens session: "Indeks Sindssyge: Hvordan undgår man kaos i databaser." Eller som jeg henviste til det i den sidste e-mail-eksplosion for at gå ud, "databasevirring." Hot term i disse dage, "wrangling." Alle gør det. Der er en dias om din virkelig. Og nok om mig.

Så Hot Technology-serien var virkelig designet til at definere et bestemt rum, i modsætning til Briefing Room, som kun er en-til-en live analytiker briefing, for Hot Tech får vi to analytikere. I dag bliver det vores helt egen doktor Robin Bloor og vores dataforsker Dez Blanchfield. Og vi taler om et emne, som jeg synes er virkelig ret emblematisk for hvad der sker på markedet i dag.

Hovedpunkterne er, at vi er i en verden med kompleksitet i disse dage. Virkelig, hvis du tænker tilbage femten år, eller tyve år, var det en meget anden verden dengang, især med hensyn til databaseteknologi. Tidligere var databaser relativt enkle. Der var kun en håndfuld af dem; de fleste af dem var relationelle. Nu har vi hele denne vifte af databaseteknologier. Bogstaveligt talt mange muligheder på bordet for alle, der ønsker at oprette en applikation eller gøre noget med data. Alt ændrer sig, og det påvirker de mennesker, der prøver at administrere disse systemer. Vi taler i dag med Bert Scalzo, som er en rigtig ekspert på området; han er seniorproduktionsledelse for IDERA, om hvad du kan gøre for at få et greb om alle disse data. Med det vil jeg overlevere det til doktor Robin Bloor for at tage det væk. Robin, ordet er dit.

Robin Bloor: Okay, tak for den introduktion. Jeg tror det - fordi det er en tohånds ting, tror jeg, at jeg bare ville tale om databaseoptimering generelt som en introduktion til dette Hot Tech-show. Jeg begyndte livet - inden for teknologi og analyse - jeg begyndte livet med at gøre dette, fordi jeg plejede at skrive artikler om databasefunktioner på DEC VAX-platformen. Og af den grund brugte databasebrugere mig. Og den slags, der opstår for mig, er, at hvorfor skulle du have en database? Jeg mener, i disse dage plejede en frygtelig masse mennesker at oprette filer med nøgleværdier og bruge dem til at have en slags indeks-sekventiel fejl, som vi kalder dem, men til at oprette en slags databasefunktion, og du ved, hvorfor ville du have Ellers andet?

Og svaret på det, jeg tror, ​​Michael Stonebraker gav det bedste svar på det, og han sagde, "En database kan vide mere om, hvor dataene er, og hvor hurtig man kan få dem, end noget program nogensinde kan vide." Og det synes jeg er interessant; det er spillet. Men i 19 - godt omkring 1989, som jeg begyndte i teknologianalyse, og du ved, på det tidspunkt var databaser meget enkle og relationelle databaser var superenkle. De havde så lille kapacitet, jeg mener, de kunne naturligvis gemme data, og du kunne sikkerhedskopiere, og de havde, de var ACID-kompatible, men de havde virkelig meget svage optimizers. Faktisk ville det være svært at argumentere for, at de overhovedet havde optimeringsfunktionen.

Og senere blev de bare bedre og bedre, men, du ved, når en database ikke fungerer - da disse kenguruer ser ud til at være på en eller anden måde indikerer - der kan være en hel del grunde til, at det går langsomt. Og det bringer mig til det punkt: Databaser har mange funktioner, men den vigtigste er forespørgseloptimering. Hvis de ikke gjorde det, ville du ikke bruge dem. Det handler om at få information hurtigt, det handler om at være i stand til at gøre det, når der er en masse samtidige brugere, og det er et hårdt problem. Og når du faktisk ser på, så lad os kalde dem modne databaser, hvis du vil - men bestemt Oracle, i lidt mindre grad, Microsoft SQL Server, bestemt Teradata og DB2 - optimeringsprogrammerne af disse databaser har fået, har været årtier i bygning. Du ved, de gjorde ikke - nogen sad ikke på - seks fyre på en to-mand, år, projekt og bare banke en sammen. Det fungerer ikke sådan. Optimeringsevnen er gradvist vokset, og det kræver meget at vokse. Lad os alligevel tale om baggrunden til databasen. Der er godt noget der siges om NoSQL-databasen nu, og der er endda en masse entusiasme for grafdatabase. Og brugen af ​​SQL over Hadoop og lignende ting. Men sandheden er, at hvis du vil have en database lige nu, hvis du vil have en fuldt funktionsdygtig, i stand til OLTP og stor forespørgselstrafik, er det en relationel database, eller det er intet.

Blandt relationelle databaser er Oracle dominerende i popularitet. Microsoft SQL Server, tror jeg, er nummer to. De er begge i stand til at blive brugt til OLTP og forespørgsel om arbejdsbyrde, men faktisk kan du virkelig ikke slippe af med at blande disse arbejdsmængder. Du har brug for forskellige hændelser til OLTP-arbejdsbelastning og forespørgsel-belastning. Der er alternativer til SQL og graf. De fleste virksomheder standardiserer en specifik database, og det er grunden til. Jeg mener, at efter flere årtier har kæmpet den ud med alle de andre spillere, blev Oracle den mest dominerende. Simpelthen fordi de endte med at kunne sælge firmalicenser, og derfor vil virksomheder kun bruge alternative produkter i ekstraordinære produkter, Oracle ville simpelthen ikke gøre dem. Og databaser er strategiske, idet de også udvikler sig. Og du ved, at jeg gjorde en smule research til denne præsentation, og det er slags - jeg kommer til det i et stykke tid, men det er lidt interessant, hvordan de udvikler sig, med hensyn til at se på det fra en DBA's holdning. Dette er, hvad jeg kalder den usynlige tendens. Det er Moore's lov i kub. Det er nogenlunde sådan: Den største database er, og nye databaser, der er ikke en gammel database, der har meget mere data at indtage. Det er normalt en database, der anvendes til et nyt problem. Og de vokser faktisk med hensyn til datamængder. Groft ved terningen af ​​Moore's lov. Så Moore's lov er en faktor ti gange hvert sjette år. VLDB'er har en tendens til at vokse en faktor på tusind hvert sjette år. I 1991, 1992, måles de store databaser i form af megabyte. I '97 og '98, gigabyte. 2003, '4, terabyte. 2009, '10, du begyndte at se petabyte databaser. Jeg tror, ​​der var muligvis en eller to exabyte databaser derude lige nu, men den største, jeg har hørt om, er de 200 petabyte til tiden, og du ved, ikke at få data til en petabyte databaser. Men det er mest af det naturligvis de nye store web 2.0-virksomheder, muligvis har du Facebook på vej i den retning.

Men alligevel, hvis du faktisk ser på det og forventer, at en database skal gennemgå den slags eskalering i volumen, spørger det meget. Og bemærkelsesværdigt, bestemt op til petabyte-niveauet, ser det ud til, at de har gjort det rimeligt godt. Jeg mener, jeg taler om de ældre produkter snarere end noget nyt. De ser ud til at have fungeret ekstraordinært godt. Hvis vi ser på databasepræstation, flaskehalser, tager dette mig tilbage til den tid, jeg faktisk plejede at pleje dem, og var nødt til at bekymre sig om dem. Du ved, at dette grundlæggende er nedbrydningen af ​​hardware. Der er CPU-flaskehalser, muligvis er der hukommelsesflaskehalse, muligvis er der diskflaskehalser, muligvis. Det kan være netværket, der får dig til sorg, og du kan også få problemer med at låse, afhængigt af hvad du laver, men normalt skyldes det, at programmet ikke ved, hvem der skal ringes. Så hvis du vil indstille en database, prøver du faktisk at indstille den, så den danser mellem disse fem mulige flaskehalse så godt som den kan gøre. Og det er ikke let, for den mængde hukommelse, du kan konfigurere på en given server, øges dramatisk. Derefter er CPU'er blevet multicore, disk, og vi kan nu også gøre det, selv på råvareserver, tror jeg, du kan gøre hundreder og hundreder af terabyte, fjerdedel petabyte, måske endda på en råvareserver. Så af alle disse ting kan du lege med, netværk kan selvfølgelig gå i forskellige hastigheder, men mest når du har med databaser at gøre, vil du virkelig have fiberkabler mellem serverne og intet andet kører på det, specielt Den vej.

Databaseprioritetsfaktorer. Jeg mener, jeg forlader, hvad det hele kommer til at handle om, fordi jeg ved, at Dez vil tale om det, men dårlig databasedesign betyder en database, der fungerer dårligt. Dårligt programmeringsdesign kan muligvis betyde at kaste meget dum SQL på en database, hvilket bare vil tage meget frygteligt længere tid. Samtidig og blandet arbejdsbyrde, for meget samtid vil medføre flaskehalsproblemer. Arbejdsbyrden blanding, når du har store forespørgsler med meget små, korte, skarpe forespørgsler, der forårsager problemer. Der er et belastningsbalanceringsproblem. De fleste databaser tager sig af det, men hvis du ikke har et sofistikeret produkt, ved du det, bare at tilføje et par servere, er ikke alt hvad du gør, hvis du rent faktisk vil øge størrelsen på en klynge. Du er faktisk nødt til at afbalancere belastning, før du får den optimale ydelse. Du skal lave kapacitetsplanlægning. Absolut. Især nu i disse dage, som når datamængderne stiger mere dramatisk, end de plejede for databaser. Og der er problemer med hele datalag, hvordan du indtager dataene, hvordan du flytter data om. At ikke hente data til en database til tiden kan være et præstationsproblem senere, fordi vi er gået fra databaser, der arbejder i Windows, til 24 timer ved syv af tre hundrede og femoghalvtreds drift, og der er ingen windows, hvor du kan bremse databasen nede, eller det er usandsynligt, at der vil være i dag.

Oracle DBA-problemet. Dette var hvad jeg tænkte på. Jeg har været i Oracle's DBA med Oracle 7, og jeg kan huske, hvordan jeg skulle indstille det. Og hvis du faktisk ser på Oracle nu, er det måde, måde - det har måde, måde mere kapacitet. Det har bitmap-indeksering og lignende ting, men jeg tog mig faktisk tid til at se og se, hvor mange indstillingsparametre der faktisk er i en Oracle-database i øjeblikket. Og der er over tre hundrede og halvtreds indstillingsparametre, og der er yderligere et hundrede skjulte parametre, som specialiserede DBA'er måske ved om, men normale Oracle DBA'er ved ikke om. Og det betyder, at det er en hård ting at indstille denne type database. Det er overhovedet ikke en enkel ting. Du skal have en fornemmelse af det, du skal have gjort det i lang, lang tid, og du er nødt til at vide nøjagtigt, hvilket problem du synes, du løser, fordi indstillingen starter, når ydeevne bliver dårlig, men det er måske ikke ydeevnen for alt. Det kan være udførelsen af ​​specifikke forespørgsler, der betyder noget, og du kan muligvis løse det ved at fastgøre bestemte data og hukommelse, eller du skal muligvis løse dem ved at indeksere, eller du kan muligvis begynde at udføre partitionering på en anden måde. Der er en masse ting, du kan gøre, er poenget. Så derfor vil de ikke gøre det i deres hoveder - DBA'er har brug for værktøjer. Jeg vil nu videregive til Dez, der vil fortælle dig om indeksering, tror jeg.

Eric Kavanagh: Okay, tag den væk.

Dez Blanchfield: Tak, Robin, og jeg elsker forsiden. Jeg tror, ​​du har kastet bøjlen dernede for at jeg endda kommer fjernt tæt på noget spændende. Men jeg har brugt et billede af vores lille galakse, som min opfattelse af, hvad nutidens udfordring for databaseadministratorer er blevet til, fordi dette er det mentale image, som jeg har tendens til at trylle frem, når jeg kommer ind i et miljø, og jeg er ikke længere i en verden af ​​administration af databaser eller designe databaser på dette niveau længere. Men som dig selv har Robin og jeg haft mange år med at være involveret i en verden af ​​databaser, enten som administrator eller udvikler, eller til sidst arkitekt, og så indså vi, at jeg kunne gøre bedre ting for at tjene en skorpe. Men det har en tendens til at føles som om du stirrer på denne galakse af data, og mere i dag, når vi går fra, som du skitserede, er vi gået fra megabyte til petabytes og exo-skala i en meget kort periode, i det store plan af ting. Men den sætning, som jeg har i mine sind, er, at databaseindekser nu er en sort kunst, og de er ikke rigtig den slags ting, som bare dødelige skal sortere sig til, til forretningsapplikationer i virksomheden og typen af ​​formulering af dig talte bare om. Men jeg ønskede at gennemgå en hurtig gennemgang af den type historie, som jeg har haft med databasesverdener, og bringe til kontekst, hvor vi vil drage en konklusion til, og derefter løbe gennem noget materiale i dag med vores venner på IDERA, fordi jeg tror, ​​der er en masse forskellige tanker om, hvordan man får tuning af databasepræstation, og en af ​​dem kaster tin på tinget. For mange butikker, som jeg støder på, kommer de altid ikke til at udføre performance-tuning på databaselaget og især indekslaget, før de har gennemgået den hårde rute at tænke på, at de kan smide en tuner på det .

Mange mennesker tager bare en stor jerntilnærmelse til det, og jeg har et billede af Flash her, hvis du nogensinde har set nogen gamle film eller helt sikkert det seneste tv-show med The Flash, som i Flash Gordon, den gamle karakter, og nu hvor han kaldes “Blitz”, har han en tendens til at gå meget, meget hurtigt og altid går hans energi ud. Og det er, hvad der sker, når du kaster stort jern på databasepræstation. Under min mening kan du efter min erfaring lægge høj ydelse, hårdt arbejde i spillet, du kan optimere dine operativsystemer og indstille dem til et bestemt punkt. Du kan sikre dig, at du har hurtige multicore-processorer med flere tråde for at få applikationen til at køre hurtigere, du kan smide masser af RAM på det, du kan have high-output-backplanes, du kan gå fra harddiske til cache-harddiske til solid state, og højtydende lagringsarray. Og selv nu kaster folk ting som flash og NVMe i deres databasemotorer og tænker, at de får dette login gange to ydelsesgevinster. Og altid får de nogle gevinster. Men det hele kommer tilbage til de samme grundlæggende problemer med tuning af ydeevne. Masser af netværksforbindelser med lav latens, så klyngerne fungerer hurtigt. Og med gruppering af databaseinfrastruktur, så du har mere end blot en maskine, der udfører alt arbejde. Men du har en tendens til at vende tilbage til det samme grundlæggende ydelsesproblem, og det er læsning af data. Skrivning af data er for det meste en temmelig lineær udfordring, og medmindre det gøres korrekt.

Og så har vi udfordringen i dagens verden: Ikke alle databaser er oprettet lige. Der er databaser og citat-på-pris "database." Og når vi tænker på databasemotorer, tænker folk ofte på de traditionelle, sædvanlige mistænkte, som de var i SQL-verdenen. Du ved, vi har Oracle og Microsoft SQL Server, og der er et par omkring det i open source-verdenen med MySQL, som nu ejes af Oracle, men det er stadig open source. Og så har vi de ikke-så-sædvanlige mistænkte, NoSQL-motorerne, som stadig har et problem omkring indeksering og ydelsesstyring, og jeg vil ikke gå nærmere ind på dem, men der er et stigende antal af disse ting dukker op hver dag, og de ser ud og føles som databasemotorer fra udviklernes synspunkt og ud fra et performance-synspunkt, men de er meget, meget forskellige dyr, og de har deres egen lille niche i verden til at skære ud enten ydelse i hukommelsen eller lineær skala på disken. Men sådan ser verden ud i databaseverdenen. Dette er 2016, dette er version tre af kortet af en række mennesker, der fremstiller dette igangværende landskabskort over, hvordan databaser ser ud, og det er her det er - ikke engang en overmenneskelig databasearkitekt eller databaseadministrator kunne give mening af det. Bogstaveligt talt hundreder og hundreder og hundreder af forskellige mærker, modeller, fabrikanter af databaser, altid SQL-kompatible. Og det interessante er, at de alle vender tilbage til den samme udfordring. Ydeevne og præstationsindstilling omkring databasemotoren, og især efter, hvordan data indekseres.

Så lad os bare hurtigt dække databaseindeksering, fordi det er et interessant emne, og du er nødt til at gå nærmere ind på det med demoen, tror jeg. Men jeg synes, det er temmelig godt accepteret og standard branchepraksis, at indstilling af databaseindeksets ydeevne er, hvor verden starter og slutter så langt som at sikre, at dine data er tilgængelige i et hurtigt og hurtigt format. Men hvad er databaseindeksering? Hvis vi tænker på indeksering i den form, som vi er vant til som hverdagsmennesker, skal du tænke på en indeksside i en bog. Hvis du vil finde noget i en bog - især som et leksikon, eller noget som et referencemateriale af en eller anden form - hvis du leder efter noget som denne side, hvor jeg leder efter ting som emnet dæmninger i et leksikon. Jeg vil gerne finde enhver henvisning til dæmninger, afvanding af vand og et stort opbygningsområde, generelt menneskeskabt. Jeg går tilbage, jeg finder det i en alfabetiseret, sorteret liste, A til Z, fra venstre til højre, og jeg finder D. Jeg finder ordet "dæmninger", og det kan jeg se på side 16, 38, 41 der er en henvisning til dem, og så kan jeg gå til disse sider, jeg kan scanne mine øjne ned, og jeg finder henvisningen til ordet "dæmning." Det er i det væsentlige det samme koncept i en database, men det er nu en raketvidenskab på mange måder. Så meget, at effektivt hver databaseadministrator, jeg nogensinde har lært godt at kende, betragter indekser som det mest kritiske værktøj til ydeevneindstilling i enhver databaseverden, uanset hvad deres erfaring kan være, når det gælder at kaste tin på det, eller uanset hvad der måtte være.

Generelt, når vi taler om databaseindeksering, er der en række fælles tilgange. Og jo mere komplekse databaseindeks der er, jo mere kompleks er fremgangsmåden til indekseringsdata. Men i det væsentlige, når du overvejer at indeksere data - forestil dig, at vi har en fil, der har en liste med navne; de kan ikke sorteres i alfabetisk rækkefølge. Lad os forestille os, at der er tyve af dem. Hvis vi skal sortere - hvis vi vil søge efter data på listen, fra top til bund, og lad os sige, at det er en liste med navne. Hvis jeg vælger et tilfældigt navn, og jeg begynder at rulle nedad på listen, fra top til bund, i et lineært format, og det er en uordnet liste, er der to kriterier, som jeg tænker på som min gennemsnitlige søgetid og min maksimale søgetid - og Jeg har en skrivefejl i den anden linje, skal være "maksimal søgningstid", undskyld - men min gennemsnitlige søgetid er hovedsageligt N plus en, divideret med to, og det er i gennemsnit, det tager mig halvtreds procent af tiden at scanne fra toppen af ​​listen til bunden af ​​listen for at finde en tilfældig ting på listen. Og den anden linje der, under lineær, skal være "maksimal søgetid." Men den maksimale søgetid er i det væsentlige antallet af genstande, og det er, at hvis jeg har en liste med tyve ting, at det mest tid kan tage mig at søge efter noget i den database er at gå fra toppen til bunden, hvilket er lad os sige 20 elementer i dette forenklede eksempel. Og det er en meget langsom proces, og der er virkelig ingen måde at yde den på. Og så er der andre typer måder at tage disse data på og oprette et indeks, som faktisk er en kort liste med pegepunkter til, hvor de faktiske data er, såsom binært, B-træ, bitmap, hashing, klynget og ikke-klynget, og så er der forskellige typer data, såsom rumlig, filtreret, XML og fuldtekst.

Binær er en meget almindeligt anvendt en til ting, hvor dataene egner sig til det. B-træ er sandsynligvis den mest almindelige i generel forstand, historisk set, idet det er en almindelig måde at strukturere et indeks til enhver form for data og tillader, at loggere, markeringer og indsættelser og sletninger er relativt lette, når du flytter pegepunkter rundt om henvisning til pointerne, punkterne. Der er andre typer, som bitmap, hvor datatyper vedrører, hvis vi har et tilknyttet interval af en eller anden form. Hashing fungerer meget godt til store objekter, især blogs og billeder. Og du kan se, at der er en række forskellige typer videnskabelige tilgange, matematiske tilgange, til indeksering af data. For den dødelige er de en interessant udfordring at tale om på dette niveau. Når du taler om det på ydelsesniveau for en databaseadministrator, bliver de virkelig en raketforsker, og folk gør grader i dem, og jeg ved, at doktor Robin Bloor helt sikkert har gjort det, og skrevet bøger om det som IBM og andre store mærker i de sidste par årtier. Og så, - min opfattelse, er, at vi faktisk har passeret et tidspunkt, hvor du ved engang en gang jeg personligt ville være i stand til at sidde foran et system, og jeg ville være i stand til at trække det fra hinanden og vise dig nøjagtigt hvor præstationsproblemerne befandt sig på en kommandolinje eller ved et grafisk brugergrænseflade startværktøj, og begynde at kaste dig ind i dataene og fortælle dig, hvor problemerne var, og opbygge indekser eller underindekser eller primære og sekundære indekser data og begynde at bruge dem til at finde ting. Men når du tænker på det landskab, jeg viste dig, hvor vi har hundreder og hundreder af mærker, mærker og modeller, og producenter og typer databaser, er vi godt og virkelig forbi den tid nu, hvor et menneske kan fremstille fornemmelse af de typer databasemotorer, vi har. Især hvis vi netop vender tilbage til dem som Oracle, er dominerende mærker i disse dage i relationelle databaseplattformer.

Antallet af databaser, de skal beskæftige sig med, enten fra en proprietær platform som et ERP- eller HR- eller finansieringssystem, eller om de er en hjemmebagt platform af forskellige grunde, antallet af databaser og databasetabeller og poster, som vi ender at håndtere er bare astronomiske, og du kan fysisk ikke gøre det i hånden. Og vi har haft en yderligere komplikation nu, hvor en databaseserver en gang måske bare sidder under dit skrivebord. Du ved, som et barn efter skoletid plejede jeg at arbejde med databasesoftware på, oprindeligt Apple IIes og derefter DOS PC-baserede systemer, ligesom dBase II, dBase III, gennemgik en æra med mainframes og mid- rækkevidde og endda VAX'er og PDP'er og logfil på den. Og lignende af Sabre, og så til sidst når nogle af SQL-databaserne fulgte med. Men i disse dage, når vi tænker på databasemotorer, ser de ud som i nederste venstre hjørne. En databaseserver er ikke kun en maskine, der sidder på gulvet under et skrivebord; det er hundredevis af maskiner, der kører kopier af databasemotorer og klynger, og de skalerer op til hundreder og hundreder af terabyte data, hvis ikke petabytes af data, hvilket er tusinder af terabyte. Og endda til det ekstreme, som doktor Robin Bloor nævnte, at nogle specifikke brugssager - luftfartsselskaber, især myndigheder - kan komme til eksabyte. De er stadig temmelig niche-y, men hundreder af terabyte og endda snesevis af petabytes er ikke mere usædvanlige, især fra dotcom-boom til nu, slags hvad vi kalder web 2.0-virksomheder, som Facebook, Google, Yahoo og så videre.

Vi har også komplikationen nu, når tingene flytter til ekstern service. Vi har infrastrukturplatform og -software som en service-tilgang, der leverer infrastruktur. Og især platformstjeneste, hvor vi ikke bare kan købe til dem som Oracle og deres skyplatform, databaser og servere. Og dette gør det muligt for os at gøre meget hurtig udvikling af applikationen og bare tilslutte en database tilbage til serverne. Vi behøver ikke at tænke over, hvad der er under hætten. Ulempen er, at vi ofte ikke tænker over, hvordan vi designer og implementerer databasen igen, indtil den begynder at skade, og ydeevne bliver et problem, og så ender vi med at lede efter det rigtige værktøj til at diagnosticere, hvorfor vores database gør ondt og hvor præstationsspørgsmålene er. Og altid bringer det det tilbage til det fælles problem med, hvordan vi har indekseret disse data og de typer indekser, vi har brugt til disse data, og som derefter bringer os tilbage til overmenneskeligt ydelseskrav. Og nogen, der har adgang til de rigtige systemer og de rigtige værktøjer til at ydeevne indstille disse motorer, og begynde at finde et hot spot og se på, hvor forespørgslerne er, hvor dataene bevæger sig, hvilke typer forespørgsler, hvordan forespørgslerne er struktureret, hvem der laver forespørgsler, og om forespørgslerne står i kø, og skal caches. Hvilken replikation ser du efter?

Og så er vi godt og virkelig - efter min mening - på et tidspunkt nu, hvor endda verdens bedste databaseguruer, i det væsentlige vores databasearkitekter og vores databaseadministrator og performancebaser, efter min mening har de meget brug for at bruge de rigtige værktøjer at levere optimal ydeevne indeksindstilling til enhver databasemotor. Fordi den skala, vi har at gøre med, og den hastighed, som tingene bevæger sig i, kan vi simpelthen ikke gøre det med hånden, og at forsøge at gøre det altid kan introducere andre performance-problemer, fordi vi muligvis ikke har erfaring i det rum, vi forsøger at løse et problem i. Og jeg tror, ​​at det er her, vi skal til at give Bert, og vi skal til at tale om, hvordan de har løst dette varierede problem og den type ting, som deres værktøj kan gør, især for Oracle-verdenen. Og med det der, Bert, overgår jeg til dig.

Bert Scalzo: Tak. Velkommen alle sammen, jeg hedder Bert Scalzo, jeg arbejder for IDERA. Jeg er seniorproduktchef for nogle af vores databaseprodukter. Jeg vil demonstrere nogle af dem i dag. Men jeg vil tale om indekser, fordi jeg er enig i alt det, alle har sagt her, især det sidste lysbillede, at indekser er så komplekse nu, at du har brug for et værktøj, og jeg håber at overbevise dig. Så Oracle-indeksdesign, det er ikke så let, som det var i gamle dage. Mange mennesker vil være usikre på sig selv, når de ser på mulighederne, og jeg kan godt lide dette siger, at jeg trak ud af historien, "i disse spørgsmål, den eneste sikkerhed, er, at intet er sikkert." Og det er sådan jeg slags føler om indeks i disse dage, for selv hvis du synes, du ved, at svaret fra dig skulle indeksere X, Y eller Z, kan du virkelig ikke være sikker, før du prøver det, fordi disse optimeringsprogrammer undertiden opfører sig anderledes, som du forventer. Og så er der en masse prøve og fejl med indeksdesign. I de gode gamle dage var der generelt kun to spørgsmål eller et spørgsmål, hvis du havde brug for et indeks. Var det unikt, eller var det ikke unikt? Og du har måske tænkt på andre ting som "Hvor mange indekser kan jeg have maksimalt på et enkelt bord?", Fordi for mange indekser bremser dine indsatser, opdateringer og sletninger. Du har måske også været i dit databasesystem, havde begrænsninger for, hvor mange kolonner der kunne være i et flersøjles indeks, fordi der undertiden var grænser baseret på siden eller blokstørrelsen på din databasemotor, men i virkeligheden var det ret simpelt tilbage i de gode gamle dage. Du indekserede det enten, eller du gjorde det ikke. Og virkelig, alt var i et B-træ. Vi kunne tillade duplikater eller ej, og det handlede om det. Livet var godt, livet var enkelt.

Nå i dag er livet ikke så godt eller så enkelt. Jeg har lagt det røde Ghostbuster-skilt gennem den måde, vi plejede at gøre det på, for nu har vi B-træ versus bitmap versus bitmap join. Og jeg vil forklare, hvad nogle af disse er i et øjeblik. Clustered og ikke-clustered, unik eller duplikater, fremad eller omvendt rækkefølge, funktionsbaseret, partitioneret eller ikke partitioneret. Hvis der er partitionering involveret, er det global eller lokal partitionering? Det forklarer jeg også. Og så er der også noget, der kaldes en indekseret organiseret tabel. Og der er faktisk et halvt dusin andre, som jeg har holdt væk herfra, fordi jeg synes, jeg har fået her her nu, som skulle overbevise dig om, at indekser er meget hårdere end du måske troede. I dette særlige dias skal jeg starte i den øverste venstre del af diagrammet, og jeg har et bord. Og den første ting, jeg er nødt til at beslutte, er, afhængigt af din databaseversion og din databaseleverandør, tillader de objekttabeller, eller er de kun relationelle? Jeg går ned til højre side og siger, at vi bygger en relationstabel. Det næste spørgsmål, jeg må stille mig selv, er, er det i en klynge? Og mange af jer, der har gjort Oracle i nogen tid, vil huske, at klynger var tilbage i Oracle 6 dage. De er sandsynligvis ikke særlig stærkt brugt mere i dag, men lad mig gå ned af grenen først.

Hvis jeg skulle lægge mit bord i en klynge, ville jeg have et klyngeindeks på det bord. Nu i Oracle, da du samlet et bord, lagrede du dybest set rækkerne, eller rækkerne var tæt på hinanden, hvor værdierne var ens. Og så skal du have et klynget indeks, og det klyngeindeks kan være ikke-opdelt. Med andre ord var der ikke rigtig nogen opdelingsmetoder til, hvordan du ville lave en klyngetabel. Det var strengt ikke delt. Og fordi den ikke var opdelt, var den global. Jeg vil forklare, hvad det globale er om et øjeblik. Og det var altid B-træ. Med andre ord, da jeg gik ned i denne gren, var det temmelig enkelt, jeg havde ikke mange valg. Hvis jeg nu gjorde et ikke-klynget indeks på et klyngetabell, som var tilladt i nogle versioner, var det igen ikke-partitioneret; når det ikke er partitioneret, er dit eneste valg globalt. Og så, der har du valget mellem B-træ eller bitmap. Igen afhang det af din version af databasen. Men nu, lad os gå tilbage til det relationelle bord og begynde at gå ned til højre side igen, og nu skal vi bare have et almindeligt, gammelt, regelmæssigt, heapet bord: relationelt. Det vil være i et bordplads. Jeg går lige ned i højre side her først. Så det er organisation, heap. Det næste spørgsmål, jeg er nødt til at stille mig selv, er: "Vil jeg opdele denne tabel, eller gør jeg det ikke?" Nu vil du sommetider partitionere, fordi du tænkte, "Hej, optimisatoren vil være smartere, hvordan den kan optimere forespørgsler. ”Men mange DBA'er vil fortælle dig, at grunden til, at du gør det, er til administrative formål. Hvis du har en tabel på hundrede milliarder rækker, hvis du opdeler den i partitioner eller spande, når du vil tilføje data til den sidste spand, kan du slippe og indeksere, der kun er et par millioner rækker. Du kan indsætte disse data, og så kan du genopbygge dette indeks på netop den spand.

Mens det var en god teknik for nogle, optimeringsteknikker som eliminering af partitioner, var dens reelle værdi i stand til at administrere eller udføre administrative opgaver på mindre stykker. Når jeg går til den organisatoriske bunke, var det første spørgsmål: ”Opdelte jeg det eller ej?” Lad os gå til venstre, jeg vil ikke opdele tabellen. Nu kan det virke underligt, når jeg fortæller dig dette, men du kan have en ikke-partitioneret tabel, og så kan du ikke opdele indekset, som du er vant til, eller du kan opdele indekset. Stop og tænk. Din tabel har dybest set en spand, som du altid har tænkt, og alligevel vil dit indeks have flere spande. Når det sker, hvor der er et misforhold mellem antallet af spande og bordet, og antallet af spande i indekset, er det, hvad der menes med global. Og så, hvis tabellen ikke er partitioneret, og hvis indekset er partitioneret, betragtes det som globalt, fordi der er et misforhold. Lad mig nu gå tilbage på min organisationshaug og komme ned i stedet på partitionssiden. Hvis jeg nu har en partitionstabel, og lad os sige, at tabellen har fire spande, fire partitioner, kunne mit indeks have fire spande, så mit indeks matcher mit borddesign. Og så er det forbi, langt væk, på højre side. Dette ville blive betragtet som lokalt. Et lokalt indeks betyder dybest set, at opdelingen af ​​tabellen og indekset udføres på samme måde og har det samme antal spande. Og så når jeg først har det lokale indeks, kan det være et B-træ eller en bitmap, og den grønne pil, den slags går op, viser dig, at selvom det er et B-træ, er der stadig valg, der kunne træffes. Det kan være funktionsbaseret. Og også, hvis det er en bitmap, er der forskellige typer bitmaps. Der er noget, der kaldes et bitmap join index. Hvis du laver datalagring, er det en meget populær slags indeks til stjerneskema eller design. Det, der sker, er, at indekset har række-ID'erne for det, det peger på i tabellen, men det vil også have række-ID'er til overordnede tabeller, så når du er - skal du stjerne skema design og du ser ved en faktatabel peger det indeks på faktabordet dig på de data, du er interesseret i, og peger dig på hver række i dine dimensioner, så du kun skal have et indeks.

Og faktisk blev dette til på grund af Red Brick, som var en database for mange år siden - det kan mange mennesker huske. Og så, hvis du ser på dette billede - og husk, at jeg ikke lagde alt i dette billede, fordi billedet ville være meget større - der er stadig flere problemer, som jeg har i teksten her over den øverste højre del . Er det et omvendt ordreindeks? Og du kan sige, ”Hvorfor vil jeg have et omvendt ordreindeks? Det giver overhovedet ingen mening. ”Nå, hvis du er i et klynget miljø i Oracle, hvis du laver rigtige applikationsklynger, hvis du holder dine indekser i orden, så ikke omvendt, hvis du har en masse behandling, der rammer de samme værdier eller de samme indeksværdier, hvad der ville ske, ville du have varme områder af dit B-træ. Betydning af at du ville have strid og muligvis låse for at prøve at få adgang til det, og det ville du gøre på tværs af noder i et netværk. Hvis du har indekseret et omvendt ordreindeks, kan du nu fortryde det. Du kan sige, "Nå, de lignende værdier er i forskellige dele af træerne, så jeg har ikke mine separate knudepunkter, der konkurrerer om varme områder i træet." Og så bemærk også, at det unikke ikke fungerer med nogle af indstillingerne . Hvis du ser, har jeg nummer tre, fem, otte og elleve, så der er nogle tilfælde, hvor jeg ikke kan have et unikt indeks. Ligeledes er der nogle tilfælde, hvor jeg ikke kan have et omvendt indeks, og så er der yderligere problemer som logning eller ingen logning, og parallelt og ikke-parallelt. Jeg kan tildele ting til et specifikt område i hukommelsen.

Og dette efterlader stadig en hel del funktioner i Oracle. Jeg vil sige, at når du ser på Oracle 12, er der sandsynligvis igen omkring et halvt dusin ting, jeg kunne tilføje til dette billede. Indeksering er virkelig kompliceret, og jeg er virkelig enig med den tidligere højttaler, for at navigere gennem dette og træffe et godt valg, har du brug for et værktøj. Du har måske behov for et billede som dette og en slags metode til, hvordan du ville vælge ting, og forhåbentlig hjælper værktøjet dig med at komme dertil. Og så bliver det prøve og fejl. Jeg fortæller altid folk om indeksering, ”se inden du springer.” Og så kan du se den lille hund her, han springer uden at kigge, han ender i vand med hajen, eller fyren gør sig klar til at hoppe i vandet, og han vil impale sig selv. Du bliver nødt til at tænke på din indeksering, fordi at oprette et indeks ikke altid betyder, at tingene bliver bedre. Faktisk kan oprettelse af et indeks bremse tingene. Og forespørgselsydelse kan være en størrelsesorden bedre med det ene valg frem for det andet. Og jeg vil give dig et godt eksempel. Hvis du laver et stjerneskema med design, og på dine dimensionstabeller bruger du bitmap-indekser i et tilfælde, og i et andet tilfælde siger du: "Jeg vil bruge B-træindekser, " har du bitmap versus B- træ. Jeg kan fortælle jer, at den ene løsning vil være en størrelsesorden eller muligvis flere størrelsesordener hurtigere end den anden. Men husk, hvad der fungerer i et miljø, som i et datalagemiljø, sandsynligvis ikke er et godt valg i et OLTP-miljø.

For eksempel, hvis du skulle tage en transaktionstabel og sætte bitmap-indekser på et transaktionsbord, er det dyrt at beregne og nulstille bitmaps, disse lange strenge, og så i en OLTP-tabel, kan du måske slå tabellen så stærkt, at bitmap indeks kan blive korrupt og bremse dit system, fordi de bare ikke er beregnet til opdateringer. De er fantastiske til hurtig adgang, men er ikke gode til opdateringer. Jeg tror, ​​indeks tager prøve og fejl. Der er virkelig ingen gylden regel længere - der er for mange forskellige variabler i denne ligning til at vide - og i sidste ende bliver du nødt til at se på udførelse eller forklare planer i din database for at se, om du vælger gode valg eller ej. Og nogle gange kan plananalysen næsten være en videnskab for sig selv. Jeg vil ikke dække det i dag - det er et andet emne - men tager ikke indeksdesign for givet. Der er legitime grunde til, at der er alle disse skøre indekstyper, jeg viste dig, i det forrige billede, og som den foregående taler talte om. Disse blev ikke kun oprettet, fordi det var en pæn funktion at sætte en tjekliste et sted for en databaseleverandør; der er brugssager eller scenarier, hvor disse indekser er vigtige og vil gøre en betydelig forskel. Nu med det vil jeg vise dig nogle eksempler på forskellige typer indekser i et af vores værktøjer. Lad mig bare få min skærm op, så du kan se den. Okay, så her sidder jeg inde i - lad mig minimere denne applikation. Jeg sidder inde i VMware og kører en Windows Server 2012 VM.

Og du kan se, jeg har næsten ethvert værktøj, man kender. Som produktchef skal jeg være opmærksom på min konkurrence, så det er ikke kun, hvilke værktøjer jeg har, men hvad gør mine konkurrenter? Og vi har fået dette værktøj her kaldet DBwartan, som jeg allerede har kørt, men jeg kører - så jeg vil bare bringe det op. Og hvad du kan se, er at dette er et rigtig dejligt værktøj, for i stedet for at skulle bruge, siger en enterprise manager for Oracle og et SQL Management Studio til SQL Server og MySQL Workbench til MySQL og tolv andre databaser, som vi understøtter, godt, jeg har alle mine databaser indbygget i dette ene værktøj. Der er DB2, der er MySQL, Oracle, Postgres, SQL Server og Sybase, og det er - jeg har kun seks databaser i netop denne ting, fordi jeg ikke kan - værktøjet understøtter tolv databaser men min dårlige VM, der kører seks databaser samtidigt, og prøver at lave en demo er omtrent lige så meget som min hardware vil gøre det lettere. Så lad mig gå tilbage til Oracle nu, og hvis du bemærker, er alle disse ting de samme. Hvis jeg vil måle min ydelse i DB2, er det de samme valg, jeg ville have i Oracle. Nu under dækslerne laver vi masser af forskellige ting, så du ikke behøver at vide, hvad der foregår, men vi giver dig en ensartet grænseflade, så du kan være en ekspert med flere databaseplatforme. Og det ville omfatte arbejde med indekser, emnet for denne diskussion.

Lad mig komme ind her og lad mig først starte med at se på nogle tabeller, og jeg har en filmdatabase, der bare har et par tabeller. Og hvis jeg ser et bestemt bord, ligesom kundetabellen, når jeg bringer det op her, kan jeg se mit borddesign, her er mine kolonner i min tabel og her er oplysninger om hver kolonne. Jeg har egenskaber til tabellen, men bemærk, at jeg har en fane her for indekser, og jeg kan se, at der er indekserne på bordet. Bemærk, at et af disse indekser er mit PK-indeks, min primære nøgle. Disse andre ser ud til at være bare indekser til forbedring af adgang til forespørgsler, måske forespørger vi ved fornavn eller efternavn, eller vi ser på telefoner og postnumre. Og hvis jeg vælger et bestemt indeks, som dette postnummer her, og jeg dobbeltklikker på det, kan jeg nu se, hey, det er et ikke-unikt indeks, og her er nogle af de andre typer, bitmap, ikke-unikt, unikt, uanset om det er sorteret eller ej, uanset om det logger eller ej, om det er omvendt rækkefølge eller ej, hvad enten det er en funktionsbase Åh, her er en sjov, jeg ikke dækkede. Du kan faktisk have usynlige indekser. Og du ville sige, "Nå, hvorfor pokker vil jeg gerne lave et usynligt indeks?" Nå, jeg vil give dig et godt eksempel. Du er i dit produktionssystem, og du har et ydelsesproblem, og du er ikke sikker på, at oprettelse af indekset vil løse problemet, så du ikke ønsker at oprette indekset og bremse produktionen, men på en eller anden måde eller den anden du vil være i stand til at teste det. Du kan oprette indekset i produktionen som usynlig, hvilket betyder, at ikke mange applikationskoder, der kalder optimeringsprogrammet, vil bruge det indeks. Det er oprettet, det er gyldigt, men det vil ikke blive brugt. Derefter kan du tage en forespørgsel, som du tror, ​​at dette indeks ville hjælpe med, eller en række forespørgsler, og du kan sætte et tip ind og sige, “Hej, optimizer, der er et usynligt indeks derude, jeg vil have dig til at bruge og lade mig ved, om jeg har gjort tingene bedre. ”Og nu har jeg testet noget i produktionen, men jeg har ikke brudt applikationerne i produktionen, der kørte. Det er brugen til et usynligt indeks. Det lyder stumt, når du først hører om det, men det har brug.

Vi kan også på indekser definere, om de er parallelle, og også hvor mange tilfælde de er parallelle på tværs. I et ikke-grupperet eller et ikke-rigtigt applikations-klyngemiljø, så ville ikke-rack, parallel betyde, hvor mange delprocesser kan min forespørgsel få til for at prøve, og arbejdstagerprocesser, for at prøve at få ting igennem hurtigere eller hurtigere . Og parallelle tilfælde ville være, hvis jeg er i en rigtig applikationsklynge, siger jeg har ti noder, hvor mange af noder har jeg lov til at dele arbejdet på tværs? Måske er det fire af de ti, og på hver af dem fire underprocesser. Det er et eksempel. Og så har vi nøglekomprimering. Du kan faktisk komprimere indekser? Ja eller nej. Og så har du selvfølgelig dine lagringsparametre, som du kan angive på indekser. Nu dækkede jeg ikke disse, fordi de virkelig er mere en lagringsparameter end et indeksproblem. Og så har vi endelig, om vi skal gøre disse opdelt eller ikke-opdelt. Lad mig droppe det her et øjeblik. Jeg går til et andet skema. Dette er et stjerneskema, og for eksempel er denne periodetabel en dimensionstabel. Hvis du nogensinde har udført stjerneskema-design, har du typisk en dimension for tiden, og i denne database og dette stjerneskema er periode en tidsdimension. Nu ved jeg, at det vil se sjovt ud, du vil sige, “Gee, se på alle disse kolonner - har fyren nogensinde hørt om normalisering?” Nå, når du er i et datavarehus eller et stjerneskema design, du har typisk ikke - du har borde, som en typisk person vil se på og sige, “Gee, disse er ikke særlig godt designet.” Men det er sådan man gør det i et datalagermiljø.

Se nu, hvad der vil ske, for okay, der er alle disse kolonner, se på det, jeg har et indeks på hver eneste kolonne. Nu i et OLTP-miljø ville det være et nej. Det ville bremse alle mine operationer. I et datalagermiljø ville jeg slippe dem under mine batchbelastningscyklusser. Indlæs uden overhead eller indekser, og jeg vil genskabe indekserne. Og hvis jeg opdelte min tabel, i stedet for at skulle droppe indekset for hver spand i tabellen, kunne jeg bare droppe indekset på spanden eller spande, hvor data ville gå ind i denne batchbelastningscyklus. Og genskab derefter bare indeksdelen for disse spande. Og så det gør det meget overskueligt. Og hvis jeg ser på - så her er en søjle kaldet "Ferieflagg" og dybest set er det et ja eller nej. Bemærk, at dette er et bitmap-indeks, og for de fleste af jer vil du sige, ”Nå, det er fornuftigt.” Ja eller nej, Y eller N, der er kun to værdier, der giver mening. Og fordi når du læser dokumentationen for bitmap-indekser, fortæller de dig altid, at du vælger noget med lav kardinalitet.

Lad mig nu gå ind i en af ​​mine faktaborde, så her har vi mine ordrer. Og dette er mine ordrer pr. Dag. Og du vil se nu, at jeg igen har en hel del kolonner, og igen, jeg vil have mere end et par indekser. Og lige her har vi noget, der kaldes den universelle priskode. Dette var for en butik, så du kender de små stregkoder, når du køber noget i butikken, dette er den universelle priskode. Nu er der millioner af universelle priskoder. For dette bestemte firma, der solgte ting, havde de sandsynligvis 1, 7 til 2 millioner universelle priskoder, så du forventer, at dette ikke bliver et bitmap-indeks, fordi 1, 7 millioner forskellige værdier lyder som høj kardinalitet. Men i virkeligheden, i et datalagermiljø, ønsker du, at dette skal være en bitmap. Lad mig nu forklare hvorfor. Der kan være 1, 7 millioner forskellige værdier for denne universelle priskode, antallet af rækker i denne ordretabel er i hundreder af millioner til milliarder rækker. Mit indeks er lav kardinalitet sammenlignet med tabellens størrelse eller kardinalitet. Det gør det til en lav kardinalitet. Det gør bitmap-indekset nyttigt, selvom det er i modstrid med 1, 7 millioner forskellige værdier, som du ville vælge bitmap her. Hvis jeg nu vidste, at jeg ville bruge et bitmap join index, i øjeblikket understøtter produktet ikke det, får jeg det tilføjet til næste udgivelse, men det ville være et andet alternativ her. Og i et stjerneskema, husk, at bitmap-indekset ville være på faktabordet, og at et indeks i B-træet ville pege på rækken i faktatabellen og derefter til hver række, der var synlig i dimensionstabellen for det faktum . Og så har du en anden mulighed der. Og så, lad os se, jeg vil komme ud af borde nu, og jeg vil bare vise dig hurtigt, at jeg har de samme oplysninger, under indekser, og jeg vil gøre den samme grundlæggende ting.

Årsagen til, at jeg bragte dette op, er, at du måske bemærker, hej, her er ingen primære nøgler. Primære nøgler udføres med en nøglebegrænsning, så de er faktisk omfattet af begrænsningsdefinitionerne. Dette ville være indekser, der ikke er en del af begrænsningen. Nu kan du sige, "Nå, vent et øjeblik, det kan se ud som en fremmed nøgle, og en fremmed nøgle er en begrænsning, " men udenlandske nøgler og de fleste databaser opretter ikke automatisk et indeks i den udenlandske nøglekolonne, selvom det er tilrådeligt, og der går du - Jeg har alle de samme valg igen. Og hvis jeg vil ændre sig bare for at blive komprimeret, kan jeg gøre det.

Nu fungerer komprimering kun på et B-træindeks. Hvad det tillader er, når man ser på de forskellige noder i B-træet, giver det mulighed for komprimering af nogle af værdierne. Det er virkelig ikke komprimering som tabelkomprimering, det er en komprimering af, hvad der er gemt i B-træet i ikke-bladknudepunkter. Det sparer ikke masser af plads, men det kan gøre en forskel. Og med det bemærkede jeg, at jeg kommer temmelig tæt på tiden, så hvad jeg vil gøre er, at jeg vil gå tilbage og stoppe min deling. Og vi har vores produkt derude til en 14-dages prøveperiode på idera.com. Det er et temmelig godt produkt, især hvis du arbejder med flere databaseplatforme. Hvis du arbejder med to eller tre forskellige databaser, vil dette værktøj gøre dit liv meget lettere. Vi har værktøjer til at hjælpe dig med indeksdesign og valg, vi har et værktøj kaldet DB Optimizer. Jeg kunne bare ikke dække det i dag, det ville være for meget. Og hvis du vil kontakte mig, er der min e-mail-adresse, det er, eller du kan hente mig på min private e-mail, og jeg har blogs, jeg har et websted og blogs og en LinkedIn-profil der. Så føl dig fri til at nå ud til mig om noget, selvom det ikke er produktrelateret, hvis du bare vil tale databaser, jeg er en nørd i hjertet og jeg elsker at gab om technobabble.

Eric Kavanagh: Okay, godt Dez, Robin, jeg er sikker på, at du hver især har et par spørgsmål i det mindste, vi har få minutter tilbage her. Dez, hvad synes du?

Dez Blanchfield: Jeg har et stort spørgsmål, jeg må stille dig, det har siddet bagpå i mit sind. Hvad er det skøreste scenarie, du har set? Jeg har læst din blog, jeg følger dig nøje, - du er sandsynligvis en af ​​de få mennesker, der har boet i næsten enhver usandsynlig, og jeg tror, ​​at Dr. Robin Bloor er det andet, jeg har mødt i min levetid. Men, du ved, du har sandsynligvis set hvert vanvittigt scenario, hvad er nogle af de skøreste scenarier, du har set, at du er stødt på, og som mennesker, der bare ikke kunne klare det, har du formået at gå og udføre Jedi-mind-tricks med hele denne DBarusan?

Bert Scalzo: Vi havde en kunde engang, som de i deres databasedesign troede meget på, hvordan de ville tænke i et fillayoutdesign, og så, det - når du normaliserer en database, er den første ting du prøver at gøre slippe af med af gentagne grupper. Nå, de havde en kolonne, og de lavede den til en lang, eller en BLOB eller CLOB, og i den ville de sætte værdi, nummer et, semikolon, værdi nummer to, semikolon, værdienummer, semikolon, og de ville have tusinder af værdier derinde, men de var nødt til at søge i den kolonne, og de er som, "Hvorfor kører denne ting så langsomt?" Og jeg er ligesom, "Nå, du kan ikke oprette et indeks over, hvad du gjorde, det er bare ikke tilladt. ”Så vi viste dem faktisk ved hjælp af planerne, at det, de havde brug for, var at normalisere tabellen. Ikke fordi normalisering er en vis akademisk øvelse, der gør tingene bedre, men fordi de ønskede en forespørgsel på det felt, hvilket betød, at de ville være i stand til at indeksere det, og du kunne ikke indeksere det på en gentagende gruppe, eller i det mindste ikke let . Og det er sandsynligvis det værste, jeg nogensinde har set.

Dez Blanchfield: Ja, det er interessant, hvor ofte du støder på, jeg tror, ​​udfordringen med databaser, folk glemmer, at det er en videnskab. Og der er mennesker, der laver grader og ph.d.er i hele dette rum, skriver papirer om det, og du har skrevet en hel swag inklusive dine TOAD-håndbøger og andre ting fra hukommelsen. Tendensen mod slags "store data" citat-på-citat nu - jeg ser en masse mennesker glemme grundlæggende elementer i databasearkitektur og databaseteknologi, databasevidenskab, hvis du vil. Hvad ser du ude i marken så langt som skiftet væk fra traditionelle databaseplatforme og traditionelle databasetanker, som vi tænker på, at vi effektivt spikede til jorden, og det var bare et tilfælde af performance tuning og skalering. Ser du, at mange mennesker lærer igen og har en oplevelse, hvor de bare sidder der og har et "a-ha" øjeblik, som et eureka-øjeblik, hvor de er klar over, at disse big data-ting faktisk bare er en slags rigtig store databaser? Er det en ting derude, og folk svarer dig tilbage og slags: ”Vi har glemt, hvad vi vidste, og kan du bringe os tilbage fra den mørke side?”

Bert Scalzo: Nå, nej, og det er forfærdeligt at skulle indrømme, men de relationelle databaseleverandører har også drikker den Kool-Aid. Hvis du husker, jeg ved det ikke, for omkring et årti siden begyndte vi at placere ustrukturerede data i relationelle databaser, hvilket var en slags underlig ting at gøre, og derefter tilføjer dataene, de relationelle databaser, nu NoSQL-typen ting og sager. Faktisk, i Oracle 12, CR2 - jeg ved, at den ikke er ude endnu - men hvis du ser på betaen, hvis du er i beta-programmet, understøtter det afskærmning. Og så, nu har du en relationsdatabase, der ikke har tilføjet konceptet fra NoSQL-afskærmning. Og så synes "a-ha" -øjeblikket at være mere for de mennesker på den relationelle side, der går "a-ha." Ingen vil nogensinde gøre det rigtigt igen, ikke engang databaseadministratorerne, så vi har blev nødt til at gå over og gå sammen med den mørke side.

Dez Blanchfield: Okay, så du siger et skift til en masse af de rodede data, hvis jeg forstår det rigtige, at blive sat i det, hvad vi nu kalder big data platforme, hvilket er lidt sjovt, fordi de ikke så gammel, men betyder det ikke, at de fokuserer på det, de laver med deres relationelle database for at få mere penge for deres penge?

Bert Scalzo: Nej, normalt, hvis de har et behov i det - der ville have været citeret et "stort datatype behov", finder de ud af at i stedet for at skulle gå til den anden databaseplatform og gøre noget i et ikke -forholdende måde, databaseleverandørerne giver dem nu de samme ikke-relationelle teknikker inde i deres relationelle database for at gøre disse ting. Jeg mener, et godt eksempel ville være, hvis du har ustrukturerede data, som en JSON-datatype eller en anden kompleks datatype, der har betydning indlejret i selve dataene, understøtter databaseleverandørerne ikke kun det, men de giver dig SUR overholdelse af ustrukturerede data. De relationelle databaser har omfavnet de nyere teknikker og teknologier, og så synes "a-ha" igen at være mere ikke, "Hej vi, applikationsudviklerne, har aflært noget, og vi er nødt til at lære det igen, " det er "Hej, vi gør det på denne måde nu, hvordan kan jeg gøre det på den måde i din traditionelle relationelle database og gøre det som jeg gør i denne database herover? ”og det bliver mere udbredt, og som sagt, databaseleverandørerne selv aktiverer at.

Dez Blanchfield: Okay, hvem er de traditionelle mistænkte i dette rum for værktøjet DBbrevan og det? Jeg lavede nogle lektier om, hvad du for nylig havde skrevet, og fra hukommelsen havde du skrevet noget, jeg tror, ​​det var en af ​​dine blogs, om ekstrem databaseydelse i Oracle-verdenen. Jeg kan ikke huske, hvornår det var, jeg tror, ​​det var engang i år fra hukommelsen, eller fra sidst på sidste år, du havde skrevet denne ting. Og det syntes for mig, at det var den traditionelle, sædvanlige mistænkte for den type emne, vi taler om i dag, hvor folk vil gå til et meget stort databasemiljø og se efter, hvad du kalder ekstreme gevinster i det. Hvem er de sædvanlige mistanker om, at du ser derude, der tager DBwartan og anvender det godt?

Bert Scalzo: Nå, vi har mange kunder, faktisk var jeg i dag med et meget stort regeringsagentur, som - og de bogstaveligt talt har sandsynligvis tæt på 1.000 eksemplarer af vores software, fordi det giver folk mulighed for at fokusere på, hvad de har ' gør det igen, og ikke hvordan man gør det. Og det er okay, jeg mener, alle burde vide, hvordan man gør noget, men produktiviteten får det ”hvad” til. Hvis virksomheden beder mig om at udføre en opgave, er det alt, hvad de er interesseret i. Hvornår fik jeg et afkrydsningsfelt til at sige, hvornår opgaven blev udført? Ikke hvilken teknik eller hvilken teknik, som jeg brugte for at komme dertil. Og så giver vores værktøj dem mulighed for at fokusere på hvad, og lader dem være langt mere produktive, og det er virkelig den enorme fordel, og som sagt, nogle databaser tilbyder et værktøj bare til deres databaseplatform. Vi tilbyder det til tolv databaseplatforme. Jeg har den samme arbejdsgang, den samme grafiske brugergrænseflade, de samme navigationer. Hvis du ved, hvordan man tildeler et privilegium til en bruger, eller hvordan man opretter en tabel eller opretter et indeks i en database, kan du gøre det i alle tolv, fordi det er det samme udseende og den samme arbejdsgang. Det har en enorm værdi for vores kunder.

Dez Blanchfield: Ja, jeg gætter på, at folk vil have meget mere knall for deres penge fra deres menneskelige ressourcer. Og dagene med at have en individuel specialist i Oracle, Ingres og DB2 er alle væk. Folk forventes at være Jack for alle handler, så jeg tror, ​​at denne ting absolut har reddet deres liv.

Bare en sidste hurtige ting, før jeg overleverer den til doktor Robin Bloor. Du nævnte, at der er en gratis download i fjorten dage, hvad gør - hvis jeg vil gå videre, og jeg vil gøre det, forresten, vil jeg lægge det i Bloor tech lab og spin denne ting op og få hænder på det selv - jeg havde ikke haft en chance for at gøre det før i dag. Du nævnte en prøve på fjorten dage, du sagde, at du kører den på en VM på din computer, jeg antager, at det er en bærbar computer. Hvad er, hvad er indstillingsniveauet for nogen til at få hænder på og bruge den fjorten dages prøveperiode, lige før jeg afleverer Robin til hans spørgsmål?

Bert Scalzo: Ethvert Windows-miljø, så Windows 7, virtuel maskine med en CPU og fire spillejobs. Vi er ikke et rigtig fedt eller dyrt værktøj. Hvis du nu ville køre din databaseserver på den samme VM under den samme Windows, ja, skal du tilføje mere, men hvis du kører din database på en databaseserver eller på en separat VM, skal VM indlæses og kør vores produkt er meget let: en CPU, fire spillehukommelser, stort set enhver version af Windows - og vi understøtter både 32oginstallationer. Men du behøver at installere din databaseleverandørs klient. Så hvis du ville oprette forbindelse til Oracle, skal du installere SQL-netklienten, fordi det er, hvad Oracle kræver, for at du kan tale med en database.

Dez Blanchfield: Det lyder ret ligetil. Jeg tror, ​​at en ting fra dette mere end noget andet, som jeg håber, at folk vil fjerne, bortset fra erkendelsen af, at dette værktøj kommer til at redde deres liv, er, at de skal gå og hente det og lege med det, i betragtning af at du tilbyder en fjorten dages gratis prøveperiode. Og det kan køre på deres nuværende bærbare computer uden at installere noget ekstra, for hvis de allerede udfører databaseadministration, arbejder de allerede med databaser, de har alle disse værktøjer på plads, og om det kører på en lokal VM eller på deres lokalt skrivebord, det lyder som om det er smertefrit at installere og lege med. Så jeg kan varmt anbefale folk at gøre det.

Robin, jeg er sikker på, at du har spørgsmål, og Eric, du har sandsynligvis fået nogle fra publikum, så Robin, hvad med at gå videre til dig og derefter tilbage til Eric?

Robin Bloor: Ja, okay, jeg har ting at sige, jeg mener, jeg har altid fundet dette område fascinerende, fordi det var - jeg skar tænderne på det. Men sandheden er, sandsynligvis siden omkring 1998, 1999, har jeg været opmærksom på, hvad Oracle faktisk er i stand til. Og jeg kendte Sybase og Microsoft SQL Server, begge af disse er ret enkle sammenlignet med hvad Oracle kunne gøre. Du fik mig til at grine, når du - jeg mener, jeg dækkede min mund, da du begyndte at tale om skærning. Oracle gjorde dette før. Oracle introducerede på et tidspunkt, de blev nervøse for den objektrelationelle idé, så de introducerede evnen til at skabe en slags objektnotation og objektslagring i Oracle, og jeg talte med en af ​​deres ingeniører, noget som et par år efter, de introducerede det, og jeg spurgte, hvor mange mennesker, der brugte det, og han sagde, at jeg tror, ​​to kunder havde prøvet det, og det var det. Og jeg tror, ​​at den samme ting vil ske, hvis de begynder at prøve at udføre NoSQL-ting. Du ved, jeg tror, ​​det er en fejltagelse, jeg mener, jeg er slags interesseret i, hvad dine tanker er. Bestemt, de - de drikker Kool-Aid. De føles som om de skal være i stand til at fremsætte påstande, der ligner de store NoSQL-databaser som Cassandra, men du ved, har det nogen mening for dig?

Bert Scalzo: Nej, du har ramt neglen lige på hovedet. For mig ville jeg, hvis jeg vil gøre relationelt, vælge en relationel leverandør som en Oracle eller en SQL Server eller en DB2 eller en Postgres, men hvis jeg skal gøre noget, der ikke er relationelt, i big data-rummet, eller NoSQL-rummet, vil jeg vælge det rigtige værktøj til det rigtige job. Og jeg tror ikke, det ville naturligvis først gå til min relationelle databaseleverandør. Og så tilføjer du den anden rynke til den, dvs. hvad er tilgængeligt i skyen? Så mange mennesker, der ønsker at få deres databaser fra premisset. Så skal du kigge på din skyudbyder og sige, ”Okay, hvad leverer du, hvilke databaser har du til rådighed for mig, der passer til mine behov, og hvor salgbare er de, og ærligt talt hvad er prisen eller gebyret for at bruge denne database i skyen pr. time eller pr. dag. Og pr. Gigabyte eller terabyte? ”Og hvad du finder, er måske nogle af de relativt nyere databaser som Mongo eller Cassandra, måske er deres priser billigere, så hvis du vil lave big-petabyte-type store data, kan du måske er nødt til - lige ud fra omkostningssynspunktet - at overveje NoSQL-databaserne i skyen, fordi de muligvis er den mest omkostningseffektive måde at gøre det på.

Robin Bloor: Ja, ret. Jeg mener, min slags - tinget med relationelle databaser i min erfaring - som er lang nok til at have ar, det er helt sikkert - der er en masse sund fornuft, at hvis du begynder at anvende det, og - du forstår, hvad relationen faktisk er, at, Jeg mener, jeg kan huske, at jeg skulle konsultere en kunde en gang, og de førte mig ind i et rum, og de havde lavet et slags enhedsdiagram og oprettet en tredje normal form, en model for, hvordan virksomhedens primære systemer var. Den havde to hundrede og fyrre borde omkring, og de sagde: ”Nå, hvad synes du om det? Vi vil oprette en database til dette, ”og sagde” Hvad synes du om det? ”Jeg sagde, ” Jeg tror ikke, det vil fungere. ”Og det er nøjagtigt, ved du, fordi de sluttede op for at skabe en bestemt struktur inden for ellevevejsforbindelser. Og det er det, man skal forstå om relationelle. Så jeg er lidt interesseret i, hvor meget dårligt design du støder på. Jeg mener, jeg har ikke noget problem med DBwartan - det gør meget fornuftige ting, og det faktum, at du faktisk kan vise ud på flere platforme, synes jeg, er vidunderligt - men hvor meget støder du derude, hvor designet er spørgsmål hvor folk kunne have løst sig selv alle slags hjertesorg, hvis de kom til et stjerneskema i stedet for at få snefnug om det, ved du?

Bert Scalzo: Nå, jeg vil ikke lyde, formodende eller arrogant, men jeg vil sige oftere end ikke. Det er klart, at størstedelen af ​​databaserne, som jeg engagerer mig derude, de har problemer eller problemer. Hvilket er godt, fordi vores værktøjer, ligesom vores databaseoptimeringsværktøj, kan hjælpe dem med at løse disse problemer, og, men hvad der virkelig er sjovt for mig, er, at mange af problemerne er de samme enkle problemer igen og igen. Jeg arbejdede lige med en kunde forleden, der havde en elleve-vejs-forespørgsel, og jeg er ligesom, ”Okay, hvorfor brugte du ikke en med klausul?” Og de er ligesom ”Nå, jeg gjorde ikke ved ikke, hvad det er. ”Og så sagde jeg, “ Og se på dine undervalg her på dit korrelerede og dit ikke-korrelerede, ”sagde jeg, “ I nogle tilfælde har du i dit, hvor klausul på det dybeste niveau, en tabelreference fra det ydre. ”Jeg sagde, ” Det er, flyt det ud til det rigtige niveau, ikke integrer det dybere, end det skal være, du vil forvirre optimisatoren. ”Og med et par par tweaks vi tog noget, der kørte omkring to timer og fik det ned til ti minutter, og det var bare - i så fald gjorde vi ikke andet end at forbedre SQL, som de havde skrevet. Jeg tror, ​​problemet er, at en masse universiteter og en masse mennesker, der lærer programmering i et ikke-akademisk miljø, de lærer det som registrerede tidsprocesser eller rækkeorienteret proces og relation er et sæt orienteret af naturen, og så du er nødt til at tænke i sæt for at skrive god SQL.

Robin Bloor: Ja, det synes jeg er helt rigtigt. Og du er nødt til at forstå, det er ting som folk burde kende ABC'erne for ting som dette. Det betyder ikke noget. Du vil ikke være i stand til at gøre rationelle ting, hvis du ikke er klar over, at selv en veludviklet, velmodificeret database, sammenkoblinger vil tage tid, sorterer vil tage tid. Det gør de, fordi verden aldrig har fundet en måde at få dem til at gå hurtigt. De har fundet måder at organisere dataene på, så de går hurtigere end ellers, og meget af den entusiasme, jeg har at sige for NoSQL-databaserne, er simpelthen at de undgår at gøre sammenføjninger. De begynder bare at opbygge databaserne med den samme spredning af data i dem, for hvis du deltager i nogen af ​​NoSQL-databaserne, suger de mægtigt. Tror du ikke?

Bert Scalzo: Åh absolut. Og jeg må grine, fordi jeg begyndte langt tilbage før relationelle databaser og tilbage, da Ingres var RTI, Relational Technology Institute, og vi havde ikke SQL, vi havde præ-SQL relationelle sprog. Jeg tror, ​​i Ingres, dengang hed det Quel. Så du kom fra disse gamle databaseparadigmer som netværk og et højere grafisk eller hierarkisk, og du går gennem de relationelle paradigmer efter et par årtier, og nu for mig føles det som om vi vender tilbage til næsten en hierarkisk igen. Det er næsten som om vi har vendt tilbage.

Robin Bloor: Ja, ret. Bedre overdragelse til Eric, jeg bruger meget tid, men har vi spørgsmål fra publikum, Eric?

Eric Kavanagh: Det gør vi, vi har få. Vi går lidt længe her, men jeg kaster et par over på dig. Vi havde et par spørgsmål omkring de usynlige indekser. Et spørgsmål var: "Har nogen brug for at bruge dit værktøj for at se dem?" Et andet spørgsmål var: "Nå, hvad nu, hvis du er blind?"

Bert Scalzo: Det er godt.

Eric Kavanagh: Også nysgerrig spørgsmål, så bare FYI.

Bert Scalzo: Nej, du behøver ikke have vores værktøjer. Det er en Oracle-funktion, det usynlige indeks. Grundlæggende i dataordbogen opbevarer Oracle bare et stykke metadata, der siger: ”Optimizer, ignorér dette indeks. Det er her, men medmindre du er fysisk instrueret via et tip i, et optimizer-tip i SQL-kommandoen, skal du ikke bruge dette. ”Og så, nej, du behøver ikke at have vores værktøjer og i enhver henseende det er et almindeligt gammelt indeks, du kan se det i et hvilket som helst værktøj, det er bare optimiseren, der siger: ”Vi ignorerer det i normal forespørgselsbehandling.” Du skal rette det, hvis du vil have det til at blive brugt. Det er virkelig praktisk til det scenarie, jeg beskrev, som er, hvis du ville opbygge et indeks i produktionen, men ikke risikere at bryde rapporterne, eller de ting, der allerede kører, men du ville teste dem, kunne du gøre det. Det er hvad det er mest nyttigt til.

Eric Kavanagh: Det er gode ting, og så var der et andet godt spørgsmål her. ”Hvad med nogle af disse nye databaser i hukommelsen? Hvordan ændrer databaseteknologi i hukommelsen spillet med hensyn til indeksering? ”

Bert Scalzo: Boy, well we – now that's a good, I'm glad someone asked that question, we're going to have to go another half hour. No, the in-memory, it depends on the database vendor. Now, normally, I am, I speak nothing but praise of anything that Oracle does because it's amazing the technology they've built, but when you tear back under the covers and you look at what in-memory is in Oracle, in the Oracle database, what it is in reality is it still kept row store on disk, and it will get loaded column-store in-memory, and if there's insufficient memory to hold the whole table, it will revert back to for the portions; it won't fit in memory, to doing it row store, and so you could actually do a select against the table and for half the table, you 're using an indexing hitting traditional rows at the table, and for the other half of the select it's actually going out and just grabbing everything from an in-memory search, and so, it's different in the way that SQL Server, for example, implemented it with their Hekaton technology, you know, and SQL 2014, and it's been improved in SQL 2016, but in some respects, theirs is a more true version of in-memory, and, but each implementation has a pros and cons, but you have to kind of look under the covers and realize. Because, I had a customer who said, “Oh this table's in-memory – I'm just going to draw up all the indexes, ” and I'm like, “The table's bigger than the memory that you have on the server, so at some point some of the query's got to hit disk.”

Eric Kavanagh: That's a good description; that's good stuff. Well, folks, we're going to have a few more webcasts with these guys over the rest of this year, come back anytime you hear of Bert being on a presentation because we know he knows his stuff. It's always fun to talk to the experts. We do archive all these webcasts for later viewing. Here's Bert's contact information once again, and we'll try to dig up that link for the download and send it out as well by email, but you can always email yours truly:, we've got a bunch more webcasts lined up for this year and we're doing the ed cal right now, so, folks, if there's any topics you really want to hear about next year, don't be shy: Take care, folks, we'll talk to you next time. Bye-bye.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved hjælp af indstillingerne til højre. For info om, hvordan vi samarbejder med branchepartnere, klik her.

• Profil
• Internet side