Indeks sinnssykdom: hvordan unngå databaser kaos

Av Techopedia Staff, 5. oktober 2016

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

Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved å bruke alternativene til høyre. For informasjon om hvordan vi samarbeider med bransjepartnere, klikk her.

• Profil
• nettsted

Eric Kavanagh: Mine damer og herrer, hallo, og velkommen tilbake igjen. Det er en onsdag, klokken fire øst, og de av dere som kjenner programmet, vet hva det betyr, det er på tide med en annen episode av Hot Technologies. Ja absolutt. Jeg heter Eric Kavanagh, jeg vil være din moderator for dagens økt: "Indeks Sinnssykdom: Hvordan unngå databaser kaos." Eller som jeg henviste til det i den siste e-post-eksplosjonen for å gå ut, “database wrangling.” Hot term i disse dager, “wrangling.” Alle gjør det. Det er et lysbilde om ditt virkelig. Og nok om meg.

Så var Hot Technology-serien virkelig designet for å definere et bestemt rom, i motsetning til Briefing Room, som bare er en-til-en live analytiker orientering, for Hot Tech får vi to analytikere. I dag kommer det til å være vår helt egen lege Robin Bloor og vår dataforsker Dez Blanchfield. Og vi snakker om et tema som jeg synes er virkelig ganske symbolsk for hva som skjer på markedet i dag.

Hovedpoenget er at vi er i en verden av kompleksitet i disse dager. Virkelig, hvis du tenker femten år tilbake, eller tjue år, var det en veldig annerledes verden den gang, spesielt med tanke på databaseteknologi. Databaser pleide å være ganske enkle. Det var bare en håndfull av dem; de fleste av dem var relasjonelle. Nå har vi hele panopien til databaseteknologier. Bokstavelig talt mange alternativer på bordet for alle som ønsker å bygge en applikasjon eller gjøre noe med data. Alt endrer seg, og det påvirker menneskene som prøver å administrere disse systemene. Vi skal snakke i dag med Bert Scalzo, som er en ekte ekspert på området; han er den øverste produktledelsen for IDERA, om hva du kan gjøre for å få tak i alle disse dataene. Med det skal jeg overlevere det til doktor Robin Bloor for å ta det bort. Robin, gulvet er ditt.

Robin Bloor: Ok, takk for introduksjonen. Jeg tror det - fordi det er en tohånds ting, tror jeg at jeg bare ville snakket om databaseoptimalisering generelt som en introduksjon til dette Hot Tech-showet. Jeg begynte livet - innen teknologi og analyse - jeg begynte med å gjøre dette fordi jeg pleide å skrive artikler om databasefunksjonene på DEC VAX-plattformen. Og av den grunn brukte databasebrukere meg. Og det som forekommer for meg er at hvorfor skulle du ha en database? Jeg mener, i disse dager pleide det veldig mange mennesker å lage nøkkelverdifiler og bruke dem til å ha en slags indeks-sekvensiell feil som vi kaller dem, men for å lage en slags databasefunksjon, og du vet, hvorfor ville du ha noe annet?

Og svaret på det, jeg tror Michael Stonebraker ga det beste svaret på det, og han sa: "En database kan vite mer om hvor dataene er og hvor raskt å få det, enn noe program noensinne kan vite." Og jeg synes det er interessant; det er spillet. Men i 19 - vel 1989 som jeg startet i teknologianalyse, og du vet, på det tidspunktet var databaser veldig enkle og relasjonsdatabaser var superenkle. De hadde så liten kapasitet, jeg mener, de kunne lagre data, tydeligvis, og du kunne sikkerhetskopiere og de hadde, de var ACID-kompatible, men de hadde virkelig veldig svake optimisatorer. Faktisk ville det være vanskelig å argumentere for at de i det hele tatt hadde optimaliseringsevnen.

Og senere ble de bare bedre og bedre, men, du vet, når en database ikke fungerer - som disse kenguruene ser ut til å være på en eller annen måte indikerer - kan det være forferdelig mange grunner til at det går sakte. Og det bringer meg til poenget: Databaser har mange funksjoner, men den viktigste er spørreoptimalisering. Hvis de ikke gjorde det, ville du ikke brukt dem. Det handler om å få informasjon raskt, det handler om å kunne gjøre det når det er mange brukere samtidig, og det er et vanskelig problem. Og når du faktisk ser på, la oss kalle dem modne databaser, hvis du vil - men absolutt Oracle, i litt mindre grad, Microsoft SQL Server, absolutt Teradata og DB2 - som optimalisererne av disse databasene har fått, har vært flere tiår i bygning. Du vet, de gjorde ikke - noen satte seg ikke på - seks karer på en to-mann, år, prosjekt og bare banket en sammen. Det fungerer ikke sånn. Optimaliseringsevnen har gradvis vokst, og det krever mye vekst. La oss uansett snakke om bakgrunnen til databasen. Det er vel veldig mye som er sagt om NoSQL-databasen nå, og det er til og med mye entusiasme for grafdatabase. Og bruken av SQL over Hadoop og sånt. Men sannheten er at hvis du vil ha en database akkurat nå, hvis du vil ha en fullt funksjonell, i stand til OLTP og stor spørretrafikk, er det en relasjonsdatabase, eller den er ingenting.

Blant relasjonsdatabaser er Oracle dominerende i popularitet. Microsoft SQL Server, tror jeg, er nummer to. De kan begge brukes til OLTP og arbeidsmengde, men du kan faktisk ikke slippe unna med å blande disse arbeidsmengdene. Du trenger forskjellige hendelser for OLTP-arbeidsmengder og spørsmålsbelastning. Det er alternativer til SQL og graf. De fleste selskaper standardiserer en spesifikk database, og det er grunnen til. Jeg mener at etter flere tiår med å kjempe den mot alle de andre spillerne, ble Oracle den mest dominerende. Rett og slett fordi de endte opp med å kunne selge bedriftslisenser, og slik at selskaper bare ville bruke alternative produkter i eksepsjonelle produkter, ville Oracle ganske enkelt ikke gjøre det. Og databaser er strategiske ved at de også utvikler seg. Og du vet at jeg gjorde litt research for denne presentasjonen, og det er slags - jeg kommer til det om en stund, men det er litt interessant hvordan de utvikler seg, når det gjelder å se på det fra en DBAs stilling. Dette er hva jeg kaller den usynlige trenden. Det er Mores lov kubisert. Det er omtrent slik: Den største databasen er, og nye databaser, det er ikke en gammel database som har mye mer data å innta. Det er vanligvis en database som brukes på et nytt problem. Og de vokser faktisk med tanke på datamengder. Omtrent ved kuben til Moore's lov. Så Moore lov er en faktor ti ganger hvert sjette år. VLDB-er har en tendens til å vokse en faktor på tusen hvert sjette år. I 1991, 1992, blir de store databasene målt i form av megabyte. I '97 og '98, gigabyte. 2003, '4, terabyte. 2009, '10, begynte du å se petabyte-databaser. Jeg tror det muligens var en eller to databaser med eksabyte der ute akkurat nå, men den største jeg har hørt om er de 200 petabytene i tide, og du vet, ikke får data til en petabyte-databaser. Men det er mest av det som åpenbart vil være de nye store web 2.0-selskapene, muligens har du Facebook på vei i den retningen.

Men uansett, hvis du faktisk ser på det, og forventer at en database skal gå gjennom den slags opptrapping i volum, spør det mye. Og bemerkelsesverdig, absolutt opp til petabyte-nivået, ser de ut til å ha gjort det bra. Jeg mener, jeg snakker om de eldre produktene i stedet for noe nytt. De ser ut til å ha gjort det ekstra godt. Hvis vi ser på databaseytelse, flaskehalser, tar dette meg tilbake til tiden jeg faktisk pleide å bry seg om dem, og måtte bekymre meg for dem. Du vet at dette grunnleggende er sammenbruddet på maskinvaren. Det er flaskehalser i CPU, muligens er det flaskehalser i minnet, muligens er det flaskehalser på harddisken. Det kan være nettverket som forårsaker sorg, og du kan også få problemer med låsing, avhengig av hva du gjør, men normalt er det fordi programmet ikke vet hvem du skal ringe lås. Så hvis du skal stille inn en database, prøver du faktisk å stille den inn slik at den danser mellom disse fem mulige flaskehalsene så godt den kan gjøre. Og det er ingen enkel sak, fordi mengden minne du kan konfigurere på en gitt server økes dramatisk. Så har CPU-er blitt flerkjerner, disk, vel, vi kan nå gjøre, tror jeg, selv på varetjenere, tror jeg at du kan gjøre hundrevis og hundrevis av terabyte, fjerdedel petabyte, kanskje, til og med på en vareserver. Så av alle disse tingene kan du leke med, nettverk kan selvfølgelig gå i forskjellige hastigheter, men mest når du har med databaser, vil du virkelig ha fiberkabler mellom serverne og ingenting annet som kjører på det, spesielt den veien.

Databasens ytelsesfaktorer. Jeg mener, jeg forlater hva dette kommer til å handle om, for jeg vet at Dez kommer til å snakke om det, men dårlig databasedesign betyr en database med dårlig ytelse. Dårlig programmeringsdesign kan muligens bety å kaste veldig dum SQL på en database, som bare vil ta forferdelig mye lenger tid. Samtidig og blanding av arbeidsmengde, for mye samtidighet vil føre til flaskehalsproblemer. Arbeidsmengdeblandingen, når du har store spørsmål med veldig små, korte, skarpe spørsmål, forårsaker problemer. Det er et belastningsbalanseringsproblem. De fleste databaser tar seg av det, men hvis du ikke har et sofistikert produkt, vet du, bare å legge til noen få servere, ikke er alt du gjør hvis du faktisk ønsker å øke størrelsen på en klynge. Du må faktisk balansere belastningen før du får optimal ytelse. Du må gjøre kapasitetsplanlegging. Absolutt. Spesielt nå i disse dager som da datamengdene øker mer dramatisk enn de pleide for databaser. Og det er problemer med hele datasjiktet til hvordan du tar inn dataene, hvordan du flytter data om. Å ikke få data til en database i tide kan være et ytelsesproblem senere, fordi vi har gått fra databaser som jobber i Windows, til tjuefire av sju av trehundreog syttifem operasjon, og det er ingen vinduer der du kan bremse databasen nede, eller det er usannsynlig at det vil være i dag.

Oracle DBA-problemet. Dette var hva jeg tenkte på. Jeg har vært i Oracle's DBA med Oracle 7, og jeg husker hvordan jeg skulle innstille det. Og hvis du faktisk ser på Oracle nå, er det måte, måte - det har måte, langt mer evne. Det har indeksering av bitmap og sånt, men jeg tok meg faktisk tid til å se og se hvor mange innstillingsparametere det faktisk er i en Oracle-database for øyeblikket. Og det er over tre hundre og femti innstillingsparametere, og det er ytterligere hundre skjulte parametere, som spesialiserte DBA-er kanskje vet om, men normale Oracle DBA-er ikke vet om. Og det betyr at det er en tøff ting å stille inn denne typen databaser. Det er ikke en enkel ting i det hele tatt. Du må føle det, du må ha gjort det i lang, lang tid, og du må vite nøyaktig hva problemet du tror du løser, fordi innstillingen starter når ytelsen blir dårlig, men det er kanskje ikke ytelsen til alt. Det kan være ytelsen til spesifikke spørsmål som betyr noe, og du kan kanskje fikse det ved å feste bestemte data og minne, eller det kan hende du trenger å fikse det ved å indeksere, eller det kan hende du må begynne å partisjonere på en annen måte. Det er mange ting du kan gjøre, er poenget. Så derfor kommer de ikke til å gjøre det i hodet - DBAer trenger verktøy. Jeg skal nå gi videre til Dez som skal fortelle deg om indeksering, tror jeg.

Eric Kavanagh: OK, ta den bort.

Dez Blanchfield: Takk, Robin, og jeg elsker forsiden. Jeg tror du har kastet måla der nede for at jeg skal komme til og med komme nært noe så spennende. Men jeg har brukt et bilde av vår lille galakse, som mitt syn på hva dagens utfordring for databaseadministratorer har blitt til, fordi dette er det mentale bildet som jeg pleier å trylle frem når jeg kommer inn i et miljø og jeg ikke lenger er i en verden av å administrere databaser eller designe databaser på det nivået lenger. Men som deg selv har Robin og jeg hatt mange år med å være involvert i databasenes verden, enten som administrator eller utvikler, eller etterhvert som arkitekt, og så innse at jeg kunne gjøre bedre ting for å tjene en skorpe. Men det har en tendens til å føles som om du stirrer på denne galaksen med data, og mer til i dag, når vi går fra, som du skisserte, har vi gått fra megabyte til petabyte og eksoskala i løpet av veldig kort tid, i den store tingenes ordning. Men uttrykket som jeg har i tankene mine, er at databaseindekser nå er en svart kunst, og de er egentlig ikke den typen ting som bare dødelige mennesker bør sortere på, for bedriftsøkonomiske applikasjoner og typen å formulere deg snakket bare om. Men jeg ønsket å gå gjennom en rask oversikt over den type historie jeg har hatt med databaseverdener og bringe til kontekst der vi skal trekke en konklusjon, og deretter løpe gjennom noe materiale i dag med vennene våre på IDERA, fordi jeg tror det er mye forskjellig å tenke på hvordan man får tuning av databaseytelse, og en av dem kaster tinn på tingen. For mange butikker som jeg kommer over, kommer de alltid ikke til poenget med å gjøre ytelsesinnstilling på databasesjiktet og spesielt indekssjiktet før de har kommet gjennom den harde ruten å tenke at de kan kaste en tuner på det .

Mange mennesker tar bare en stor jerntilnærming til det, i mitt sinn, og jeg har fått et bilde av The Flash her fordi hvis du noen gang har sett noen gamle filmer eller helt sikkert det siste TV-programmet med The Flash, som i Flash Gordon, den gamle karakteren, og nå som han heter "Blitsen", har han en tendens til å gå veldig, veldig raskt, og alltid går energien hans tom. Og det er dette som skjer når du kaster stort jern på databaseprestasjoner. Unødvendigvis, etter min erfaring, kan du sette høy ytelse, hardt arbeid i spillet, du kan optimalisere operativsystemene dine og stille dem inn på et bestemt punkt. Du kan sikre at du har raske, flertrinnede CPUer for å få applikasjonen til å gå raskere, du kan kaste masse RAM på det, du kan ha høye gjennomstrømningsplaner, du kan gå fra harddisker til cache-harddisker til solid tilstand, og høy ytelse lagringsarray. Og selv nå kaster folk inn ting som flash og NVMe på databasemotorene deres, og tenker at de kommer til å få denne innloggingen ganger to ytelsesgevinster. Og alltid får de litt gevinst. Men alt kommer tilbake til de samme grunnleggende tuningproblemene for ytelse. Mange nettverksforbindelser med lav latens, slik at klyngene fungerer raskt. Og av gruppering av databaseinfrastruktur, slik at du har mer enn bare en maskin som gjør alt arbeidet. Men du har en tendens til å komme tilbake til det samme grunnleggende ytelsesproblemet, og det er å lese data. Å skrive data er for det meste en ganske lineær utfordring og med mindre det er gjort ordentlig.

Og så har vi utfordringen i dagens verden: Ikke alle databaser er opprettet like. Det er databaser og sitat-på-pris "database." Og når vi tenker på databasemotorer, tenker folk ofte på de tradisjonelle, vanlige mistenkte som de var i SQL-verdenen. Vi har Oracle og Microsoft SQL Server, og det er et par rundt i open source-verdenen med MySQL, som nå eies av Oracle, men det er fremdeles åpen kildekode. Og så har vi de ikke så vanlige mistenkte, NoSQL-motorene, som fremdeles har et problem rundt indeksering og ytelsesstyring, og jeg vil ikke gå nærmere inn på dem, men det er stadig flere av disse ting dukker opp hver dag, og de ser og føles som databasemotorer fra utviklernes synspunkt og ut fra et ytelsessynspunkt, men de er veldig, veldig forskjellige dyr, og de har sin egen lille nisje i verden til å hugge ut heller ytelse i minnet eller lineær skala på disken. Men slik ser verden ut i databaseverdenen. Dette er 2016, dette er versjonen tre av kartet, av en rekke mennesker som produserer dette pågående landskapskartet over hvordan databaser ser ut, og det er her det - ikke engang en overmenneskelig databasearkitekt eller databaseadministrator kan være fornuftig av det. Bokstavelig talt hundrevis, og hundrevis, og hundrevis av forskjellige merker, modeller, produsenter av databaser, alltid SQL-kompatible. Og det interessante er at de alle kommer tilbake til den samme utfordringen. Ytelse og ytelsestuning rundt databasemotoren, og spesielt etter hvordan data indekseres.

Så la oss bare raskt dekke databaseindeksering, fordi det er et interessant tema, og du må komme nærmere inn på det med demoen, tror jeg. Men jeg tror det er ganske godtatt og standard bransjepraksis at tuning av databasens indeksytelse er der verden starter og slutter så langt som å sikre at dataene dine er tilgjengelige i et raskt og raskt format. Men hva er databaseindeksering? Hvis vi tenker på indeksering i den formen vi er vant til som hverdagslige mennesker, tenker du på en indeksside i en bok. Hvis du vil finne noe i en bok - spesielt som et leksikon, eller noe som et referansemateriell av en eller annen form - hvis du leter etter noe som denne siden, der jeg leter etter ting som temaet dammer i et leksikon. Jeg vil finne enhver henvisning til demninger, vannoppsamling og et stort oppbyggingsområde, menneskeskapt generelt. Jeg går til baksiden, jeg finner det i en alfabetisert, sortert liste, A til Å, fra venstre til høyre, og jeg finner D. Jeg finner ordet "dams", og det kan jeg se på side 16, 38, 41 er det en henvisning til dem, og så kan jeg gå til disse sidene, jeg kan skanne ned øynene mine, og jeg finner referansen til ordet "dam." Det er egentlig det samme konseptet i en database, men det er nå en rakettvitenskap på mange måter. Så mye at effektivt hver databaseadministrator jeg noensinne har blitt kjent med, anser indekser som det mest kritiske verktøyet for ytelsestuning i en hvilken som helst databaseverden, uavhengig av hva deres erfaring kan være så langt som å kaste tinn på det, eller hva tilfellet måtte være.

Generelt når vi snakker om databaseindeksering, er det en rekke vanlige tilnærminger. Og jo mer komplekse databaseindekser blir, jo mer kompleks er tilnærmingen til indekseringsdata. Men egentlig når du tenker på indekseringsdata - forestill deg at vi har en fil som har en liste med navn; de kan ikke sorteres i alfabetisk rekkefølge. La oss tenke oss at det er tjue av dem. Hvis vi skal sortere - hvis vi skal søke etter data i den listen, fra topp til bunn, og la oss si at det er en liste med navn. Hvis jeg velger et tilfeldig navn, og jeg begynner å rulle nedover listen, fra topp til bunn, i et lineært format, og det er en uordnet liste, er det to kriterier som jeg tenker på som min gjennomsnittlige søketid og min maksimale søketid - og Jeg har en skrivefeil i den andre linjen, skal være "maksimal søketid", beklager - men den gjennomsnittlige søketiden min er egentlig N pluss en, delt med to, og det er i gjennomsnitt, det tar meg femti prosent av tiden å skanne fra toppen av listen, til bunnen av listen for å finne noen tilfeldige ting i den listen. Og den andre linjen der, under lineær, skal være "maksimal søketid." Men den maksimale søketiden er i hovedsak antall elementer, og det er at hvis jeg har en liste med tjue ting, at mest mulig tid kan ta meg å søke etter noe i den databasen er å gå fra topp til bunn, som er 20 elementer i dette forenklede eksemplet. Og det er en veldig treg prosess, og det er virkelig ingen måte å ytelse innstille på. Og så er det andre typer måter å ta dataene på og opprette en indeks, som faktisk er en kort liste med pekere til hvor de faktiske dataene er, for eksempel binær, B-tre, bitmapp, hashing, gruppert og ikke-klyngete, og så er det forskjellige typer data som romlig, filtrert, XML og fulltekst.

Binær er en veldig vanlig brukt for ting der dataene egner seg til det. B-tre er sannsynligvis den mest vanlige i generell forstand, historisk sett, ved at det er en vanlig måte å strukturere en indeks til hvilken som helst form for data og tillater at loggere, valg, og innsettinger og slettinger er relativt enkle når du flytter pekere rundt referanse til pekerne, poengene. Det er andre typer, for eksempel bitmapp, der datatyper angår som om vi har et tilknyttet utvalg av en eller annen form. Hashing fungerer veldig bra for store objekter, spesielt blogger og bilder. Og du kan se at det finnes en rekke forskjellige typer vitenskapelige tilnærminger, matematiske tilnærminger, til indeksering av data. For de dødelige er de en interessant utfordring å snakke om på dette nivået. Når du snakker om det på ytelsesnivå for en databaseadministrator, blir de virkelig en rakettforsker og folk gjør grader i dem, og jeg vet at doktor Robin Bloor absolutt har gjort det, og skrevet bøker om det slik som IBM og andre store merker i løpet av de siste tiårene. Og så, - mitt syn, er at vi faktisk har gått en tid der, du en gang vet at jeg personlig ville kunne sitte foran et system, og jeg ville være i stand til å trekke det fra hverandre, og vise deg nøyaktig hvor ytelsesproblemene befant seg på en kommandolinje eller ved et grafisk startverktøy for brukergrensesnitt, og begynn å fordype deg i dataene og fortelle deg hvor problemene var, og bygge indekser, eller underindekser, eller primære og sekundære indekser i det data og begynne å bruke dem til å finne ting. Men når du tenker på det landskapet jeg viste deg, der vi har hundrevis og hundrevis av merker, merker og modeller, og produsenter og typer databaser, er vi vel og virkelig forbi den tiden nå, der et menneske kan lage følelse av hvilke typer databasemotorer vi har. Spesielt, selv om vi bare kommer tilbake til slike som Oracle, er dominerende merker i disse dager i relasjonsdatabaseplattformer.

Antall databaser de har å gjøre med enten fra en egen plattform som et ERP- eller HR- eller økonomisystem, eller om de er en hjemmebakt plattform av forskjellige grunner, antall databaser og databasetabeller og poster som vi ender opp å håndtere er bare astronomiske, og du kan fysisk ikke gjøre det for hånd. Og vi har hatt en ekstra komplikasjon nå, der en gang i blant en databaseserver bare kan sitte under skrivebordet ditt. Som en liten gutt etter skoletid, pleide jeg å jobbe med databaseprogramvare på, opprinnelig Apple IIes og deretter DOS PC-baserte systemer, som dBase II, dBase III, gjennomgikk en epoke med mainframes og mid- rekkevidde og til og med VAX-er og PDP-er og loggfil på den. Og lignende av Saber, og så til slutt når noen av SQL-databasene fulgte med. Men i disse dager når vi tenker på databasemotorer, ser de ut som nederst i venstre hjørne. En databaseserver er ikke bare en maskin som sitter på gulvet under et skrivebord lenger; det er hundrevis av maskiner som kjører kopier av databasemotorer og klynger, og de skalerer opp til hundrevis og hundrevis av terabyte med data, om ikke petabyte med data, som er tusenvis av terabyte. Og til og med til det ekstreme, som doktor Robin Bloor nevnte, at noen spesifikke brukssaker - flyselskaper, spesielt offentlige etater - kan komme til eksabyte. De er fortsatt ganske nisje-y, men hundrevis av terabyte og til og med dusinvis av petabyte er ikke uvanlig lenger, spesielt fra dotcom-boom til nå, slags det vi kaller web 2.0-selskaper, som Facebook, Google, Yahoo og så videre.

Vi har også komplikasjonen nå som ting går over til ekstern tjeneste. Vi har infrastrukturplattform og programvare som en tjenestetilnærming som gir infrastruktur. Og spesielt plattformtjenester der vi ikke bare kan kjøpe for Oracle og deres skyplattform, databaser og servere. Og dette gjør at vi kan gjøre en veldig rask utvikling av applikasjonen og bare koble en database tilbake til serverne. Vi trenger ikke å tenke på hva som er under panseret. Ulempen er at vi ofte ikke tenker på hvordan vi designer og implementerer databasen igjen før den begynner å skade og ytelse blir et problem, og så ender vi opp med å måtte se etter det rette verktøyet for å diagnostisere hvorfor databasen vår gjør vondt og hvor ytelsesproblemene er. Og alltid bringer det det tilbake til det vanlige problemet med hvordan vi indekserte dataene og hvilke indekstyper vi har brukt for disse dataene, og som deretter bringer oss tilbake til overmenneskelig ytelseskrav. Og noen som har tilgang til de riktige systemene og de riktige verktøyene for å ytelse stille inn motorene, og begynner å finne et hett sted og se på hvor spørsmålene er, hvor dataene beveger seg, hvilke typer spørsmål, hvordan spørsmålene er strukturert, hvem som gjør spørsmålene, og om spørsmålene står i kø og må bufres. Hvilken replikasjon ser du etter?

Og så er vi vel og virkelig - etter mitt syn - på et tidspunkt der selv verdens beste databaseguruer, egentlig databasearkitektene og databaseadministratoren og ytelsesbasene, etter mitt syn trenger de veldig å starte å utnytte de riktige verktøyene for å levere optimal ytelse indeksstemming for enhver databasemotor. Fordi skalaen vi har å gjøre med og hastigheten på ting beveger seg, kan vi ganske enkelt ikke gjøre det for hånd, og å prøve å gjøre det alltid kan introdusere andre ytelsesproblemer, fordi vi kanskje ikke har erfaring i det rommet som vi prøver å løse et problem i. Og jeg tror at det er her vi skal gi Bert, og vi skal snakke om hvordan de har løst dette varierte problemet og hva slags ting verktøyet deres kan gjør det, spesielt for Oracle-verdenen. Og med det der, Bert, skal jeg overføre til deg.

Bert Scalzo: Takk. Velkommen alle sammen, jeg heter Bert Scalzo, jeg jobber for IDERA. Jeg er seniorproduktleder for noen av databaseproduktene våre. Jeg skal demonstrere noen av dem i dag. Men jeg vil snakke om indekser, fordi jeg er enig i alt som alle har sagt her, spesielt det siste lysbildet, at indeksene er så komplekse nå som du trenger et verktøy, og jeg håper å overbevise deg. Så Oracle indeksdesign, det er ikke så enkelt som det var i gamle dager. Mange mennesker vil være usikre på seg selv når de ser på alternativene, og jeg liker at dette sier at jeg trakk meg fra historien, "i disse spørsmålene, den eneste vissheten, er at ingenting er sikkert." Og det er slik jeg slags føler om indekser i disse dager, for selv om du tror at du vet at svaret fra deg bør indeksere X, Y eller Z, kan du virkelig ikke være sikker før du prøver det, fordi disse optimisatorene noen ganger oppfører seg annerledes som du forventer. Og det er mye prøving og feiling med indeksdesign. I de gamle dager var det bare to spørsmål, eller ett spørsmål hvis du trengte en indeks. Var det unikt eller var det ikke unikt? Og du har kanskje tenkt på andre ting som: "Hvor mange indekser kan jeg ha maksimalt på et enkelt bord?" Fordi for mange indekser bremser innsatsene, oppdateringene og slettene. Du har kanskje også vært i databasesystemet ditt, hatt begrensninger for hvor mange kolonner som kunne være i en flersøyleindeks, fordi det noen ganger var grenser basert på siden eller blokkstørrelsen til databasemotoren, men i virkeligheten var det ganske enkelt tilbake i de gode gamle dagene. Du indekserte det, eller ikke gjorde det. Og egentlig var alt i et B-tre. Vi kunne tillate duplikatene eller ikke, og det handlet om det. Livet var bra, livet var enkelt.

Vel i dag, livet er ikke så bra eller så enkelt. Jeg har lagt det røde Ghostbuster-skiltet slik vi pleide å gjøre det, for nå har vi B-tre kontra bitmapp, kontra bitmapp bli med. Og jeg skal forklare hva noen av disse er i løpet av et øyeblikk. Clustered og ikke-gruppert, unik eller duplikater, fremover eller omvendt rekkefølge, funksjonsbasert, partisjonert eller ikke partisjonert. Hvis det er partisjonering involvert, er det global eller lokal partisjonering? Det skal jeg også forklare. Og så er det også noe som heter et indeksert organisert bord. Og det er faktisk et halvt dusin andre som jeg har sluttet med her, for jeg tror jeg har fått nok her nå som burde overbevise deg om at indekser er mye tøffere enn du kanskje trodde. I dette lysbildet skal jeg starte øverst til venstre på diagrammet, og jeg har et bord. Og det første jeg må bestemme meg er, avhengig av databaseversjon og databaseleverandør, tillater de objekttabeller eller er de bare relasjonelle? Jeg kommer til å gå til høyre og si at vi bygger et forholdstabell. Nå, det neste spørsmålet jeg må stille meg er, er det i en klynge? Og mange av dere som har gjort Oracle i noen tid, vil huske at klynger var tilbake i Oracle 6 dager. De er sannsynligvis ikke veldig sterkt brukt lenger i dag, men la meg gå ned den grenen først.

Hvis jeg skulle legge bordet mitt i en klynge, måtte jeg ha en gruppert indeks på det bordet. Nå, i Oracle, da du gruppert et bord, lagret du i utgangspunktet radene, eller radene var i nærheten av hverandre der verdiene var like. Og så må du ha en klynget indeks, og den klyngede indeksen kan være ikke-partisjonert. Med andre ord var det egentlig ikke noen partisjonsmetoder for hvordan du ville gjøre et gruppert bord. Det var strengt tatt ikke delt opp. Og fordi den ikke var delt opp, var den global. Jeg vil forklare hva det globale er om et øyeblikk. Og det var alltid B-tre. Med andre ord, da jeg gikk ned den grenen, var det ganske enkelt, jeg hadde ikke mange valg. Hvis jeg nå gjorde en ikke-klynget indeks på et gruppert bord, som var tillatt i noen versjoner, var det igjen ikke-partisjonert; når den ikke er partisjonert, er det eneste valget ditt globalt. Og så, der har du valget mellom B-tre eller bitmapp. Igjen, det var avhengig av din versjon av databasen. Men nå, la oss gå tilbake til det relasjonelle bordet og begynne å gå ned på høyre side igjen, og nå skal vi bare ha et vanlig, gammelt, vanlig, heapet bord: relasjonelt. Det kommer til å være på et bordplass. Jeg går litt ned på høyre side her først. Så det er organisering, heap. Det neste spørsmålet jeg må stille meg er, "Vil jeg dele denne tabellen eller gjør jeg det ikke?" Nå, noen ganger vil du partisjonere fordi du tenkte: "Hei, optimisatoren vil være smartere om hvordan den kan optimalisere spørsmål. ”Men mange DBA-er vil fortelle deg at grunnen til at du gjør det er av administrative formål. Hvis du har et bord på hundre milliarder rad, hvis du deler det opp i partisjoner eller bøtter, når du vil legge til data i den siste bøtta, kan du slippe og indeksere det er bare noen få millioner rader. Du kan sette inn dataene og så kan du gjenopprette den indeksen på akkurat den bøtta.

Selv om det var en god teknikk for noen, optimaliseringsteknikker som eliminering av partisjoner, var dens virkelige verdi å kunne administrere eller utføre administrative oppgaver på mindre deler. Når jeg går til organisasjonshaugen, var det første spørsmålet: "Delte jeg det opp eller ikke?" La oss gå til venstre, jeg skal ikke dele opp bordet. Nå kan det virke rart når jeg forteller deg dette, men du kan ha et ikke-partisjonert bord, og da kan du ikke partisjonere indeksen som du er vant til, eller du kan dele indeksen. Stopp og tenk. Bordet ditt har i utgangspunktet en bøtte, som du alltid har trodd, og likevel vil indeksen ha flere bøtter. Når det skjer, der det er et misforhold mellom antall bøtter og bord, og antall bøtter i indeksen, er det hva som menes med global. Og hvis tabellen ikke er partisjonert, og hvis indeksen er partisjonert, blir den ansett som global, fordi det er et misforhold. La meg nå gå tilbake på organisasjonshaugen min og komme ned i stedet på partisjonssiden. Nå, hvis jeg har et partisjonstabell, og la oss si at tabellen har fire bøtter, fire partisjoner, kan indeksen ha fire bøtter, slik at indeksen min samsvarer med mitt borddesign. Og så er det over, på vei til høyre. Det vil bli vurdert som lokalt. En lokal indeks betyr i utgangspunktet at inndelingen av tabellen og indeksen gjøres på samme måte og har samme antall bøtter. Og så når jeg har den lokale indeksen, kan det være et B-tre eller et bitmappe, og den grønne pilen den slags går opp, viser deg at selv om det er et B-tre, er det fremdeles valg som kan tas. Det kan være funksjonsbasert. Og også, hvis det er et bitmap, er det forskjellige typer bitmaps. Det er noe som kalles en bitmap join index. Hvis du driver med datavarehus, er det en veldig populær type indeks for stjerneskjema eller design. Det som skjer er at indeksen har rad-ID-ene for hva den peker på i tabellen, men den vil også ha rad-ID-er for overordnede tabeller, slik at når du er - du må stjerneskjema design og du ser ved en faktatabell, peker indeksen på faktatabellen deg på dataene du er interessert i, og peker deg på hver rad i dimensjonene dine, slik at du bare trenger å ha en indeks.

Og faktisk ble dette til på grunn av Red Brick, som var en database for mange år siden - mange husker kanskje det. Og så, hvis du ser på dette bildet - og husk at jeg ikke la alt i dette bildet fordi bildet ville være mye større - er det fortsatt flere problemer, som jeg har i teksten her øverst til høyre . Er det en omvendt ordreindeks? Og du kan si: "Hvorfor vil jeg ønske en omvendt ordreindeks? Det gir ingen som helst mening. "Vel, hvis du er i et klynget miljø i Oracle, hvis du gjør ekte applikasjonsklynger, hvis du holder indeksene i orden, så ikke reversert, hvis du har mye behandling som treffer de samme verdiene eller de samme indeksverdiene. Det som ville skje er at du har varme områder av B-treet. Betyr at du ville ha strid og muligens låse for å prøve å få tilgang til det, og det vil du gjøre på tvers av noder i et nettverk. Vel, hvis du legger inn en omvendt ordreindeks, kan du nå angre det. Du kan si, "Vel, de samme verdiene er i forskjellige deler av trærne, så jeg har ikke mine separate noder som konkurrerer om varme områder i treet." Og legg også merke til at det unike ikke fungerer med noen av alternativene. . Hvis du ser, har jeg nummer tre, fem, åtte og elleve, så det er noen tilfeller der jeg ikke kan ha en unik indeks. På samme måte er det noen tilfeller der jeg ikke kan ha en omvendt indeks, og så er det flere problemer som logging eller ingen logging, og parallell og ikke-parallell. Jeg kan tilordne ting til et bestemt område i minnet.

Og dette etterlater fortsatt ganske mange funksjoner i Oracle. Jeg vil si at når du ser på Oracle 12, er det sannsynligvis igjen omtrent et halvt dusin ting jeg kan legge til dette bildet. Indeksering er veldig kompleks, og jeg er veldig enig med foredragsholderen, for å navigere gjennom dette og gjøre et godt valg, trenger du et verktøy. Du trenger kanskje et bilde som dette, og en slags metodikk for hvordan du kan velge ting, og forhåpentligvis vil verktøyet hjelpe deg med å komme dit. Og da kommer det til å være prøving og feiling. Jeg forteller alltid folk om indeksering, "se før du hopper." Og så kan du se den lille hunden her, han hopper uten å se, han kommer til å havne i vann med haien, eller fyren gjør seg klar til å hoppe i vannet, og han skal impale seg selv. Du må tenke på indekseringen din, fordi det å lage en indeks ikke alltid betyr at ting blir bedre. Å lage en indeks kan faktisk bremse ting. Og spørringsytelse kan være en størrelsesorden bedre med ett valg fremfor et annet. Og jeg vil gi deg et godt eksempel. Hvis du gjør et stjerneskjema for design, og på dimensjonstabellene dine bruker du bitmap-indekser i ett tilfelle, og i et annet tilfelle sier du: "Jeg vil bruke B-tree-indekser, " har du bitmap versus B- tre. Jeg kan fortelle deg at den ene løsningen vil være en størrelsesorden eller muligens flere størrelsesordener raskere enn den andre. Men husk hva som fungerer i ett miljø, som i et datalagermiljø, sannsynligvis ikke er et godt valg i et OLTP-miljø.

For eksempel, hvis du skulle ta et transaksjonstabell og legge bitmap-indekser på et transaksjonsbord, er det dyrt å beregne og tilbakestille bitmapper, disse lange strengene, og så i en OLTP-tabell, kan du slå i tabellen så tungt at bitmappen indeksen kan bli korrupt og bremse systemet ditt fordi de bare ikke er ment for oppdateringer. De er flotte for rask tilgang, men er ikke bra for oppdateringer. Jeg tror indeks tar prøving og feiling. Det er virkelig ingen gylden regel lenger - det er for mange forskjellige variabler i denne ligningen til å vite - og til slutt må du se på utførelse eller forklare planer i databasen din for å se om du tar gode valg eller ikke. Og noen ganger kan plananalysen nesten være en vitenskap for seg selv. Jeg skal ikke dekke det i dag - det er et annet tema - men ikke ta indeksdesign for gitt. Det er legitime grunner til at det er alle disse vanvittige indekstypene jeg viste deg, på det forrige bildet, og som den forrige foredragsholderen snakket om. Disse ble ikke bare opprettet fordi det var en fin funksjon å sette på en sjekkliste et sted for en databaseleverandør; det er brukssaker eller scenarier der disse indeksene er viktige og vil utgjøre en betydelig forskjell. Nå med det skal jeg vise deg noen eksempler på forskjellige typer indekser i et av verktøyene våre. La meg bare få skjermen opp slik at du kan se den. OK, så her sitter jeg inne i - la meg minimere denne applikasjonen. Jeg sitter inne i VMware og kjører en Windows Server 2012 VM.

Og du kan se, jeg har omtrent hvert verktøy kjent for mennesker. Som produktsjef må jeg holde meg klar over konkurransen min, så det er ikke bare hvilke verktøy jeg har, men hva gjør konkurrentene mine? Og vi har fått dette verktøyet her kalt DBwartan, som jeg allerede har kjørt, men jeg skal - så jeg vil bare ta det opp. Og det du kan se er at dette er et veldig fint verktøy, for i stedet for å måtte bruke, sier en bedriftsleder for Oracle og et SQL Management Studio for SQL Server, og MySQL Workbench for MySQL, og tolv andre databaser som vi støtter, Vel, jeg har alle databasene mine innebygd i dette verktøyet. Det er DB2, det er MySQL, Oracle, Postgres, SQL Server og Sybase, og det er - jeg har bare seks databaser i denne spesielle tingen fordi jeg ikke kan - verktøyet støtter tolv databaser, men min stakkars VM, som kjører seks databaser samtidig, og prøver å gjøre en demo, handler omtrent så mye som maskinvaren min vil gjøre det lettere. Så la meg gå tilbake til Oracle nå, og hvis du legger merke til, er alle disse tingene de samme. Hvis jeg vil måle ytelsen min i DB2, er det de samme valgene jeg ville tatt i Oracle. Nå under dekslene gjør vi mange forskjellige ting slik at du ikke trenger å vite hva som skjer, men vi gir deg et jevnlig grensesnitt slik at du kan være en ekspert med flere databaseplattformer. Og det vil omfatte arbeid med indekser, temaet for denne diskusjonen.

La meg komme inn hit og la meg først begynne med å se på noen tabeller, så har jeg en filmdatabase som bare har noen få tabeller. Og hvis jeg ser på et bestemt bord, som kundetabellen, når jeg tar det opp hit, kan jeg se borddesignet mitt, her er kolonnene mine i tabellen, og her er informasjon om hver kolonne. Jeg har egenskaper for tabellen, men merk at jeg har en fane her for indekser, og jeg kan se at her er indeksene på bordet. Legg merke til at en av disse indeksene er min PK-indeks, min primære nøkkel. Disse andre ser ut til å være bare indekser for å forbedre tilgangen til spørsmålet, kanskje vi spør etter fornavn eller etternavn, eller vi ser på telefoner og postnummer. Og hvis jeg velger en bestemt indeks, som denne postnummeret her, og jeg dobbeltklikker på den, nå kan jeg se at hei, det er en ikke-unik indeks, og her er noen av de andre typene, bitmap, ikke-unike, unikt, enten det er sortert eller ikke, om det logger eller ikke, om det er omvendt rekkefølge eller ikke, om det er en funksjonsbase. Åh, her er en morsom jeg ikke dekket. Du kan faktisk ha usynlige indekser. Og du vil si: "Vel, hvorfor pokker skulle jeg ønske å gjøre en usynlig indeks?" Vel, jeg vil gi deg et godt eksempel. Du er i produksjonssystemet ditt, og du har et ytelsesproblem, og du er ikke sikker på at oppretting av indeksen vil løse problemet, slik at du ikke vil opprette indeksen og bremse produksjonen, men på en eller annen måte vil du kunne teste det. Du kan opprette indeksen i produksjonen som usynlig, noe som betyr at ikke mange applikasjonskoder, kaller optimisatoren, vil bruke den indeksen. Den er opprettet, den er gyldig, men den vil ikke bli brukt. Så kan du ta et spørsmål som du tror at denne indeksen vil hjelpe med, eller en serie spørsmål, og du kan holde et hint i og si: "Hei, optimizer, det er en usynlig indeks der ute. Jeg vil at du skal bruke og la meg vet om jeg har gjort ting bedre. ”Og nå har jeg testet noe i produksjonen, men jeg har ikke ødelagt applikasjonene i produksjonen som kjørte. Det er bruken for en usynlig indeks. Det høres stum ut når du først hører om det, men det har bruk.

Vi kan også på indekser definere om de er parallelle, og også hvor mange forekomster de er parallelle på tvers. Nå, i et ikke-gruppert eller et ikke-ekte applikasjonsmiljø, så ikke-rack, vil parallell bety hvor mange delprosesser som spørsmålet mitt kan lage for å prøve, og arbeiderprosesser, for å prøve å få ting gjennom raskere eller raskere . Og parallelle tilfeller vil være at hvis jeg er i en virkelig applikasjonsklynge, sier at jeg har ti noder, hvor mange av noder får jeg lov til å dele arbeidet på tvers? Kanskje er det fire av de ti, og på hver av dem, fire delprosesser. Det er et eksempel. Og så har vi nøkkelkomprimering. Du kan faktisk komprimere indekser? Ja eller nei. Og så har du selvfølgelig lagringsparametere som du kan spesifisere på indekser. Nå dekket jeg ikke disse fordi de egentlig er mer en lagringsparameter enn et indeksproblem. Og så til slutt, har vi om vi skal gjøre disse partisjonerte eller ikke-partisjonerte. La meg slippe det her et øyeblikk. Jeg skal til et annet skjema. Dette er et stjerneskjema, og for eksempel er dette periodetabellen et dimensjonstabell. Hvis du noen gang har gjort stjerneskjema-design, har du vanligvis en dimensjon for tid, og i denne databasen og dette stjerneskjemaet, er periode en tidsdimensjon. Nå, jeg vet at det vil se morsomt ut, du vil si: "Gee, se på alle kolonnene - har fyren noen gang hørt om normalisering?" Vel, når du er i et datavarehus eller et stjerneskjema design, har vanligvis ikke - du har tabeller som en typisk person vil se på og si: "Tja, disse er ikke veldig bra designet." Men det er slik du gjør det i et datalagermiljø.

Nå, se hva som kommer til å skje fordi, ok, det er alle disse kolonnene, se på det, jeg har en indeks på hver eneste kolonne. Nå, i et OLTP-miljø som vil være et nei-nei. Det ville redusere alle operasjonene mine. I et datalagermiljø ville jeg slippe dem i løpet av batch-belastningssyklusene mine. Last uten overhead eller indeksene, og jeg vil gjenskape indeksene. Og hvis jeg partisjonerte tabellen min, så i stedet for å måtte slippe indeksen for hver bøtte i tabellen, kunne jeg bare slippe indeksen på bøtta eller bøttene der data skulle gå inn i løpet av den batchbelastningssyklusen. Og gjenskape bare indeksdelen for disse bøttene. Og så det gjør det veldig håndterbart. Og hvis jeg ser på - så her er en kolonne kalt "Ferieflagg" og i utgangspunktet er det et ja eller nei. Legg merke til at dette er en bitmap-indeks, og for de fleste av dere vil du si: “Vel, det er fornuftig.” Ja eller nei, Y eller N, det er bare to verdier som er fornuftige. Og fordi når du leser dokumentasjonen for bitmap-indekser, forteller de deg alltid at du velger noe med lav kardinalitet.

La meg nå gå inn på et av faktabordene mine, så her har vi ordrene mine. Og dette er bestillinger per dag. Og du skal se nå, at igjen har jeg ganske mange kolonner, og igjen, jeg kommer til å ha mer enn noen få indekser. Og akkurat her har vi noe som heter den universelle priskoden. Dette var for en butikk, så du kjenner de små strekkodene når du kjøper noe i butikken, dette er den universelle priskoden. Nå er det millioner av universelle priskoder. Nå, for dette bestemte selskapet som solgte ting, hadde de sannsynligvis 1, 7 til 2 millioner universelle priskoder, så du kommer til å forvente at dette ikke kommer til å bli en bitmap-indeks fordi 1, 7 millioner distinkte verdier høres ut som høy kardinalitet. Men i virkeligheten, i et datalagermiljø, vil du at dette skal være et bitmap. La meg forklare hvorfor. Det kan være 1, 7 millioner distinkte verdier for denne universelle priskoden, antall rader i denne ordretabellen er i hundrevis av millioner til milliarder rader. Indeksen min er lav kardinalitet sammenlignet med tabellens størrelse eller kardinalitet. Det gjør at det blir lav kardinalitet. Det gjør bitmap-indeksen nyttig, selv om den er intuitiv med 1, 7 millioner distinkte verdier som du ville valgt bitmap her. Hvis jeg nå visste at jeg ønsket å bruke en bitmap join index, for øyeblikket støtter ikke produktet det, får jeg det til for neste utgivelse, men det vil være et annet alternativ her. Og i et stjerneskjema, husk at bitmap-indeksen ville være på faktabordet, og at den ene indeksen i B-treet skulle peke på raden i faktatabellen og deretter til hver rad som var tydelig i dimensjonstabellen for det faktum . Og så har du et annet alternativ der. Og så, la oss se, jeg vil komme ut av bordene nå, og jeg vil bare vise dere raskt at jeg har den samme informasjonen, under indekser, og jeg skal gjøre den samme grunnleggende tingen.

Grunnen til at jeg tok opp dette er at du kanskje legger merke til, hei, det er ingen primære nøkler her. Primære nøkler utføres med en nøkkelbegrensning, så de dekkes faktisk av begrensningsdefinisjonene. Dette ville være indekser som ikke er en del av begrensningen. Nå kan du kanskje si: "Vel, vent litt, det kan se ut som en fremmed nøkkel, og en fremmed nøkkel er en begrensning, " men utenlandske nøkler og de fleste databaser oppretter ikke automatisk en indeks i den utenlandske nøkkelkolonnen, selv om det er tilrådelig, og der du går - jeg har alle de samme valgene igjen. Og hvis jeg vil endre for bare å bli komprimert, kan jeg gjøre det.

Nå fungerer kompresjon bare på en B-treindeks. Det som tillater det er, når du ser på de forskjellige nodene i B-treet, gir det mulighet for komprimering av noen av verdiene. Det er virkelig ikke komprimering som tabellkomprimering, det er en komprimering av hva som er lagret i B-treet i ikke-bladknutene. Det sparer ikke massevis av plass, men det kan utgjøre en forskjell. Og med det merket jeg at jeg kommer ganske nær tid, så det jeg vil gjøre er at jeg vil gå tilbake og slutte å dele. Og vi har vårt produkt der ute for en fjorten dager lang prøve på idera.com. Det er et ganske bra produkt, spesielt hvis du jobber med flere databaseplattformer. Hvis du jobber med to eller tre forskjellige databaser, vil dette verktøyet gjøre livet ditt mye enklere. Vi har verktøy som hjelper deg med indeksdesign og valg, vi har et verktøy som heter DB Optimizer. Jeg kunne ikke dekke det i dag, det ville være for mye. Hvis du vil kontakte meg, så er det min e-postadresse, det er, eller du kan hente meg på min private e-post, og jeg har blogger, jeg har et nettsted og blogger, og en LinkedIn-profil der. Så ta gjerne kontakt med meg om hva som helst, selv om det ikke er produktrelatert, hvis du bare vil snakke databaser, er jeg en nørd i hjertet og jeg elsker å gab om technobabble.

Eric Kavanagh: OK, vel, Dez, Robin, jeg er sikker på at dere har minst et par spørsmål, vi har noen minutter igjen her. Desember, hva tror du?

Dez Blanchfield: Jeg har et stort spørsmål jeg må stille deg, det har sittet bakerst i tankene mine. Hva er det sprøeste scenariet du har sett? Jeg har lest bloggen din, jeg følger deg nøye, den du er sannsynligvis en av få mennesker som har bodd i nesten alle usannsynlige, og jeg tror Dr. Robin Bloor er det andre jeg har møtt i min levetid. Men, du vet, du har sikkert sett alle vanvittige scenarier, hva er noen av de galeste scenariene du har sett, at du har kommet over, og som mennesker som bare ikke orket, har du klart å gå og utføre Jedi-tanketriks med hele DBarusan?

Bert Scalzo: Vi hadde en kunde en gang som i databasedesignen de tenkte veldig mye på hva de ville tenke i et filoppsett, og så, det - når du normaliserer en database, det første du prøver å gjøre er å bli kvitt av gjentagende grupper. Vel, de hadde en kolonne, og de laget den til en lang, eller en BLOB eller CLOB, og i den ville de sette verdi, nummer én, semikolon, verdi nummer to, semikolon, verdi nummer, semikolon, og de ville ha tusenvis av verdier der inne, men de trengte å søke i den kolonnen, og de er som, "Hvorfor kjører denne tingen så tregt?" Og jeg er som, "Vel, du kan ikke lage en indeks på hva du gjorde, det er bare ikke tillatt. ”Så vi viste dem faktisk, ved å bruke planene, at det de trengte å gjøre var å normalisere tabellen. Ikke fordi normalisering er noen akademiske øvelser som gjør ting bedre, men fordi de ønsket en spørring på det feltet, noe som betydde at de ønsket å kunne indeksere det, og du kunne ikke indeksere det på en gjentagende gruppe, eller i det minste ikke lett . Og så det er sannsynligvis det verste jeg noensinne har sett.

Dez Blanchfield: Ja, det er interessant hvor ofte du kommer over, jeg tror utfordringen med databaser, folk glemmer at det er en vitenskap. Og det er folk som gjør grader og doktorgrader i hele dette rommet, skriver papirer om det, og du har skrevet en hel swag inkludert TOAD-håndbøkene og andre ting fra minnet. Trenden mot slags "store data" sitat-på-pris-nå-jeg ser mange mennesker glemme grunnleggende grunnlag for databasearkitektur og databaseteknologi, databasevitenskap, om du vil. Hva ser du ute på feltet så langt som skiftet fra tradisjonelle databaseplattformer og tradisjonelle databasetanker som vi effektivt spikret til bakken, og det var bare et tilfelle av ytelsestuning og skalering. Ser du at mange mennesker lærer seg på nytt og har en opplevelse der de bare sitter der og har et "a-ha" -øyeblikk, som et eureka-øyeblikk, der de innser at disse big data-tingene faktisk bare er slags store databaser? Er det noe der ute, og folk svarer deg tilbake og slags: "Vi har glemt, hva vi visste, og kan du bringe oss tilbake fra den mørke siden?"

Bert Scalzo: Vel, nei, og dette er fryktelig å måtte innrømme, men de relasjonsdatabaseleverandørene har drukket den Kool-Aid også. Hvis du husker, jeg vet ikke, for et tiår siden begynte vi å legge ustrukturerte data inn i relasjonsdatabaser, noe som var en merkelig ting å gjøre, og deretter legger dataene, de relasjonsdatabaser, til NoSQL-typen ting. Faktisk, i Oracle 12, CR2 - jeg vet at den ikke er ute ennå - men hvis du ser på betaen, hvis du er i beta-programmet, støtter det skjæring. Og så, nå har du en relasjonsdatabase som ikke har lagt til konseptet fra NoSQL-avskjerming. Og så, "a-ha" -øyeblikket ser ut til å være mer for menneskene på den relasjonelle siden som går "a-ha." Ingen kommer til å gjøre det riktig igjen, ikke engang databasesjefene, så vi har måtte gå over og bli med på den mørke siden.

Dez Blanchfield: Helt riktig, så du sier et skifte til mye rotete data, hvis jeg forstår riktig, blir lagt inn i det vi nå kaller big data-plattformer, som er litt morsomt, fordi de er ikke så gammel, men betyr det ikke da at de fokuserer på det de gjør med sin relasjonsdatabase for å få mer smell for pengene?

Bert Scalzo: Nei, vanligvis, hvis de har et behov i det - det ville vært et sitat av "big data-type need", finner de ut at i stedet for å måtte gå til den andre databaseplattformen og gjøre noe i et ikke -relasjonell måte, databaseleverandørene gir nå dem de samme ikke-relasjonelle teknikkene i sin relasjonsdatabase, for å gjøre disse tingene. Jeg mener, et godt eksempel vil være, hvis du har ustrukturerte data, som en JSON-datatype eller annen kompleks datatype som har betydning innebygd i selve dataen, støtter databaseleverandørene ikke bare det, men de vil gi deg SUR samsvar med ustrukturerte data. De relasjonsdatabaser har omfavnet de nyere teknikkene og teknologiene, og igjen, "a-ha" ser ut til å være mer ikke, "Hei vi, applikasjonsutviklerne, har avlært noe og vi trenger å lære det igjen, " det er "Hei, vi gjør det på denne måten nå, hvordan kan jeg gjøre det på den måten i din tradisjonelle relasjonsdatabase og gjøre det som jeg gjør i denne databasen her over? ”og det blir mer utbredt, og som sagt, databaseleverandørene gjør det mulig at.

Dez Blanchfield: Ikke sant, hvem er de tradisjonelle mistenkte på dette rommet for verktøyet DBwartan og det? Jeg gjorde noen lekser om det du nylig hadde skrevet, og fra minnet til at du hadde skrevet noe, tror jeg det var en av bloggene dine, om ekstrem databaseytelse i Oracle-verdenen. Jeg kan ikke huske når det var, jeg tror det var en gang i år fra minnet, eller fra sent i fjor, du hadde skrevet denne tingen. Og det syntes for meg at det var den tradisjonelle, vanlige mistenkte for den type tema vi snakker om i dag, der folk vil gå til veldig storskala databasemiljø og lete etter det du kaller ekstreme gevinster i det. Hvem er de vanlige mistenkte at du ser der ute som tar opp DBwartan og bruker den til god bruk?

Bert Scalzo: Vel, vi har mange kunder, faktisk, i dag var jeg sammen med et veldig stort myndighetsorgan som - og de har bokstavelig talt nesten 1000 eksemplarer av programvaren vår, fordi den lar folk fokusere på det de har gjør det, og ikke hvordan du gjør det. Og det er greit, jeg mener, alle burde vite hvordan de skal gjøre noe, men produktiviteten er å få til det “hva”. Hvis virksomheten ber meg om å gjøre en oppgave, er det alt de er interessert i. Når fikk jeg et hake for å si når oppgaven ble gjort? Ikke hvilken teknikk eller hvilken teknikk som jeg brukte for å komme dit. Og så lar verktøyet dem fokusere på hva, og lar dem være langt mer produktive, og det er virkelig den enorme fordelen, og som sagt, noen databaser tilbyr et verktøy bare for databaseplattformen deres. Vi tilbyr det for tolv databaseplattformer. Jeg har den samme arbeidsflyten, det samme grafiske brukergrensesnittet, de samme navigasjonene. Hvis du vet hvordan du gir en bruker et privilegium eller hvordan du oppretter en tabell eller oppretter en indeks i en database, kan du gjøre det i alle tolv fordi det er samme utseende og samme arbeidsflyt. Det har stor verdi for kundene våre.

Dez Blanchfield: Ja, jeg antar at folk vil ha mye mer smell for pengene sine fra menneskelige ressurser. Og dagene med å ha en individuell spesialist i Oracle, Ingres og DB2 er alle borte. Det forventes at folk skal være Jack for alle bransjer, så jeg tror at denne tingen absolutt har reddet livene deres.

Bare en siste kjappe ting før jeg overlater den til doktor Robin Bloor. Du nevnte at det er en gratis nedlasting i fjorten dager, hva gjør - hvis jeg skal gå foran og jeg skal gjøre det, forresten, skal jeg legge det i Bloor tech lab og snurre denne tingen opp og få tak i det selv - jeg hadde ikke hatt en sjanse til å gjøre det før i dag. Du nevnte en prøve på fjorten dager, du sa at du kjører den på en VM på datamaskinen din. Jeg antar at det er en bærbar datamaskin. Hva er, hvordan er oppsettet på noen nivå for noen å få hånden på og bruke den fjorten dager lange prøveperioden, like før jeg gir tilbake til Robin til spørsmålene hans?

Bert Scalzo: Alle Windows-miljøer, så Windows 7, virtuell maskin med en prosessor og fire spillejobber. Vi er ikke et veldig fett eller dyrt verktøy. Hvis du nå ville kjøre databaseserveren på samme VM under samme Windows, ja, må du legge til mer, men hvis du kjører databasen på en databaseserver eller på en egen VM, skal VM lastes inn og kjører produktet vårt er veldig lett: en prosessor, fire spillejobber, omtrent hvilken som helst versjon av Windows - og vi støtter både trettito og fire og sekstifire-bit installasjoner. Men du må installere databaseleverandørens klient. Så hvis du ønsket å koble til Oracle, må du installere SQL-nettklienten, fordi det er det Oracle krever for at du skal kunne snakke med en database.

Dez Blanchfield: Det høres ganske greit ut. Jeg tror at en ting av dette mer enn noe jeg håper at folk kommer til å ta bort, annet enn erkjennelsen av at dette verktøyet kommer til å redde livene deres, er at de skal gå og laste ned det og leke med det, gitt at du tilbyr en fjorten dager lang prøveperiode. Og den kan kjøres på deres nåværende bærbare datamaskin uten å installere noe ekstra, fordi hvis de allerede gjør databaseadministrasjon, jobber de allerede med databaser, de har alle verktøyene på plass og om de kjører på en lokal VM eller på deres lokalt skrivebord, høres det ut som det er smertefritt å installere og spille med. Så jeg anbefaler folk å gjøre det.

Robin, jeg er sikker på at du har spørsmål og Eric, du har sikkert fått noen fra publikum, så Robin, hva med å gi meg videre til deg og så tilbake til Eric?

Robin Bloor: Ja, greit nok, jeg har ting å si, jeg mener, jeg har alltid funnet dette området fascinerende fordi det var - jeg klippet tennene på det. Men sannheten er at antagelig siden om lag 1998, 1999, har jeg brukt hva Oracle faktisk er i stand til. Og jeg kjente Sybase og Microsoft SQL Server, begge disse er ganske enkle sammenlignet med hva Oracle kunne gjøre. Du fikk meg til å le når du - jeg mener, jeg dekket til munnen min, da du begynte å snakke om skjæring. Oracle gjorde dette før. Oracle introduserte på et eller annet tidspunkt, de ble nervøse for den objektrelasjonelle ideen, så de introduserte muligheten til å lage en slags objektnotasjon og objektlagring i Oracle, og jeg snakket med en av ingeniørene deres, noe som et par år etter at de introduserte det, og jeg spurte hvor mange som brukte det, og han sa at jeg tror to kunder hadde prøvd det, og det var det. Og jeg tror at det samme kommer til å skje hvis de begynner å prøve og gjøre trolige NoSQL-ting. Jeg tror det er en feil, jeg mener, jeg er interessert i hva tankene dine er. Helt klart - de drikker Kool-Aid. De føler seg som om de må være i stand til å komme med påstander som ligner på de store NoSQL-databasene som Cassandra, men du vet, gir det noe mening for deg?

Bert Scalzo: Nei, du har truffet spikeren rett på hodet. For meg ville jeg, hvis jeg skal gjøre relasjonelt, jeg velge en relasjonsleverandør som en Oracle eller en SQL Server eller en DB2 eller en Postgres, men hvis jeg skal gjøre noe som ikke er relasjonelt, på big data-plassen, eller NoSQL-plassen, skal jeg velge riktig verktøy for riktig jobb. Og jeg tror ikke at det naturlig ville gå til min relasjonsdatabaseleverandør først. Og så legger du den andre rynken til den, som er, hva er tilgjengelig i skyen? Så mange mennesker som ønsker å få databasene sine utenfor premisset. Så må du se på skyleverandøren din og si: “Ok, hva leverer du, hvilke databaser har du tilgjengelig for meg som passer mine behov og hvor salgbare er de, og ærlig talt hva er prisen eller prisen for å bruke den databasen i skyen per time, eller per dag. Og per gigabyte eller terabyte? ”Og det du finner er kanskje noen av de relativt nyere databasene som Mongo eller Cassandra, kanskje prisene deres er billigere, så hvis du skal gjøre store data med flere petabyte-typer, kan du må - bare fra kostnadssynspunkt - måtte ta hensyn til NoSQL-databasene i skyen fordi de kan være den mest kostnadseffektive måten å gjøre det på.

Robin Bloor: Ja, ikke sant. Jeg mener, min type - tingen om relasjonsdatabaser i min erfaring - som er lang nok til å ha arr, det er helt sikkert - det er mye sunn fornuft at hvis du begynner å bruke det og - du forstår hva relasjonelt faktisk er, at, Jeg mener, jeg husker at jeg skulle konsultere en kunde en gang, og de førte meg inn i et rom, og de hadde laget et slags enhetsdiagram og laget en tredje normal form, en modell for hvordan selskapets primære systemer var. Den hadde to hundre og førti bord om, og de sa: “Vel, hva synes du om det? Vi skal bygge en database for dette, og sa "Hva synes du om det?" Jeg sa: "Jeg tror ikke det kommer til å fungere." Og det er helt riktig, vet du, fordi de var slutt opp for å skape spesiell struktur innen elleveveis sammenføyninger. Og det er tingen å forstå om relasjonelle. Så jeg er veldig interessert i hvor mye dårlig design du møter. Jeg mener, jeg har ikke noe problem med DBwartan - det gjør veldig fornuftige ting, og det at du faktisk kan vise ut på flere plattformer, synes jeg er fantastisk - men hvor mye møter du der ute der designet er problematisk hvor folk kunne ha løst seg selv alle slags hjertesorg hvis de kom til et stjerneskjema i stedet for å snøflak om det, vet du?

Bert Scalzo: Vel, jeg vil ikke høres ut som, formuende eller arrogant, men jeg vil si oftere enn ikke. Det er klart, de fleste av databasene som jeg blir involvert i der ute, de har problemer eller problemer. Noe som er bra, fordi verktøyene våre, som vårt databaseoptimeringsverktøy, kan hjelpe dem med å løse disse problemene, og, men det som virkelig er morsomt for meg, er at mange av problemene er de samme enkle problemene om og om igjen. Jeg jobbet nettopp med en kunde forleden som hadde en elleveveis medforespørsel, og jeg er som: "OK, hvorfor brukte du ikke en med klausul?", Og de er som, "Vel, det gjorde jeg ikke vet ikke hva det er. "Og så sa jeg:" Og se på undervelgene dine her på dine korrelerte og ikke-korrelerte, "sa jeg, " I noen tilfeller har du i din hvor klausulen på det dypeste nivået, en tabellreferanse fra det ytre. ”Jeg sa:“ Det er, flytt den ut til riktig nivå, ikke legg den dypere inn enn den må være, du vil forvirre optimisatoren. ”Og med noen få par tweaks vi tok noe som gikk omtrent to timer og fikk det ned til ti minutter, og det var bare - i så fall gjorde vi ikke annet enn å forbedre SQL-en som de hadde skrevet. Jeg tror problemet er at mange universiteter og mange mennesker som lærer programmering i et ikke-akademisk miljø, de lærer det som innspilte tidsprosesser eller rekkeorienterte prosesser og relasjon er et sett orientert av natur, og så du må tenke i sett for å skrive god SQL.

Robin Bloor: Ja, jeg tror det er helt riktig. Og du må forstå, det er ting som, folk burde vite ABCs om ting som dette. Det gjør ikke noe. Du kommer ikke til å være i stand til å gjøre rasjonelle ting hvis du ikke er klar over at selv en godt designet, godt modellert database, sammenføyninger vil ta tid, og det vil ta tid. Det gjør de fordi verden aldri har funnet en måte å få dem til å gå fort. De har funnet måter å organisere dataene på slik at de går raskere enn ellers, og mye av entusiasmen jeg har å si for NoSQL-databasene er ganske enkelt at de unngår å bli med. De begynner bare å bygge databasene med den samme spredningen av data i dem, for hvis du blir med i noen av NoSQL-databasene, suger de mektig. Tror du ikke det?

Bert Scalzo: Å absolutt. Og jeg må le fordi, jeg startet langt tilbake før relasjonsdatabaser og tilbake da Ingres var RTI, Relational Technology Institute, og vi ikke hadde SQL, vi hadde pre-SQL relasjonelle språk. Jeg tror i Ingres, den gang den het Quel. Så du fikk fra disse gamle databaseparadigmer som nettverk og et høyere grafisk, eller hierarkisk, og du går gjennom de relasjonelle paradigmer etter et par tiår, og nå føles det for meg at vi går tilbake til nesten en hierarkisk igjen. Det er nesten som vi har vendt tilbake.

Robin Bloor: Ja, ikke sant. Bedre overlate deg til Eric, jeg bruker for mye tid, men har vi noen spørsmål fra publikum, Eric?

Eric Kavanagh: Vi gjør det, vi har noen få. Vi går litt lenge her, men jeg skal kaste et par på deg. Vi hadde et par spørsmål rundt de usynlige indeksene. Et spørsmål var: "Må noen bruke verktøyet ditt for å se dem?" Et annet spørsmål var: "Vel, hva om du er blind?"

Bert Scalzo: Det er bra.

Eric Kavanagh: Nysgjerrig spørsmål også, så bare FYI.

Bert Scalzo: Nei, du trenger ikke å ha verktøyene våre. Det er en Oracle-funksjon, den usynlige indeksen. I dataordboken holder Oracle bare et stykke metadata som sier: “Optimizer, ignorer denne indeksen. Det er her, men med mindre du blir fysisk instruert via et hint i, et optimizer-hint i SQL-kommandoen, ikke bruk dette. ”Og så, nei, du trenger ikke å ha verktøyene våre, og på alle måter det er en vanlig gammel indeks, du kan se den i et hvilket som helst verktøy, det er bare optimiseren som vil si: "Vi ignorerer det i vanlig spørringsbehandling." Du må rette det hvis du vil at det skal bli brukt. Det er veldig nyttig for scenariet jeg beskrev, og hvis du ville bygge en indeks i produksjonen, men ikke risikere å bryte rapportene, eller tingene som allerede kjører, men du ville teste dem, kan du gjøre det. Det er det den er mest nyttig for.

Eric Kavanagh: Det er gode ting, og da var det et annet godt spørsmål her. “Hva med noen av disse nye databasene i minnet? Hvordan endrer databaseteknologi i minnet spillet når det gjelder indeksering? "

Bert Scalzo: Gutt, vel vi - nå er det bra, jeg er glad for at noen stilte det spørsmålet, vi må ta en halv time til. Nei, minnet, det avhenger av databaseleverandøren. Nå, normalt sett er jeg det, jeg snakker ikke annet enn ros for alt det Oracle gjør fordi det er utrolig teknologien de har bygd, men når du river deg ned under dekslene og du ser på hva minnet er i Oracle, i Oracle database, det er i virkeligheten at den fremdeles holdes radlager på disk, og den vil få lastet kolonnelager i minnet, og hvis det ikke er nok minne til å holde hele tabellen, vil den gå tilbake til for delene; det vil ikke passe i minnet, for å gjøre det på rad butikk, og slik at du faktisk kan gjøre et valg mot bordet og for halve bordet bruker du en indeksering som treffer tradisjonelle rader ved bordet, og for den andre halvparten av velg den faktisk går ut og bare griper alt fra et søk i minnet, og så er det annerledes på den måten at for eksempel SQL Server implementerte det med deres Hekaton-teknologi, du vet, og SQL 2014, og det er blitt forbedret i SQL 2016, men i noen henseender, er deres en mer sann versjon av minnet, og hver implementering har fordeler og ulemper, men du må se litt under dekslene og innse. Fordi jeg hadde en kunde som sa, "Åh denne tabellens minne - jeg skal bare tegne opp alle indeksene, " og jeg er som, "Tabellen er større enn minnet du har på serveren, så på et tidspunkt må noen av spørringene treffe disken. ”

Eric Kavanagh: Det er en god beskrivelse; det er gode ting. Vel, folkens, vi kommer til å ha noen flere websendinger med disse gutta resten av året, kom tilbake når du hører om Bert er på en presentasjon fordi vi vet at han kjenner til tingene hans. Det er alltid gøy å snakke med ekspertene. Vi arkiverer alle disse webcastene for senere visning. Her er Bert's kontaktinformasjon igjen, og vi vil prøve å grave opp den lenken for nedlastingen og sende den ut også via e-post, men du kan alltid sende deg en e-post: Vi har flere web-sendinger oppført for dette året og vi holder på med utdanningen akkurat nå, så folkens, hvis det er noen temaer du virkelig vil høre om neste år, ikke vær sjenert: Ta vare, folkens, vi snakker med deg neste gang. Ha det.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved å bruke alternativene til høyre. For informasjon om hvordan vi samarbeider med bransjepartnere, klikk her.

• Profil
• nettsted