Hakemiston hulluus: kuinka välttää tietokannan kaaosta

Tekijä Techopedia Staff, 5. lokakuuta 2016

Takeaway: Isäntä Eric Kavanagh keskustelee tietokantojen indeksoinnista tohtori Robin Bloorin, Dez Blanchfieldin ja IDERAn Bert Scalzon kanssa.

Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.

Techopedian sisältökumppani

Techopedia Staff on sidoksissa Bloor-konserniin, ja heihin voidaan ottaa yhteyttä käyttämällä oikealla olevia vaihtoehtoja. Tietoja siitä, miten työskentelemme alan yhteistyökumppaneiden kanssa, napsauta tätä.

• Profiili
• Verkkosivusto

Eric Kavanagh: Hyvät naiset ja herrat, hei, tervetuloa jälleen kerran. On keskiviikko, kello neljä kohti itää, ja ne, jotka tietävät ohjelman, tietävät, mitä tämä tarkoittaa, on aika toiselle Hot Technologies -jaksolle. Todellakin. Nimeni on Eric Kavanagh, olen tämänhetkisen moderaattorisi seuraavana päivänä: "Index Insanity: Kuinka välttää tietokannan kaaosta". Tai kuten viittasin siihen viimeisessä sähköpostin räjähdyksessä, joka meni ulos, ”tietokannan vääntely”. Kuuma termi nykyään “väänteleminen”. Kaikki tekevät sen. Siellä on dia sinun todella. Ja tarpeeksi minusta.

Joten, Hot Technology -sarja on todella suunniteltu määrittelemään tietty tila, toisin kuin Briefing Room, joka on vain yksi-to-live-live-analyytikoiden tiedotustilaisuus, Hot Techille saamme kaksi analyytikkoa. Tänään siitä tulee oma lääkäri Robin Bloor ja datatieteilijä Dez Blanchfield. Ja puhumme aiheesta, joka on mielestäni todella melko vertauskuvallinen markkinoiden tämänhetkisestä tilanteesta.

Tärkeintä on, että olemme nykyään monimutkaisessa maailmassa. Todellakin, jos ajattelet viisitoista tai kaksikymmentä vuotta taaksepäin, se oli tuolloin huomattavasti erilainen maailma, etenkin tietokantatekniikan suhteen. Tietokannat olivat aikaisemmin melko yksinkertaisia. Heitä oli vain kourallinen; suurin osa heistä oli suhteellisia. Nyt meillä on koko tietokantateknologioiden kokonaisuus. Kirjaimellisesti tulokset vaihtoehdoista pöydällä kaikille, jotka haluavat rakentaa sovelluksen tai tehdä jotain datan avulla. Kaikki muuttuu ja se vaikuttaa ihmisiin, jotka yrittävät hallita näitä järjestelmiä. Keskustelemme tänään Bert Scalzon kanssa, joka on todellinen alan asiantuntija; hän on IDERA: n vanhempi tuotehallinto siitä, mitä voit tehdä saadaksesi kaiken tiedon käsiteltäväksi. Aion luovuttaa sen tohtori Robin Bloorille viedäkseni sen pois. Robin, lattia on sinun.

Robin Bloor: Okei, kiitos johdannosta. Mielestäni - koska se on kahden käden asia, uskon, että puhun vain tietokannan optimoinnista yleensä tämän Hot Tech -esityksen johdannona. Aloitin elämän - tekniikassa ja analyysissä - aloitin elämän tekemällä tätä, koska kirjoitin aiemmin artikkeleita tietokantojen ominaisuuksista DEC VAX -alustalla. Ja tästä syystä tietokannan kuluttajilla oli tapana kertoa minulle. Ja asia, jota minulle tapahtuu, on se, miksi sinulla olisi tietokanta? Tarkoitan, että noina päivinä kovin paljon ihmisiä luonut avaintiedostoja ja käyttämään niitä jonkinlaiseen indeksisekvenssivirheeseen, kuten me niitä kutsumme, vaan luoda jonkinlainen tietokantaominaisuus, ja tiedätkö, miksi sinulla olisi mitään muuta?

Ja vastauksen siihen, mielestäni Michael Stonebraker antoi parhaan vastauksen siihen, ja hän sanoi: "Tietokanta voi tietää enemmän siitä, missä tiedot ovat ja kuinka nopea saada ne, kuin mikään ohjelma voi koskaan tietää." Ja minusta se on mielenkiintoista; se on pelin luonne. Mutta vuonna 19 - hyvin vuonna 1989, jonka aloitin teknologian analysoinnissa ja tiedät, tuolloin tietokannat olivat hyvin yksinkertaisia ​​ja relaatiotietokannat olivat erittäin yksinkertaisia. Heillä oli niin vähän valmiuksia, tarkoitan, että he tietysti pystyivät tallentamaan tietoja, ja voit varmuuskopioida ja heillä oli, ne olivat ACID-yhteensopivia, mutta heillä oli todellakin erittäin heikkoja optimoijia. Itse asiassa olisi vaikea väittää, että heillä oli lainkaan optimointikykyä.

Ja myöhemmin ne vain parantuivat, mutta tiedätte, kun tietokanta ei toimi - koska nämä kengurut näyttävät tavalla tai toisella osoittavan -, voi olla hirveästi monia syitä, miksi se menee hitaasti. Ja se tuo minut asiaan: Tietokannoilla on monia toimintoja, mutta tärkein niistä on kyselyjen optimointi. Jos he eivät tekisi niin, et käyttäisi niitä. Kyse on tiedon nopeaan hankkimisesta, sen tekemisestä, kun käyttäjiä on paljon samanaikaisesti, ja se on vaikea ongelma. Ja kun tarkastellaan tosiasiallisesti, kutsutaan niitä kypsiksi tietokannoiksi, jos haluat - mutta varmasti Oracle, hiukan vähäisemmässä määrin Microsoft SQL Server, varmasti Teradata ja DB2 - joiden tietokantojen optimoijat ovat saaneet, on ollut vuosikymmenien ajan rakennus. Tiedätkö, he eivät - joku ei istunut - kuusi kaveria kahden miehen vuodessa, projekti ja lyö vain yhtä yhdessä. Se ei toimi niin. Optimointikyky on vähitellen kasvanut, ja se vie paljon kasvavaa. Puhutaan joka tapauksessa tietokannan taustasta. No, NoSQL-tietokannasta sanotaan nyt hirveästi paljon, ja kuvaajatietokantaan on jopa innostunut. Ja SQL: n käyttö Hadoopin yli ja vastaavat. Mutta totuus on se, että jos haluat tietokannan heti, jos haluat täysin toimivan, OLTP: lle kykenevän ja suuren kyselyliikenteen, se on relaatiotietokanta tai se ei ole mitään.

Reliaatiotietokannoista Oracle on hallitseva suosio. Luulen, että Microsoft SQL Server on toinen. Niitä molempia voidaan käyttää OLTP: n ja kyselyjen työmäärään, mutta et todellakaan pääse eroon näiden työmäärien sekoittamisesta. Tarvitset erilaisia ​​tapauksia OLTP-työkuormiin ja kyselytyökuormiin. SQL: lle ja kuvaajalle on vaihtoehtoja. Useimmat yritykset standardisoivat yhden tietyn tietokannan, minkä vuoksi - tarkoitan vuosikymmenien taistelun jälkeen kaikkien muiden toimijoiden kanssa, että Oraclasta tuli hallitsevin tietokanta. Yksinkertaisesti siksi, että he lopulta pystyivät myymään yrityslisenssejä, joten yritykset käyttäisivät vaihtoehtoisia tuotteita vain poikkeuksellisissa tuotteissa, joita Oracle ei yksinkertaisesti tekisi. Ja tietokannat ovat strategisia siinä mielessä, että myös ne kehittyvät. Ja tiedät, että tein vähän tutkimusta tätä esitystä varten, ja se on eräänlainen - tulen siihen jonkin ajan kuluttua, mutta se on tavallaan mielenkiintoista, kuinka ne kehittyvät, kun tarkastellaan sitä DBA: n sijainnista. Tätä kutsun näkymättömäksi suuntaukseksi. Se on Mooren laki kuutiossa. Se on suunnilleen tällainen: Suurin tietokanta on, ja uusia tietokantoja, ei ole vanhaa tietokantaa, joka saisi paljon enemmän tietoa syödäkseen. Se on yleensä tietokanta, jota käytetään uuteen ongelmaan. Ja tosiasiallisesti ne kasvavat tietomäärien suhteen. Karkeasti Mooren kuutiossa laki. Joten Mooren laki on kymmenen kertaa kuuden vuoden välein. VLDB: t kasvavat kerralla tuhannesta kuuden vuoden välein. Vuonna 1991, 1992 suuret tietokannat mitattiin megatavuina. Vuosina '97 ja '98, gigatavua. 2003, '4, teratavua. 2009, '10, alat nähdä petatatietokantoja. Luulen, että siellä oli tällä hetkellä mahdollisesti yksi tai kaksi eksabyytti tietokantaa, mutta suurin, josta olen kuullut, on 200 petatataalia ajoissa, ja tiedät, ettet saa tietoja petatabyytitietokantoihin. Mutta suurin osa siitä on tietysti uudet suuret web 2.0 -yritykset, mahdollisesti sinulla on Facebookin suunta tähän suuntaan.

Mutta joka tapauksessa, jos tarkastellaan sitä tosiasiallisesti odottamalla tietokannan käyvän läpi tällaisen volyymin lisääntymisen, se vaatii paljon. Ja huomattavan paljon, varmasti petabyyttiluokkaan saakka, he näyttävät menestyneen kohtuullisen hyvin. Tarkoitan, että puhun pikemminkin vanhemmista tuotteista kuin mistään uudesta. He näyttävät menestyneen poikkeuksellisen hyvin. Jos tarkastelemme tietokannan suorituskykyä, pullonkauloja, tämä vie minut takaisin tilanteeseen, jolla olen itse asiassa tottunut niistä välittämään, ja minun piti huolehtia niistä. Tiedät, että tämä on pohjimmiltaan laitteiston rikkoutuminen. On suorittimen pullonkauloja, mahdollisesti muistin pullonkauloja, mahdollisesti levyjen pullonkauloja. Se voi olla se verkko, joka aiheuttaa surua, ja myös lukitsemiseen voi liittyä ongelmia tekemästäsi riippuen, mutta yleensä se johtuu siitä, että ohjelma ei tiedä kenelle lukita. Joten jos aiot virittää tietokantaa, yrität itse virittää sitä niin, että se tanssi näiden viiden mahdollisen pullonkaulan välillä niin hyvin kuin pystyy. Ja se ei ole helppo asia, koska muistin määrä, jonka voit määrittää missä tahansa palvelimessa, kasvaa dramaattisesti. Sitten suorittimista on tullut moniydin, levy, hyvin, mitä voimme nyt tehdä, luulen, että jopa hyödykepalvelimilla voin tehdä satoja ja satoja teratavuja, neljäsosa petatavua, ehkä jopa hyödykepalvelimella. Joten kaikista näistä asioista, joista voit leikkiä, verkko voi tietysti kulkea eri nopeuksilla, mutta pääasiassa kun käsittelet tietokantoja, haluat todella olla kuitukaapeleita palvelimien välillä eikä mitään muuta käynnissä tällä, erityisesti siten.

Tietokannan suorituskykytekijät. Tarkoitan, jätän pois, mistä tässä on kyse, koska tiedän, että Dez puhuu siitä, mutta huono tietokannan suunnittelu tarkoittaa huonosti toimivia tietokantoja. Huono ohjelmointisuunnittelu voi mahdollisesti tarkoittaa hyvin tyhmän SQL-tiedoston heittämistä tietokantaan, mikä vie vain kauhean paljon kauemmin. Samanaikaisuus ja työmäärän sekoittaminen, liian suuri samanaikaisuus aiheuttaa pullonkaulaongelmia. Työmäärän sekoittuminen, kun sinulla on suuria kyselyjä erittäin pienillä, lyhyillä, terävillä kyselyillä, aiheuttaa ongelmia. Kuorman tasapainottamisessa on ongelma. Useimmat tietokannat pitävät siitä huolta, mutta jos sinulla ei ole hienostunutta tuotetta, tiedät vain, että lisäämällä muutama palvelin vain muuta kuin teet, jos todella haluat lisätä klusterin kokoa. Kuorma on todella tasapainossa, ennen kuin saat parhaan mahdollisen suorituskyvyn. Sinun on tehtävä kapasiteetin suunnittelu. Ehdottomasti. Varsinkin nykyisin näinä päivinä, jolloin tietomäärät kasvavat dramaattisemmin kuin aiemmin tietokantoihin. Ja siellä on kokonaisia ​​tietokerrosongelmia, kuinka syöt tietoja, miten siirrät tietoja. Tietojen nousematta jättäminen tietokantaan ajoissa voi olla myöhemmin suorituskykyongelma, koska olemme siirtyneet Windowsissa toimivista tietokannoista kaksikymmentäneljälle seitsemäntoista kolmesataa seitsemänkymmentäviisi operaatioon eikä ole ikkunoita, joilla voit hidastaa tietokantaa alas tai on epätodennäköistä, että sitä olisi nykyään.

Oracle DBA -ongelma. Tätä ajattelin. Olen ollut Oraclen DBA: lla Oracle 7: n kanssa, ja muistan kuinka virittää sen. Ja jos tarkastellaan nyt Oraclea, se on tapa, tapa - siinä on tapa, tapa lisätä kykyä. Sillä on bittikartta-indeksointi ja vastaavat, mutta otin tosiasiallisesti aikaa etsiä ja nähdä kuinka monta viritysparametria tosiasiallisesti Oracle-tietokannassa on tällä hetkellä. Ja viritysparametreja on yli kolmesataa ja viisikymmentä, ja siellä on vielä sata piilotettua parametria, joista erikoistuneet DBA: t saattavat tietää, mutta normaalit Oracle DBA: t eivät tiedä. Ja se tarkoittaa, että tällaisen tietokannan virittäminen on vaikea asia. Se ei ole ollenkaan yksinkertainen asia. Sinulla on oltava siitä tuntemus, sinun on pitänyt tehdä sitä jo pitkään, pitkään, ja sinun on tiedettävä tarkalleen, mitä ongelma luulet ratkaisevan, koska viritys alkaa kun suorituskyky heikkenee, mutta se ei välttämättä ole kaiken suorituskykyä. Voi olla, että tiettyjen kyselyiden suorittaminen on tärkeätä, ja voit korjata sen kiinnittämällä tiettyjä tietoja ja muistia tai korjata se indeksoimalla, tai joutua aloittamaan osioinnin eri tavalla. Asiassa on paljon asioita, joita voit tehdä. Joten näin ollen he eivät aio tehdä sitä päänsä sisällä - DBA: t tarvitsevat työkaluja. Aion nyt siirtää Dezille, joka aikoo kertoa teille indeksoinnista, luulen.

Eric Kavanagh: Hyvä Dez, vie se pois.

Dez Blanchfield: Kiitos, Robin, ja rakastan kansilehteä. Luulen, että olet heittänyt holkin sinne, jotta voin tulla jopa etäältä jotain jännittävää. Olen kuitenkin käyttänyt kuvaa pienestä galaksistamme, sillä näkemyksenäni siitä, mistä tämän päivän haaste tietokannan ylläpitäjille on tullut, koska tämä on mielikuvitus, jonka tapana luulen saapuessani ympäristöön, enkä enää ole tietokantojen hallinnan tai tietokantojen suunnittelun maailmassa tällä tasolla. Mutta kuten sinäkin, Robin ja minä olemme olleet monien vuosien ajan mukana tietokantojen maailmassa joko järjestelmänvalvojana, kehittäjänä tai lopulta arkkitehtina, ja sitten tajusin, että voisin tehdä parempia asioita ansaitaksesi kuoren. Mutta tuntuu siltä, ​​että katselet tätä tietojen galaksia, ja etenkin tänään, kun siirrymme, kuten totesitte, olemme siirtyneet megatavuista petatavuihin ja ekso-mittakaavaan hyvin lyhyessä ajassa., asioiden suuressa järjestelmässä. Mutta mielessäni oleva lause on, että tietokantahakemistot ovat nyt mustaa taidetta ja ne eivät oikeastaan ​​ole sellaisia ​​tavaroita, joissa pelkkien kuolevaisten tulisi jonkin verran tuijota yritystason luokan yrityssovelluksiin ja tyyppiin, jolla sinua muotoillaan puhuivat vain. Mutta halusin käydä läpi nopeasti käytetyn tyyppisen historian, joka minulla on ollut tietokantamaailmojen kanssa, ja viedä asiayhteyteen kohtaan, johon aiomme tehdä johtopäätökset, ja käydä läpi jotain materiaalia tänään ystävien kanssa IDERA, koska mielestäni on paljon erilaista ajattelua kuinka saada tietokannan suorituskyvyn viritys ja yksi heistä heittää tinaa asiaan. Monien kauppojen kanssa, joita törmännyt, he eivät aina pääse siihen pisteeseen, että suoritetaan suorituskyvyn viritys tietokantakerroksessa ja erityisesti hakemistokerroksessa, kunnes he ovat päätyneet kovan ajattelureitin läpi, kun he voivat heittää virittimen siihen. .

Monet ihmiset ottavat mielessäni vain suuren rautaisen lähestymistavan siihen, ja minulla on täällä kuva The Flashista, koska jos olet koskaan katsellut vanhoja elokuvia tai ehdottomasti uusinta TV-ohjelmaa The Flashin kanssa, kuten Flash Gordon on vanha hahmo, ja nyt kun hänet kutsutaan ”Salamaksi”, hänellä on taipumus mennä erittäin, nopeasti ja aina hänen energiansa loppuu. Ja niin tapahtuu, kun heittää iso rauta tietokannan suorituskykyyn. Aina, kokemukseni mukaan voit asettaa peliin suuren suorituskyvyn ja kovan työn, voit optimoida käyttöjärjestelmän ja virittää ne tiettyyn pisteeseen. Voit varmistaa, että sinulla on nopeita moniytimisiä, monisäikeisiä CPU: ita, jotta sovellus toimisi nopeammin, voit heittää siihen paljon RAM-muistia, sinulla voi olla korkean suorituskyvyn taustoja, voit siirtyä kiintolevyistä välimuistiin kiintolevyihin solid-state-tilaan, ja korkea suorituskykyinen tallennusmatriisi. Ja jopa nyt, ihmiset heittävät asioita, kuten flash ja NVMe, tietokantamoottoriinsa ajatellessaan, että he saavat tämän kirjautumisajan kahdesti. Ja aina he saavat jonkin verran hyötyä. Mutta kaikki palautuu samoihin suorituksen viritysongelmiin. Paljon pienviiveisiä verkkoyhteyksiä, jotta klusterit toimivat nopeasti. Ja klusteroimalla tietokantainfrastruktuuria, joten sinulla on enemmän kuin yksi kone, joka tekee kaiken työn. Mutta sinulla on taipumus palata takaisin samaan suorituskyvyn perusongelmaan, ja se on tietojen lukemista. Tietojen kirjoittaminen on suurimmaksi osaksi melko lineaarista haastetta ja ellei sitä tehdä oikein.

Ja sitten meillä on haaste nykymaailmassa: Kaikkia tietokantoja ei luoda yhtäläisiä. Siellä on tietokantoja ja quote-on-quote-tietokanta. Ja kun ajattelemme tietokantamoottoreita, ihmiset ajattelevat usein perinteisiä, tavanomaisia ​​epäiltyjä sellaisina kuin ne olivat SQL-maailmassa. Tiedätkö, että meillä on Oracle ja Microsoft SQL Server, ja avoimen lähdekoodin maailmassa on pari MySQL: n kanssa, joka nyt omistaa Oracle, mutta se on silti avoin lähdekoodi. Ja sitten meillä on epätavallisia epäilijöitä, NoSQL-moottoreita, joilla on yhä kysymys indeksoinnista ja suorituskyvyn hallinnasta. En käsittele niitä yksityiskohtaisesti, mutta näitä on yhä enemmän asiat, jotka ilmestyvät päivittäin, ja ne näyttävät ja tuntuvat tietokantamoottorilta kehittäjien kannalta ja suorituskyvyn kannalta, mutta ne ovat hyvin, hyvin erilaisia ​​petoja ja heillä on oma pieni markkinarako maailmassa veistämään joko muistin suorituskyky tai lineaarinen asteikko levyllä. Mutta näin maailma näyttää tietokantamaailmasta. Tämä on vuosi 2016, tämä on version kolme karttaa, jonka joukko ihmisiä, jotka tuottavat tämän jatkuvan maisemakartan siitä, millaiset tietokannat näyttävät, ja tässä se on - edes superinhimillinen tietokannan arkkitehti tai tietokannan ylläpitäjä ei voisi olla järkevää siitä. Kirjaimellisesti satoja, satoja ja satoja erilaisia ​​merkkejä, malleja, tietokantojen valmistajia, jotka ovat aina SQL-yhteensopivia. Ja mielenkiintoinen asia on, että he kaikki palaavat samaan haasteeseen. Suorituskyvyn ja suorituskyvyn virittäminen tietokantamoottorin ympärillä, ja erityisesti sen mukaan, miten tiedot indeksoidaan.

Joten peitämme vain nopeasti tietokantojen indeksoinnin, koska se on mielenkiintoinen aihe, ja uskon, että joudut käsittelemään sitä yksityiskohtaisemmin demon avulla. Mutta mielestäni on melko hyvin hyväksyttyä ja vakiintunutta teollisuuskäytäntöä, että tietokantaindeksien suorituskyvyn viritys on siellä, missä maailma alkaa ja päättyy, kunhan taataan, että tietoihisi on saatavana nopea ja nopea muoto. Mutta mitä tietokannan indeksointi on? Jos ajattelemme indeksointia muodossa, johon olemme tottuneet arkipäivinä, ajatelkaa kirjan hakemistosivua. Jos haluat löytää jotain kirjasta - etenkin tietosanakirjan kaltaisia ​​tai jonkinlaista viitemateriaalia - jos etsit jotain tämän sivun kaltaista, etsin esimerkiksi pattien aiheita tietosanakirjassa. Haluan löytää kaikki viitteet patoille, veden valuma-alueelle ja suurelle rakennusalueelle, yleensä ihmisen luomalle. Menen taaksepäin, löydän sen aakkostettuun, lajiteltuun luetteloon, A: sta Z: ään, vasemmalta oikealle, ja löydän D. Löydän sanan “padot” ja näen sen sivuilla 16, 38, 41 on viittaus niihin, ja sitten voin mennä noille sivuille, voin skannata silmäni ja löytää viittauksen sanan ”pato”. Se on käytännössä sama käsite tietokannassa, mutta se on nyt monin tavoin rakettitiede. Niin paljon, että käytännössä jokainen tietokannan ylläpitäjä, jonka olen koskaan oppinut tuntemaan, pitää hakemistoja yhtenä kriittisimmänä välineenä suorituskyvyn virittämisessä missä tahansa tietokantamaailmassa riippumatta siitä, mikä heidän kokemuksensa voi olla niin paljon kuin tinan heitto siihen, tai riippumatta tapauksesta.

Yleensä, kun puhutaan tietokannan indeksoinnista, on olemassa useita yhteisiä lähestymistapoja. Ja mitä monimutkaisempia tietokantahakemistoista tulee, sitä monimutkaisempi lähestymistapa tietojen indeksointiin. Mutta lähinnä kun ajattelet tietojen indeksointia - kuvittele, että meillä on tiedosto, jolla on luettelo nimistä; niitä ei voi lajitella aakkosjärjestykseen. Kuvittelemme, että heitä on kaksikymmentä. Jos aiomme lajitella - jos etsimme tietoja luettelosta, ylhäältä alas ja sanotaan, että se on nimiluettelo. Jos valitsen satunnaisen nimen ja aloitan vierittää sitä luetteloa ylhäältä alas lineaarisessa muodossa ja se on järjestämätön luettelo, on olemassa kaksi kriteeriä, joita ajattelen keskimääräisenä hakuaikana ja enimmäishakuaikani - ja Minulla on kirjoitusvirhe toisella rivillä, sen pitäisi olla “enimmäisaika”, anteeksi - mutta keskimääräinen hakuaika on olennaisesti N plus yksi, jaettuna kahdella, ja se on keskimäärin se, että vie minut viisikymmentä prosenttia ajasta skannata luettelon yläosasta luettelon alaosaan löytääksesi luettelossa satunnaisia ​​asioita. Ja toisen rivin, lineaarisen alla, tulisi olla ”enimmäisaika”. Mutta enimmäisaika on lähinnä esineiden lukumäärä, ja se on, että jos minulla on luettelo kahdestakymmenestä asiasta, se vie eniten aikaa. jotain etsimistä kyseisestä tietokannasta on mennä ylhäältä alas, mikä tarkoittaa esimerkiksi 20 kohtaa tässä yksinkertaistetussa esimerkissä. Ja se on erittäin hidas prosessi, ja sitä ei todellakaan ole mahdollista suorittaa. Ja sitten on olemassa muun tyyppisiä tapoja ottaa nämä tiedot ja luoda hakemisto, joka on käytännössä lyhyt luettelo osoittimista siihen, missä todelliset tiedot ovat, kuten binaarinen, B-puu, bittikartta, yhdistelmä, klusteroitu ja klusteroimaton, ja sitten on erityyppisiä tietoja, kuten spatiaalinen, suodatettu, XML ja koko teksti.

Binaari on hyvin yleisesti käytetty asioissa, joissa tiedot soveltuvat siihen. B-puu on luultavasti yleisin, historiallisesti yleisin tapa, koska se on yleinen tapa rakentaa hakemisto minkä tahansa tyyppiseen tietoon ja sallii lokitietojen, valintojen, lisäysten ja poistojen tekemisen suhteellisen helppoa, kun siirrät osoittimia viittaus osoittimiin, pisteisiin. On myös muita tyyppejä, kuten bittikartta, joissa tietotyypit koskevat esimerkiksi jos meillä on jonkin muodon liittyvä alue. Hajautus toimii erittäin hyvin suurissa kohteissa, erityisesti blogeissa ja kuvissa. Ja voit nähdä, että tietojen indeksointiin on olemassa erityyppisiä tieteellisiä lähestymistapoja, matemaattisia lähestymistapoja. Pelkän kuolevaisen kannalta he ovat mielenkiintoinen haaste puhua tällä tasolla. Kun puhut siitä suorituskykytasolla tietokannan ylläpitäjälle, heistä todella tulee rakettitieteilijöitä ja ihmiset tekevät niissä tutkintoja. Tiedän, että tohtori Robin Bloor on varmasti tehnyt niin ja kirjoittanut siitä kirjoja IBM: n ja muut suuret tuotemerkit parin viime vuosikymmenen aikana. Joten - mielestäni olemme todella kuluneet aikaan, jolloin tiedät kerran, että voisin henkilökohtaisesti istua järjestelmän edessä ja pystyisin erottamaan sen, ja näyttämään sinulle tarkalleen missä suorituskykyongelmat olivat komentorivillä tai graafisen käyttöliittymän käynnistystyökalulla, ja alkavat kaivaa tietoja ja kertoa sinulle, missä ongelmat olivat, ja rakentaa siihen indeksejä tai alaindeksejä tai ensisijaisia ​​ja toissijaisia ​​hakemistoja tietoja ja alkaa käyttää sitä asioiden löytämiseen. Mutta kun mietit tätä maisemaa, osoitin sinulle, jossa meillä on satoja ja satoja tuotemerkkejä, valmistajia ja malleja sekä valmistajia ja tietokantatyyppejä, olemme menneet hyvin ja todella sen ajan yli nyt, missä ihminen voi tehdä ymmärtää, minkä tyyppiset tietokantamoottorit meillä ovat. Erityisesti, vaikka palaammekin takaisin Oraclen kaltaisiin malleihin, nykyään vallitsevat tuotemerkit relaatiotietokanta-alustoilla.

Niiden tietokantojen lukumäärä, joiden heidän on käsiteltävä joko omalta käyttöympäristöltä, kuten ERP, HR tai finanssijärjestelmä, vai onko kyse kotitekoisesta alustasta useista syistä, tietokantojen ja tietokantataulukoiden ja tietueiden lukumäärä tekemisissä ovat vain tähtitieteellisiä, ja et fyysisesti voi tehdä sitä käsin. Ja meillä on nyt ollut vielä yksi monimutkaisuus, jossa tietokantapalvelin voi kerran istua vain pöydän alla. Tiedätte, että nuorena kouluna koulunkäynnillä käytin ja työskentelin tietokantaohjelmistojen kanssa alun perin Apple IIes -järjestelmissä ja sitten DOS PC -pohjaisissa järjestelmissä, kuten dBase II, dBase III, käynyt läpi aikakauden, jossa keskusyksiköt ja puolivälissä alue- ja jopa VAX- ja PDP-tiedostot ja lokitiedosto siihen. Ja kuten Saber, ja sitten lopulta, kun jotkut SQL-tietokannat tulivat mukana. Mutta nykyään, kun ajatellaan tietokantamoottoreita, ne näyttävät vasemmasta alakulmasta. Tietokantapalvelin ei ole enää vain yksi kone, joka istuu lattialla pöydän alla; se on satoja koneita, jotka käyttävät tietokantamoottoreiden ja klusterien kopioita, ja ne skaalaavat jopa satoja ja satoja teratavuja dataa, ellei jopa petatavua dataa, mikä on tuhansia teratavuja. Ja jopa äärimmäisyyteen, kuten tohtori Robin Bloor mainitsi, että jotkut erityiset käyttötapaukset - erityisesti lentoyhtiöt, erityisesti valtion virastot - voivat päästä eksabyytteihin. Ne ovat edelleen melko kapeat, mutta sadat teratavua ja jopa kymmeniä petabaitteja ei ole enää epätavallisia, etenkin dotcom-puomista tähän päivään saakka, sellaisena kuin me kutsumme web 2.0 -yrityksiä, kuten Facebook, Google, Yahoo ja niin edelleen.

Meillä on myös monimutkaisuus nyt, kun asiat ovat siirtymässä ulkoiseen palveluun. Meillä on infrastruktuurialusta ja ohjelmistot palvelumallina, joka tarjoaa infrastruktuurin. Erityisesti käyttöjärjestelmäpalveluna, jota emme voi ostaa vain Oraclen kaltaisille tuotteille ja niiden pilvialustalle, tietokannoille ja palvelimille. Ja niin tämä antaa meille mahdollisuuden kehittää sovellusten nopeaa kehitystä ja kytkeä vain tietokanta takaisin palvelimille. Meidän ei tarvitse miettiä, mitä konepellin alla on. Haittapuoli on, että emme usein ajattele sitä, kuinka suunnittelemme ja toteutamme tietokannan takaisin, kunnes se alkaa vahingoittaa ja suorituskyvystä tulee ongelma, ja sitten meidän on lopulta etsittävä oikea työkalu diagnosoidaksesi miksi tietokantamme vahingoittaa ja missä esiintymisasiat ovat. Ja se vie ainakin sen takaisin siihen yleiseen ongelmaan, kuinka olemme indeksoineet kyseiset tiedot ja indeksityypit, joita olemme käyttäneet kyseisiin tietoihin, ja joka sitten tuo meidät takaisin yli-inhimillisen suorituskyvyn vaatimukseen. Ja joku, jolla on pääsy oikeisiin järjestelmiin ja oikeisiin suorituskykyisiin työkaluihin, virittää nämä moottorit ja alkaa löytää hot spot ja tutkia missä kyselyt ovat, missä tiedot liikkuvat, kyselytyypit, kuinka kyselyt on järjestetty, kuka tekee kyselyitä ja ovatko kyselyt jonossa ja onko ne välimuistissa. Mitä replikointia etsit?

Ja niin olemme hyvin ja todella - mielestäni - hetkellä, jossa jopa maailman parhaat tietokanta-gurut, lähinnä tietokanta-arkkitehdit ja tietokannan ylläpitäjät sekä suorituskykypohjat, heidän mielestäni on erittäin tärkeää aloittaa hyödyntämällä oikeita työkaluja. optimaalisen suorituskykyindeksin virittäminen mille tahansa tietokantamoottorille. Koska käsittelemämme mittakaava ja nopeus, jolla asiat liikkuvat, emme yksinkertaisesti pysty tekemään sitä käsin, ja yrittämällä tehdä sitä aina, voidaan ottaa käyttöön muita suorituskykyongelmia, koska meillä ei ehkä ole kokemusta tuosta tilasta. yritämme ratkaista ongelman. Ja uskon, että olemme täällä Bertille ja puhumme siitä, kuinka he ovat ratkaisseet tämän monipuolisen ongelman ja millaisia ​​asioita heidän työkalunsa voi tehdä, etenkin Oracle-maailmalle. Ja sen kanssa, Bert, aion siirtää sinulle.

Bert Scalzo: Kiitos. Tervetuloa kaikki, nimeni on Bert Scalzo, työskentelen IDERAssa. Olen vanhempi tuotepäällikkö joillekin tietokantatuotteillemme. Esitän joitain näistä tänään. Mutta haluan puhua hakemistoista, koska olen samaa mieltä kaikesta, mitä kaikki täällä ovat sanoneet, etenkin viimeisessä diassa, että hakemistot ovat niin monimutkaisia, että tarvitset työkalun, ja toivon vakuuttavani sinut. Joten Oracle-hakemistosuunnittelu, se ei ole niin helppoa kuin ennen. Monet ihmiset ovat epävarmoja itsestään, kun he katsovat vaihtoehtoja, ja pidän tästä sanomasta, jonka vetin pois historiasta, "näissä asioissa on ainoa varmuus siitä, että mikään ei ole varmaa." Ja niin minäkin sellainen ajattele indekseistä nykyään, koska vaikka luulet tietäväsi vastauksesi indeksoivan X, Y tai Z, et todellakaan voi olla varma, ennen kuin yrität sitä, koska optimoijat käyttäytyvät joskus toisin kuin odotat. Ja niin hakemistosuunnittelussa on paljon kokeiluja ja virheitä. Nyt, vanhoina hyvinä päivinä, jos tarvitsit hakemistoa, siinä oli yleensä vain kaksi kysymystä tai yksi kysymys. Onko se ainutlaatuinen vai ei se ainutlaatuinen? Ja olet ehkä ajatellut muita asioita, kuten ”Kuinka monta hakemistoa voi olla korkeintaan yhdessä taulukossa?”, Koska liian monet hakemistot hidastavat lisäyksiä, päivityksiä ja poistoja. Saatat myös olla tietokantajärjestelmässäsi, sinulla oli rajoituksia monen sarakkeen hakemistossa olevien sarakkeiden lukumäärälle, koska toisinaan rajoitukset perustuivat tietokantamoottorin sivun tai lohkon kokoon, mutta todellisuudessa se oli melko yksinkertainen takaisin vanhoina hyvinä aikoina. Sinä joko indeksoit sen tai et. Ja oikeastaan ​​kaikki oli B-puussa. Voisimmeko sallia jäljennökset vai ei, ja siitä oli kyse. Elämä oli hyvää, elämä oli yksinkertaista.

No, nykyään elämä ei ole niin hyvä tai niin yksinkertainen. Olen laittanut punaisen Ghostbuster-merkin läpi tapaan, jolla olemme tehneet sen, koska nyt meillä on B-puu vs. bittikartta vs. bittikartta liittyminen. Ja aion selittää, mitä jotkut näistä ovat hetkessä. Ryhmitetyt ja ryhmittelemättömät, yksilölliset tai kaksoiskappaleet, eteen- tai taaksepäin, toimintoperusteiset, osioidut tai osioimattomat. Jos mukana on osiointi, onko se maailmanlaajuinen vai paikallinen osiointi? Selitän myös sen. Ja sitten on myös jotain, jota kutsutaan indeksoiduksi järjestetyksi taulukkoksi. Ja täällä on tosiasiallisesti puoli tusinaa muuta, koska mielestäni minulla on täällä nyt tarpeeksi, minkä pitäisi vakuuttaa teille, että hakemistot ovat paljon tiukempia kuin luulitte. Tässä nimenomaisessa diassa aloitan kaavion vasemmasta yläkulmasta ja minulla on taulukko. Ja ensimmäinen asia, joka minun on päätettävä, onko tietokantaversiosta ja tietokannan myyjästä riippuen sallivatko objektitaulukot vai ovatko ne vain relaatiotietoja? Menen oikealle puolelle ja sanon, että rakennamme relaatiopöytää. Seuraava kysymys, joka minun on esitettävä itselleni, on, onko se klusterissa? Ja monet teistä, jotka ovat tehneet Oraclen jonkin aikaa, muistavat, että klusterit olivat takaisin Oraclen 6 päivää. Niitä ei todennäköisesti enää käytetä kovinkaan paljon tänään, mutta päästän sen ensin laskemaan sen oksan.

Jos aioin laittaa pöydän klusteriin, minulla olisi pitänyt olla klusteroitu hakemisto siinä taulukossa. Nyt Oraclessa, kun klusteroit taulukon, olet periaatteessa tallentanut rivejä tai rivit olivat lähellä toisiaan, missä arvot olivat samankaltaisia. Ja niin, sinulla on oltava klusteroitu hakemisto ja että klusteroitu hakemisto voi olla osittamaton. Toisin sanoen, ei ollut oikeastaan ​​mitään ositusmenetelmiä, jotka tekisivät klusteroidun taulukon tekemistä. Se oli ehdottomasti jakamaton. Ja koska sitä ei jaettu, se oli globaali. Selitän, mikä globaali on minuutissa. Ja se oli aina B-puuta. Toisin sanoen, kun menin tuosta haarasta, se oli melko yksinkertaista, minulla ei ollut monia vaihtoehtoja. Nyt, jos tein klusteroimattoman hakemiston klusteroidussa taulukossa, joka oli sallittu joissakin versioissa, se taas ei ollut osioitu; Kun sitä ei ole osioitu, ainoa valinta on globaali. Ja niin, siellä voit valita B-puun tai bittikartan. Jälleen se riippui tietokannan versiosta. Mutta nyt, palatkaamme takaisin relaatiotaulukkoon ja alamme mennä alas oikealta puolelta, ja nyt meillä on vain tavallinen, vanha, säännöllinen, kasattu taulukko: relaatiota. Se tulee olemaan pöytätilassa. Menen tavallaan oikealta alas ensin. Joten se on organisaatio, kasa. Seuraava kysymys, joka minun on esitettävä itselleni, on: ”Haluanko osioida tämän taulukon vai en?” Nyt joskus osioit, koska ajattelit: “Hei, optimoija on fiksumpi, kuinka se voi optimoida kyselyitä. ”Mutta monet DBA: t kertovat sinulle, että syy siihen on hallinnollisiin tarkoituksiin. Jos sinulla on sadan miljardin rivin taulukko, jos hajotat sen osioiksi tai kauhoiksi, kun haluat lisätä tietoja viimeiseen ämpäriin, voit pudottaa ja indeksoida vain muutaman miljoonan rivin. Voit lisätä tiedot ja sitten rakentaa kyseisen hakemiston uudelleen vain siihen ämpäriin.

Vaikka se oli hyvä tekniikka joillekin optimointitekniikoille, kuten osioiden eliminointi, sen todellinen arvo oli kyky hallita tai suorittaa hallinnollisia tehtäviä pienemmillä kappaleilla. Kun menen organisaation kasaan, ensimmäinen kysymys oli: ”Jaoinko sen vai ei?” Mennään vasemmalle, en aio jakaa taulukkoa. Nyt voi tuntua oudolta, kun kerron tämän sinulle, mutta sinulla voi olla osioimaton taulukko, etkä voi sitten osioida hakemistoa, kuten olet tottunut, tai voit jakaa hakemiston. Pysähdy ja ajattele. Pöydässäsi on periaatteessa yksi ämpäri, kuten olet aina ajatellut, ja indeksissäsi on silti useita kauhoja. Kun näin tapahtuu, jossa kauhojen ja taulukon lukumäärän ja hakemistossa olevien kauhojen lukumäärän välillä ei ole eroa, niin tarkoitetaan globaalilla. Joten jos taulukkoa ei ole osioitu ja jos hakemisto on osioitu, sitä pidetään globaalina, koska siinä on ristiriita. Nyt sallitaan minun mennä takaisin organisaation kasaan ja tulla alas sen sijaan osiopuolelle. Nyt, jos minulla on osiotaulu, ja sanotaan esimerkiksi, että taulukossa on neljä kauhaa, neljä osiota, hakemistollani voi olla neljä kauhaa, jotta hakemistoni vastaa taulukon suunnittelua. Ja niin se on ohi, oikealla puolella. Tätä pidetään paikallisena. Paikallinen hakemisto tarkoittaa periaatteessa sitä, että taulukon ja hakemiston osiointi tapahtuu samalla tavalla ja sillä on sama määrä kauhoja. Ja kun minulla on paikallinen hakemisto, se voi olla B-puu tai bittikartta, ja se vihreä nuoli, joka sellainen nousee ylös, osoittaa, että vaikka se olisi B-puu, on vielä valintoja, joita voidaan tehdä. Se voisi olla toimintoperusteinen. Ja myös, jos se on bittikartta, on erityyppisiä bittikarttoja. Siellä on jotain, jota kutsutaan bittikartta-liittymisindeksiksi. Jos teet tietovarastoja, se on erittäin suosittu tähtihakemuksen tai suunnittelun hakemisto. Mitä tapahtuu, indeksillä on rivitunnukset sille, mihin se osoittaa taulukossa, mutta siinä on myös rivitunnukset vanhemmista taulukoista, niin että kun olet - sinun on tähdettävä mallin suunnittelu ja etsit tosiasiapöydässä, tämä taulukko-indeksi osoittaa sinut kiinnostaviin tietoihin ja osoittaa sinut mittasuhteiden jokaiselle riville, joten sinulla on oltava vain yksi hakemisto.

Ja itse asiassa tämä syntyi Red Brickin takia, joka oli tietokanta monta vuotta sitten - monet ihmiset muistavat sen. Joten jos katsot tätä kuvaa - ja muista, etten laittanut kaikkea tätä kuvaa, koska kuva olisi paljon isompi -, on vielä lisäkysymyksiä, joita minulla on tekstissä täällä oikeassa yläkulmassa . Onko se käänteisjärjestyksen indeksi? Ja saatat sanoa: “Miksi haluaisin käänteisjärjestyksen hakemistoa? Siinä ei ole mitään järkeä. ”No, jos olet klusteroidussa ympäristössä Oraclissa, jos teet todellisia sovellusklustereita, jos pidät hakemistosi järjestyksessä, niin, että niitä ei peruuteta, jos sinulla on paljon prosessointia, joka lyö samat arvot tai samat indeksiarvot, mitä tapahtuisi, sinulla olisi kuumia alueita B-puustasi. Tarkoittaa, että sinulla olisi kiistelyä ja mahdollisesti lukitusta yrittääksesi käyttää näitä juttuja, ja tekisit sitä verkon kaikkien solmujen kautta. No, jos laitat käänteisen järjestyksen hakemistoon, voit nyt peruuttaa sen. Voit sanoa: "No, samanlaiset arvot ovat puiden eri osissa, joten minulla ei ole erillisiä solmuja, jotka kilpailevat puun kuumista alueista." Ja huomaa myös, että ainutlaatuinen ei toimi joidenkin vaihtoehtojen kanssa. . Jos katsot, olen numeroinut kolme, viisi, kahdeksan ja yksitoista, joten joissain tapauksissa minulla ei ole yksilöivää hakemistoa. Samoin on joitain tapauksia, joissa minulla ei voi olla käänteistä indeksiä, ja silloin on lisäongelmia, kuten kirjaaminen tai puuttuminen, sekä rinnakkaiset ja ei-rinnakkaiset. Voin määrittää asiat tietylle muistialueelle.

Ja tämä jättää vielä melko vähän ominaisuuksia Orackelta. Sanoisin, että kun katsot Oracle 12: ta, siellä on todennäköisesti jälleen noin puoli tusinaa asiaa, jotka voisin lisätä tähän kuvaan. Indeksointi on todella monimutkaista, ja olen todella samaa mieltä aikaisemman puhujan kanssa, jotta voit selata tätä ja tehdä hyvä valinta, tarvitset työkalun. Tarvitset ehkä jonkinlaisen kuvan, kuten kuvan, ja jonkinlaisen menetelmän, jolla valitset asioita, ja toivottavasti työkalu auttaa sinua pääsemään sinne. Ja sitten se tulee olemaan kokeilu ja virhe. Sanon ihmisille aina indeksoinnin yhteydessä, ”katso ennen kuin hyppäät.” Ja sitten näet pienen koiran täällä, hän hyppää katsomatta, hän päätyy veteen hain kanssa tai kaveri valmistautuu hyppäämään veteen., ja hän aikoo lyödä itseään. Sinun on mietittävä indeksointia, koska hakemiston luominen ei aina tarkoita, että asiat paranevat. Itse asiassa hakemiston luominen voi hidastaa asioita. Ja kyselyn suorituskyky voi olla suuruusluokkaa parempi yhden valinnan suhteen toiseen. Ja minä annan sinulle hyvän esimerkin. Jos teet suunnittelemisen tähtikaaviona ja käytät mittataulukoissa yhdessä tapauksessa bittikartta-indeksejä, toisessa tapauksessa sanot: "Käytän B-puun hakemistoja", saat bittikartan verrattuna B- puu. Voin kertoa, että yksi ratkaisu on suuruusluokkaa tai mahdollisesti useita suuruusluokkia nopeampi kuin toinen. Mutta muista, mikä toimii yhdessä ympäristössä, kuten tietovarastointiympäristössä, mikä ei todennäköisesti ole hyvä valinta OLTP-ympäristössä.

Esimerkiksi, jos otat transaktiotaulukon ja laitat bittikartta-indeksejä transaktiotaulukkoon, on kallista laskea ja nollata bittikartat, nämä pitkät merkkijonot, ja niinpä OLTP-taulukossa saatat osua taulukkoon niin voimakkaasti, että bittikartta hakemisto voi vioittua ja hidastaa järjestelmän toimintaa, koska niitä ei vain ole tarkoitettu päivityksiin. Ne ovat hienoja nopeaan pääsyyn, mutta eivät päivityksiin. Uskon, että hakemisto vaatii virheitä. Ei todellakaan ole enää kultaista sääntöä - tässä yhtälössä on liian monia erilaisia ​​muuttujia tietääksesi - ja lopulta joudut tarkastelemaan toteutusta tai selittämään tietokannasi suunnitelmia nähdäksesi, tehdäänkö hyviä valintoja. Ja joskus suunnitelman analysointi voi olla melkein tiede itselleen. En aio käsitellä sitä tänään - se on toinen aihe - mutta älä ota hakemistosuunnittelua itsestäänselvyytenä. On olemassa perusteltuja syitä, miksi on olemassa kaikki nämä hulluja hakemistotyyppejä, jotka näyttelin teille edellisessä kuvassa ja joista edellinen puhuja puhui. Niitä ei luotu vain siksi, että se oli siisti ominaisuus laittaa tarkistusluettelo jonnekin tietokannan myyjälle; on käyttötapauksia tai skenaarioita, joissa nämä hakemistot ovat tärkeitä ja vaikuttavat merkittävästi. Nyt esitän sinulle joitain esimerkkejä erityyppisistä indekseistä yhdessä työkalumme kanssa. Annan vain nostaa näytön ylös, jotta näet sen. Okei, joten istun täällä - anna minun minimoida tämä sovellus. Istun VMwaren sisällä ja käytän Windows Server 2012 -automaattia.

Ja voit nähdä, että minulla on melkein kaikki työkalut, jotka ihminen tuntee. Tuotepäällikkönä minun on oltava tietoinen kilpailusta, joten ei ole vain mitä työkaluja minulla on, vaan mitä kilpailijani tekevät? Ja meillä on täällä tämä DBArtisan-niminen työkalu, jota olen jo käynnissä, mutta minä aion - joten aion vain tuoda sen esiin. Ja mitä voit nähdä, tämä on todella mukava työkalu, koska sen sijaan, että tarvitsisi käyttää, sano Oraclen yrityspäällikkö ja SQL Management Studio SQL Serverille ja MySQL Workbench MySQL: lle ja kaksitoista muuta tukemiamme tietokantaa, No, kaikki tietokannani on rakennettu tähän työkaluun. Siellä on DB2, siellä on MySQL, Oracle, Postgres, SQL Server ja Sybase, ja se on - Minulla on vain kuusi tietokantaa tässä nimenomaisessa asiassa, koska en voi - työkalu tukee 12 tietokantaa, mutta huonoa VM: tä, ajaa kuusi tietokantaa samanaikaisesti ja yrittää Demon tekeminen on suunnilleen yhtä paljon kuin laitteistoni helpottaa. Joten anna minun palata takaisin Oracliin nyt, ja jos huomaat, kaikki nämä asiat ovat samat. Jos haluan mitata suorituskykyäni DB2: ssä, se on sama valinta, joka minulla olisi Oraclessa. Nyt kansien alla teemme paljon erilaisia ​​juttuja, joten sinun ei tarvitse tietää mitä tapahtuu, mutta annamme sinulle yhdenmukaisen käyttöliittymän, jotta voit olla asiantuntija useilla tietokantaalustoilla. Ja siihen sisältyy hakemusten käsittely, tämän keskustelun aihe.

Saanen tulla tänne ja aloitan ensin katsomalla joitain taulukoita, ja minulla on elokuvatietokanta, jossa on vain muutama taulukko. Ja jos katson tiettyä taulukkoa, kuten asiakastaulukkoa, kun tuon sen täällä, voin nähdä pöydän suunnittelun, tässä taulukon sarakkeet ja tässä tiedot jokaisesta sarakkeesta. Minulla on taulukon ominaisuuksia, mutta huomaa, että täällä on välilehti hakemistoja varten ja näen, että täällä ovat taulukon indeksit. Huomaa, että yksi näistä indekseistä on PK-hakemisto, ensisijainen avain. Nämä muut näyttävät olevan vain indeksejä kyselyn saatavuuden parantamiseksi. Ehkä kysymme etunimen tai sukunimen perusteella tai katsomme puhelimia ja postinumeroita. Ja jos valitsen tietyn hakemiston, kuten tämä postinumero, ja kaksoisnapsautan sitä, nyt voin nähdä, että hei, se ei ole ainutlaatuinen hakemisto ja tässä on joitain muita tyyppejä, bittikartta, ei-ainutlaatuinen, ainutlaatuinen, riippumatta siitä, lajitellaanko se vai ei, riippumatta siitä, onko kyseinen kirjaus vai ei, riippumatta siitä, onko käänteinen järjestys, onko kyseessä funktion perusta. Voi, tässä on hauska, jota en peittänyt. Sinulla voi todella olla näkymättömiä hakemistoja. Ja sinä sanot: "No, miksi hitto haluaisin tehdä näkymättömän hakemiston?" No, annan sinulle hyvän esimerkin. Olet tuotantojärjestelmässäsi ja sinulla on suorituskykyongelma etkä ole varma, että hakemiston luominen korjaa ongelman, joten et halua luoda hakemistoa ja hidastaa tuotantoa, vaan jotenkin tai toisella kyetä testaamaan se. Voit luoda hakemiston tuotannossa näkymättömäksi, mikä tarkoittaa, että monet sovelluskoodit, jotka kutsuvat optimoijaa, käyttävät kyseistä hakemistoa. Se on luotu, se on kelvollinen, mutta sitä ei käytetä. Sitten voit ottaa kyselyn, jonka mielestäsi tämä hakemisto auttaisi, tai sarjan kyselyitä, ja voit kiinnittää vihjeen ja sanoa: "Hei, optimoija, siellä on näkymätön hakemisto, jonka haluan sinun käyttävän ja antavan tiedän, olenko tehnyt asioita paremmiksi. ”Ja nyt olen testannut jotain tuotannossa, mutta en ole rikkoutunut käytössä olevia tuotannon sovelluksia. Sitä käytetään näkymättömään hakemistoon. Se kuulostaa tyhmältä, kun kuulet siitä ensin, mutta sillä on hyötyä.

Voimme myös määrittää hakemistoissa, ovatko ne rinnakkaisia, ja myös kuinka monta esiintymää ne ovat samansuuntaisia. Nyt ryhmittelemättömässä tai ei-todellisessa sovellusklusteriympäristössä, joten ei-teline, rinnakkain tarkoittaisi, kuinka monta aliprosessia kyselyni voi tuoda yrittämään ja työntekijäprosesseja yrittämään saada asian läpi nopeammin tai nopeammin . Ja rinnakkaiset esiintymät olisivat, jos sanoisin, että minulla on kymmenen solmua, jos olen todellisessa sovellusklusterissa, kuinka monta solmua sallin jakaa työn keskenään? Ehkä se on neljä kymmenestä ja jokaisessa neljä prosessia. Se on esimerkki. Ja sitten meillä on näppäinten pakkaus. Voit todella pakkaa hakemistoja? Kyllä vai ei. Ja sitten sinulla on tietysti tallennusparametrit, jotka voit määrittää hakemistoissa. Nyt en kata näitä, koska ne ovat todellakin enemmän tallennusparametreja kuin hakemistoongelma. Ja sitten lopulta meillä on, tehdäänkö nämä osioidut vai osittamattomat. Annan pudottaa sen täällä hetkeksi. Aion siirtyä toiseen kaavaan. Tämä on tähtikaavio ja esimerkiksi tämä jaksotaulukko on mittataulukko. Jos olet koskaan suunnitellut tähtikaavion suunnittelua, sinulla on tyypillisesti ulottuvuus ajalle, joten tässä tietokannassa ja tähtiskeemassa jakso on aikaulottuvuus. Nyt tiedän, että se näyttää hauskalta, sanot: “Hei, katso kaikki nuo sarakkeet - onko kaveri koskaan kuullut normalisoinnista?” No, kun olet tietovarastoissa tai tähdeskeemassa, sinä yleensä sinulla ei ole taulukoita, joita tyypillinen henkilö katsoisi ja sanoisi: "hei, nämä eivät ole kovin hyvin suunniteltuja." Mutta niin teet sen tietovarastoympäristössä.

Katso nyt mitä tapahtuu, koska okei, kaikki nämä sarakkeet ovat. Katsokaa, minulla on hakemisto jokaisessa sarakkeessa. Nyt OLTP-ympäristössä, joka olisi ei-ei. Se hidastaa kaikkia toimini. Tietovarastointiympäristössä pudottaisin ne erälatausjaksojen aikana. Lataa ilman yläkulmia tai indeksejä, ja luon indeksit uudelleen. Ja jos osioin taulukon, niin sen sijaan, että tarvitsisin pudottaa indeksiä jokaiselle taulukon kauhalle, voisin pudottaa hakemiston vain kauhaan tai kauhoihin, joihin tietoja oli tarkoitus mennä kyseisen erälatausjakson aikana. Ja sitten uudelleen vain hakemisto-osa niille kauhoille. Ja niin, että se on erittäin hallittavissa. Ja jos katson - niin tässä on sarake nimeltä “Lippulippu” ja pohjimmiltaan se on kyllä ​​tai ei. Huomaa, että tämä on bittikartta-indeksi, ja useimmille sanot: "No, siinä on järkeä." Kyllä tai ei, Y tai N, on vain kaksi arvoa, jotka ovat järkeviä. Ja koska luet bittikartta-hakemistojen dokumentaatiota, ne kertovat aina, että valitset jotain, jolla on vähän kardinaalia.

Sallikaa minun nyt mennä yhteen tositaulukkooni, joten täällä meillä on tilaukseni. Ja tämä on tilaukseni päivässä. Ja näet nyt, että taas minulla on melko vähän sarakkeita, ja minulla on jälleen kerran enemmän kuin muutama hakemisto. Ja täällä meillä on jotain, jota kutsutaan yleiseksi hintakoodiksi. Tämä koski vähittäiskauppaa, joten tiedät pienet viivakoodit, kun ostat jotain myymälästä, tämä on yleinen hintakoodi. Nyt on miljoonia yleisiä hintakoodeja. Nyt tällä tietyllä tavaraa myyvällä yrityksellä oli todennäköisesti 1, 7–2 miljoonaa yleistä hintakoodia, joten luulet, että tästä ei tule bittikartta-indeksiä, koska 1, 7 miljoonaa erillistä arvoa kuulostaa korkealta kardinaliteetilta. Mutta todellisuudessa haluat tietovarastoympäristössä tämän olevan bittikartta. Sallikaa minun selittää miksi. No, tällä yleisellä hintakoodilla voi olla 1, 7 miljoonaa erillistä arvoa, tämän tilaustaulukon rivien lukumäärä on sadoista miljoonista miljardeihin riveistä. Hakemistoni on pieni kardinaliteetti verrattuna pöydän kokoon tai kardinaliteettiin. Se tekee siitä matalan kardinaalisuuden. Tämä tekee bittikartta-indeksistä hyödyllisen, vaikka se on vastaintuitiivinen 1, 7 miljoonalla erillisellä arvolla, jonka valitsisit täältä bittikarttaksi. Nyt, jos tietäisin, että haluan käyttää bittikartta-liittymäindeksiä, tuote ei tällä hetkellä tue sitä, lisään sen seuraavalle julkaisulle, mutta se olisi toinen vaihtoehto täällä. Ja muista tähtikaaviossa, että bittikarttaindeksi olisi tosiasiapöydällä ja että yksi B-puun hakemisto osoittaisi tosiasiataulukon riville ja sitten jokaiselle riville, joka ilmestyi kyseisen tosiasian mittataulukossa. . Ja niin, sinulla on toinen vaihtoehto siellä. Ja niin, katsotaanpa, haluan tulla ulos taulukoista nyt ja haluan vain näyttää nopeasti, että minulla on samat tiedot, hakemistoissa, ja aion tehdä saman perustoimen.

Nyt syy, jonka vuoksi nosin tämän esiin, on se, että saatat huomata, hei, täällä ei ole ensisijaisia ​​avaimia. Ensisijaiset avaimet tehdään näppäinrajoituksella, joten ne todella kuuluvat rajoitusmääritelmien piiriin. Nämä olisivat indeksejä, jotka eivät ole osa rajoituksia. Nyt saatat sanoa: "No, odota hetki, joka saattaa näyttää ulkomaiselta avaimelta, ja vieras avain on rajoitus", mutta vieraat avaimet ja useimmat tietokannat eivät automaattisesti luo hakemistoa vieraan avaimen sarakkeeseen, vaikka se onkin suositeltavaa, ja sinä menet - minulla on samat valinnat uudelleen. Ja jos haluan muuttaa vain pakkaamiseksi, voin tehdä sen.

Nyt pakkaus toimii vain B-puuhakemistossa. Se mitä sallii on, kun tarkastellaan B-puun erilaisia ​​solmuja, se mahdollistaa joidenkin arvojen pakkaamisen. Se ei todellakaan ole pakkausta kuten taulukkompressio, se on pakkaus siitä, mikä on tallennettu B-puuhun muihin kuin lehtiä koskeviin solmuihin. Se ei säästää tonnia tilaa, mutta sillä voi olla merkitystä. Ja sen myötä huomasin, että olen melko lähellä aikaa, joten haluan tehdä, että haluan palata takaisin ja lopettaa jakamisen. Ja meillä on tuotteemme siellä nelitoista päivän kokeiluversioon idera.com-sivustossa. Se on aika hyvä tuote, varsinkin jos työskentelet useiden tietokantaalustojen kanssa. Jos työskentelet kahden tai kolmen eri tietokannan kanssa, tämä työkalu helpottaa elämääsi. Meillä on työkaluja, jotka auttavat sinua hakemiston suunnittelussa ja valinnassa. Meillä on työkalu nimeltään DB Optimizer. En vain pystynyt käsittelemään sitä tänään, se olisi liikaa. Ja jos haluat ottaa minuun yhteyttä, siellä on sähköpostiosoitteeni, se on, tai voit saada minut kiinni yksityisellä sähköpostillani, ja minulla on blogeja, minulla on verkkosivusto ja blogeja sekä LinkedIn-profiili. Joten ota rohkeasti yhteyttä minuun mistä tahansa, vaikka se ei liity tuotteisiin, jos haluat vain puhua tietokannoista, olen sydän ja rakastan kyllästyä teknobabbleihin.

Eric Kavanagh: Hyvä on, Dez, Robin, olen varma, että jokaisella on vähintään pari kysymystä, täällä on muutama minuutti jäljellä. Dez, mitä luulet?

Dez Blanchfield: Minulla on yksi suuri kysymys, joka minun on esitettävä sinulle, se on istunut mieleni takana. Mikä on hulluin skenaario, jonka olet nähnyt? Olen lukenut blogiisi, seuraan tarkkaan, - olet, olet todennäköisesti yksi harvoista ihmisistä, jotka ovat asuneet melkein kaikissa epätodennäköisissä, ja uskon, että tohtori Robin Bloor on toinen, jonka olen tavannut elämäni. Mutta tiedät, olet todennäköisesti nähnyt jokaisen hullua skenaarion, mitä hulluimmista skenaarioista olet nähnyt, että olet törmännyt, ja kuten ihmiset, jotka vain eivät pystyneet selviytymään, olet onnistunut kävelemään ja suorittaa Jedi-mieli temppuja tällä koko DBArtisanilla?

Bert Scalzo: Meillä oli kerran asiakas, joka tietokannan suunnittelussa he ajattelivat paljon tapaa, jolla he ajattelevat tiedostoasetussuunnittelua, ja niin - kun normalisoit tietokannan, yrität ensin päästä eroon ryhmien toistamisesta. No, heillä oli pylväs ja he tekivät siitä pitkän tai BLOB- tai CLOB-arvon, ja niihin sijoittaisi arvo, numero yksi, puolipiste, arvo numero kaksi, puolipiste, arvonumero, puolipiste ja heillä olisi tuhansia arvoja siellä, mutta heidän piti etsiä tuosta sarakkeesta ja he ovat kuin: “Miksi tämä asia sujuu niin hitaasti?” Ja olen kuin “No, et voi luoda hakemistoa tekemästäsi, se on vain ei sallittu. ”Joten me itse osoitimme heille suunnitelmia käyttämällä, että heidän tarvitsi tehdä, oli normalisoida kyseinen taulukko. Ei siksi, että normalisointi on jotain akateemista tehtävää, joka tekee asiat paremmaksi, vaan koska he halusivat kyselyn kentältä, mikä tarkoitti, että he halusivat pystyvän indeksoimaan sitä, etkä pystynyt indeksoimaan sitä toistuvassa ryhmässä tai ainakaan ei helposti . Ja niin se on luultavasti pahin asia mitä olen koskaan nähnyt.

Dez Blanchfield: Kyllä, on mielenkiintoista kuinka usein törmännyt, mielestäni haaste tietokantoihin, ihmiset unohtavat sen olevan tiede. Ja siellä on ihmisiä, jotka tekevät tutkintoja ja tohtorintutkintoja tässä koko tilassa, kirjoittavat siitä papereita, ja olet kirjoittanut kokonaisen sanonnan, mukaan lukien TOAD-käsikirjat ja muut asiat muistista. Suuntaus jonkinlaiseen, lainaan lainatuun ”suuriin tietoihin” nyt - Näen monien ihmisten unohtavan tietokannan arkkitehtuurin ja tietokantatekniikan perusteet, tietokantatieteen, jos haluat. Mitä näet kentällä, kun siirrytään eroon perinteisistä tietokantaympäristöistä ja perinteisestä tietokanta-ajattelusta, että kynsimme tehokkaasti maahan, ja kyse oli vain suorituskyvyn virittämisestä ja skaalaamisesta. Näetkö paljon ihmisiä uudelleen keräämästä ja sinulla kokemusta siitä, että he vain istuvat siellä ja saavat “a-ha” -hetken, kuten eureka-hetken, jolloin he ymmärtävät, että nämä suuret tiedot ovat oikeastaan ​​vain eräänlaisia ​​todella suuria tietokantoja? Onko se jotain siellä, ja ihmiset vastaavat sinulle sellaisenaan: "Unohdimme, mitä tiesimme ja voisitko tuoda meidät takaisin pimeältä puolelta?"

Bert Scalzo: No, ei, ja tämä on kamalaa joutua jonkin verran myöntämään, mutta relaatiotietokantamyyjät ovat juoneet myös tämän Kool-Aidin. Jos muistat, en tiedä, noin kymmenen vuotta sitten aloitimme jäsentämättömän datan sijoittamisen relaatiotietokantoihin, mikä oli tavallaan outoa, ja sitten tiedot, relaatiotietokannat, lisäävät nyt NoSQL-tyypin kamaa. Itse asiassa Oracle 12: ssä, CR2 - tiedän, että se ei ole vielä loppunut - mutta jos katsot beetaa, jos olet beta-ohjelmassa, se tukee varjostusta. Ja niin, nyt sinulla on relaatiotietokanta, jota ei ole lisätty käsitettä NoSQL-varjostimesta. Ja niin, a-ha-hetki näyttää olevan enemmän suhteellisten puolien ihmisille, jotka ovat menossa “a-ha”. Kukaan ei tule koskaan tekemään sitä oikein, edes tietokannan ylläpitäjät, joten olemme täytyy mennä yli ja liittyä pimeälle puolelle.

Dez Blanchfield: Oikein, joten sanot siirtyvän moniin sotkuisiin tietoihin, jos ymmärrän oikein, niin että meitä laitetaan siihen, mitä me nyt kutsumme isoiksi tietoalustoiksi, mikä on tavallaan hauskaa, koska ne ovat ei niin vanha, mutta eikö se tarkoita sitten sitä, että he keskittyvät siihen, mitä he tekevät relaatiotietokantaansa saadakseen lisää bang-kykyä vastineelleen?

Bert Scalzo: Ei, yleensä, jos heillä on tarve - se olisi ollut "suuri tietotyyppitarve", he huomaavat, että sen sijaan, että olisi mentävä toiselle tietokantaalustalle ja tehtävä jotain -suhteellisella tavalla, tietokantatoimittajat antavat nyt heille samat ei-relaatiotekniikat relaatiotietokannansa sisällä tehdäkseen näitä asioita. Tarkoitan, hyvä esimerkki olisi, jos sinulla on jäsentämätöntä tietoa, kuten JSON-tietotyyppi tai jokin muu monimutkainen tietotyyppi, jolla on merkitys upotettuna itse tietoon, tietokannan toimittajat eivät vain tue sitä, mutta antavat sinulle ACID: n rakenteettomien tietojen noudattaminen. Relaatiotietokannat ovat omaksuneet uudemmat tekniikat ja tekniikat, joten taas a-ha näyttää olevan enemmän kuin se, että "Hei, sovelluskehittäjät, olemme oppineet jotain ja meidän on opittava se uudelleen", se on "Hei, teemme sen tällä tavalla nyt, miten voin tehdä sen tällä tavalla perinteisessä relaatiotietokannassani ja tehdä sen kuten minä tässä tietokannassa täällä? ”ja siitä on tulossa yleisempiä, ja kuten sanoin, tietokantatoimittajat itse sallivat että.

Dez Blanchfield: Okei, ketkä ovat perinteiset epäillyt tässä tilassa DBArtisan-työkalulle? Tein kotitehtäviä siitä, mitä kirjoitit äskettäin, ja muistista kirjoitit jotain, mielestäni se oli yksi blogeistasi, tietokannan äärimmäisestä suorituskyvystä Oracle-maailmassa. En muista, milloin se oli, luulen, että olit joskus tänä vuonna muistista, tai viime vuoden lopulta, olet kirjoittanut tämän asian. Ja minusta tuntui, että se oli perinteinen, tavallinen epäily tyyppi aiheesta, josta tänään puhumme, jolloin ihmiset menevät erittäin laajaan tietokantaympäristöön etsimään mitä kutsut siihen äärimmäisiksi hyötyiksi. Ketkä ovat tavallisia epäilyjä, joita näet siellä, jotka ottavat DBArtisanin käyttöön ja hyödyntävät sitä?

Bert Scalzo: No, meillä on itse asiassa paljon asiakkaita, tänään olin yhdessä erittäin suuren valtion viraston kanssa, joka - ja heillä on kirjaimellisesti todennäköisesti lähellä 1 000 kopiota ohjelmistomme, koska se antaa ihmisille mahdollisuuden keskittyä siihen, mitä he " teemme, etkä tee sitä. Ja se on okei, tarkoitan, että kaikkien pitäisi tietää, miten tehdä jotain, mutta tuottavuus saa aikaan ”mitä” tehdään. Jos yritys pyytää minua tekemään tehtävän, heitä kaikki kiinnostavat. Milloin sain valintamerkin sanoakseni, kun tehtävä on tehty? Ei mitä tekniikkaa tai mitä technobabblea käytin sinne pääsemiseen. Ja niin, työkalumme avulla he voivat keskittyä mihin, ja antaa heidän olla paljon tuottavampia, ja se on todella valtava etu, ja kuten sanoin, jotkut tietokannat tarjoavat työkalun vain tietokantaalustaansa varten. Tarjoamme sitä 12 tietokantaalustalle. Minulla on sama työnkulku, sama graafinen käyttöliittymä, samat navigoinnit. Jos tiedät kuinka myöntää käyttäjälle käyttöoikeus tai miten luoda taulukko tai luoda hakemisto tietokantaan, voit tehdä sen kaikissa kahdessatoista, koska se on sama ulkoasu ja sama työnkulku. Tällä on valtava arvo asiakkaillemme.

Dez Blanchfield: Kyllä, luulen, että ihmiset haluavat saada paljon enemmän potkua vastineeksi henkilöstöresursseistaan. Ja päivät, jolloin sinulla on yksittäinen asiantuntija Oraclessa, Ingresissä ja DB2: ssä, ovat kaikki ohi. Ihmisten odotetaan olevan kaikkien kauppojen jätti, joten mielestäni tämä asia on pelastanut heidän henkensä.

Viimeinen nopea asia, ennen kuin annan sen tohtori Robin Bloorille. Mainitsit, että siellä on ilmainen lataus neljääntoista päivään. Mitä tekee - jos aion mennä eteenpäin ja aion tehdä sen, muuten, aion laittaa sen Bloorin tekniseen laboratorioon ja kehrätä tätä asiaa ylöspäin ja saada käsi kädessä itse - minulla ei ollut ollut mahdollisuutta tehdä sitä ennen tänään. Mainitsit 14 päivän kokeilujakson, sanoit, että käytät sitä tietokoneesi VM: ssä. Oletan, että se on kannettava tietokone. Minkälainen on lähtötason asetus, jonka avulla joku voi saada käsiinsä ja käyttää neljäntoista päivän kokeilua, juuri ennen kuin annan takaisin Robinille hänen kysymyksensä?

Bert Scalzo: Mikä tahansa Windows-ympäristö, joten Windows 7, virtuaalikone, jossa on yksi suoritin ja neljä keikkaa muistia. Emme ole todella rasva tai kallis työkalu. Nyt jos haluat käyttää tietokantapalvelinta samassa VM: ssä samassa Windows-järjestelmässä, niin, joudut lisäämään lisää, mutta jos käytät tietokantaa tietokantapalvelimella tai erillisellä VM: llä, VM ladata ja ajaa tuotteemme on erittäin kevyt: yksi prosessori, neljä keikkaa muistia, melkein mikä tahansa Windows-versio - ja tuemme sekä kolmenkymmenenkahden että kuusikymmentäneljän bitin asennuksia. Mutta sinun on asennettava tietokantatoimittajan asiakas. Joten jos halusit muodostaa yhteyden Oracliin, sinun on asennettava SQL-verkkopalvelin, koska juuri sitä Oracle vaatii, jotta voit puhua tietokantaan.

Dez Blanchfield: Kuulostaa melko suoraviivaiselta. Mielestäni yksi asia tästä enemmän kuin mikään, jonka toivon ihmisten vievän pois, lukuun ottamatta oivallusta, että tämä työkalu aikoo pelastaa heidän henkensä, on, että heidän pitäisi mennä ja ladata se ja leikkiä sen kanssa, koska tarjoat 14 päivän ilmaisen kokeilujakson. Ja se voi toimia heidän nykyisessä kannettavassa tietokoneessaan asentamatta mitään ylimääräistä, koska jos he tekevät jo tietokannan hallintaa, he työskentelevät jo tietokantojen kanssa, joilla on kaikki nämä työkalut paikallaan ja onko se käynnissä paikallisella VM: llä tai paikallisella työpöydällä, kuulostaa siltä, ​​että sen asentaminen ja pelaaminen on vaivatonta. Joten suosittelen ihmisille sitä.

Robin, olen varma, että sinulla on kysymyksiä ja Eric, olet todennäköisesti saanut joitakin yleisöltä, joten Robin, entä minä välitän sinulle ja sitten takaisin Ericelle?

Robin Bloor: Kyllä, okei, hyvin, minulla on asioita sanottavaa, tarkoitan, olen aina pitänyt tätä aluetta kiehtovana, koska se oli - leikkasin hampaani siihen. Mutta totuus on, luultavasti vuodesta 1998, 1999 lähtien, olen lukenut siihen, mihin Oracle todella pystyy. Ja tiesin Sybase ja Microsoft SQL Server, että molemmat ovat melko yksinkertaisia ​​verrattuna siihen, mitä Oracle voisi tehdä. Panit minut nauramaan kun - tarkoitan, peitin suuni, kun aloit puhua varjostuksesta. Oracle teki tämän aiemmin. Oraclen esittely jossain vaiheessa, he hermostuivat objekti-relaatioideasta, joten he esittelivät kykyä luoda jonkinlainen esineiden merkitseminen ja esineiden varastointi Oracliin, ja puhuin heidän insinööriensä kanssa, jotain parin vuotta sen jälkeen kun he esittelivät sitä ja kysyin kuinka moni ihminen käytti sitä, ja hän sanoi, että mielestäni kaksi asiakasta oli kokeillut sitä ja se oli se. Ja mielestäni sama asia tapahtuu, jos he alkavat yrittää tehdä trendikkäitä NoSQL-asioita. Tiedätkö, että se on virhe, tarkoitan, olen kiinnostunut eräänlaisesta ajatuksestasi. Varmasti - he juovat Kool-Aidia. Heistä tuntuu siltä kuin heidän pitäisi kyetä esittämään väitteitä, jotka ovat samanlaisia ​​kuin suuret NoSQL-tietokannat, kuten Cassandra, mutta tiedättekö, onko sillä mitään järkeä sinulle?

Bert Scalzo: Ei, olet lyönyt kynnen päähän. Minulle, jos aion tehdä relaatiota, valitsen relaatiotuottajan, kuten Oraclen tai SQL Serverin, DB2: n tai Postgresin, mutta jos aion tehdä jotain, joka ei ole suhteellista, isossa datatilassa tai NoSQL-tilassa, aion valita oikea työkalu oikeaan työhön. Ja en usko, että se olisi luonnollista mennä ensin relaatiotietokantamyyjälleni. Ja sitten lisäät siihen toisen rypyn, eli mitä on saatavilla pilvessä? Niin monet ihmiset haluavat saada tietokannat pois lähtökohdasta. Sitten sinun on katsottava pilvipalveluntarjoajaasi ja sanottava: “Okei, mitä tarjoat, mitä tietokantoja minulla on käytettävissäni, jotka sopivat tarpeisiini ja kuinka myytäviä ne ovat, ja rehellisesti sanottuna, mikä on kyseisen tietokannan käytön hinta tai maksu pilvissä tunnissa tai päivässä. Ja gigatavua tai teratavua kohti? ”Ja löydät ehkä joitain suhteellisen uudemmista tietokannoista, kuten Mongo tai Cassandra, ehkä niiden hinnat ovat halvemmat, joten jos aiot tehdä monen petabaidin tyyppisiä suuria tietoja, saatat ehkä joudut - vain kustannusten kannalta - ottamaan huomioon pilvessä olevat NoSQL-tietokannat, koska ne saattavat olla kustannustehokkain tapa tehdä se.

Robin Bloor: Kyllä, oikein. Tarkoitan sellaista - kokemuksessani olevaa relaatiotietokantoihin liittyvää asiaa - joka on tarpeeksi pitkä, jotta siinä olisi arpia, se on varmasti - siellä on paljon järkeä, että jos aloitat sen soveltamisen ja - ymmärrät mitä relaatiot oikeasti ovat, niin Tarkoitan, että muistan käydä neuvonpitoa yhden asiakkaan kanssa kerran, ja he johtivat minua huoneeseen. He olivat tehneet eräänlaisen kokonaisuuskaavion ja luoneet kolmannen normaalin muodon, mallin siitä, millaiset yrityksen pääjärjestelmät olivat. Siinä oli kaksisataa neljäkymmentä pöytää ja he sanoivat: ”No, mitä ajattelet siitä? Me aiomme rakentaa tietokannan tätä varten ”ja kysyi:“ Mitä ajattelet siitä? ”Sanoin:“ En usko, että se tulee toimimaan. ”Ja se on totta, se on totta, tiedätkö, koska ne olivat loppumassa ylöspäin, jotta voidaan luoda tietty rakenne yksitoista-liittymiin. Ja se on asia, joka ymmärretään relaatiosta. Joten olen tavallaan kiinnostunut siitä, kuinka paljon huonoa suunnittelua kohtaat. Tarkoitan, että minulla ei ole mitään ongelmaa DBArtisanin kanssa - se tekee erittäin järkeviä asioita ja se, että voit tosiasiallisesti näyttää useilla alustoilla, on mielestäni upeaa - mutta kuinka paljon kohtaat siellä, missä suunnittelu on kysymys missä ihmiset olisivat voineet ratkaista kaikenlaiset sydämensä säröt, jos he joutuvat tähtikaavaan sen sijaan, että saisivat siitä lumihiutaleita, tiedätkö?

Bert Scalzo: No, en halua kuulostaa arkaluontoiselta tai ylimieliseltä, mutta sanoisin useammin. On selvää, että suurimmassa osassa tietokantoja, joihin olen mukana, niissä on ongelmia tai ongelmia. Mikä on hyvää, koska työkalumme, kuten tietokannan optimointityökalumme, voivat auttaa heitä ratkaisemaan nämä ongelmat, ja mikä on minulle todella hauskaa, on se, että monet ongelmat ovat samoja yksinkertaisia ​​ongelmia uudestaan ​​ja uudestaan. Työskentelin juuri toisena päivänä asiakkaan kanssa, jolla oli yksisuuntainen liittymiskysely, ja olen kuin “Okei, miksi et käyttänyt lauseketta?” Ja he ovat kuin “No, en "En tiedä mikä tämä on." Ja sitten sanoin: "Ja katsokaa tässä alavalinnoissanne korreloitunutta ja ei-korreloitunutta", sanoin: "Joissakin tapauksissa sinulla on missä tahansa lauseessa syvin taso, taulukon viite ulkoreunasta. ”Sanoin:” Siirrä se oikealle tasolle, älä upota sitä syvemmälle kuin sen on oltava, hämmentät optimoijaa. ”Ja muutamalla parilla painalluksella me otti jotain, joka oli käynnissä noin kaksi tuntia, ja sai sen kymmeneen minuuttiin, ja se oli vain - siinä tapauksessa emme tehneet mitään muuta kuin parannaneet heidän kirjoittamaa SQL: tä. Luulen, että ongelmana on, että monet yliopistot ja monet ihmiset, jotka opiskelevat ohjelmointia ei-akateemisessa ympäristössä, oppivat sen kirjattuna ajankohtana tai rivisuuntautuneena prosessina ja relaatiot ovat luonteeltaan suuntautuneita, ja niin te täytyy miettiä sarjoinaan kirjoittaa hyvä SQL.

Robin Bloor: Kyllä, mielestäni se on aivan oikein. Ja sinun on ymmärrettävä, kyse on asioista, kuten ihmisten pitäisi tietää tällaisten asioiden ABC. Sillä ei ole merkitystä. Et voi tehdä rationaalisia asioita, jos et ymmärrä, että edes suunniteltu, hyvin mallinnettu tietokanta, liittyminen vie aikaa, lajittelu vie aikaa. He tekevät, koska maailma ei ole koskaan löytänyt tapaa saada nämä menemään nopeasti. He ovat löytäneet tapoja järjestää tiedot niin, että ne menevät nopeammin kuin muuten. NoSQL-tietokantoja kohtaan minun on sanottava paljon innostusta yksinkertaisesti siitä, että ne välttävät liittymistä. He alkavat vain rakentaa tietokantoja samalla leviämisellä niissä, koska jos liittyt johonkin NoSQL-tietokantaan, ne imevät voimakkaasti. Etkö usko?

Bert Scalzo: Voi ehdottomasti. Ja minun täytyy nauraa, koska aloitin tien takaisin ennen relaatiotietokantoja ja takaisin, kun Ingres oli RTI, Relational Technology Institute, ja meillä ei ollut SQL: tä, meillä oli pre-SQL-relaatiokielet. Luulen, että Ingresissä tuolloin sitä kutsuttiin Queliksi. Joten sait näistä vanhoista tietokantamalleista, kuten verkko ja korkeampi graafinen tai hierarkkinen, ja käydät suhteelliset paradigmat muutaman vuosikymmenen kuluttua, ja nyt minusta tuntuu, että palaamme jälleen melkein hierarkkiseen. Se on melkein kuin olemme palanneet.

Robin Bloor: Kyllä, oikein. Parempi luovuttaminen Ericille, kulutin liikaa aikaa, mutta onko meillä kysyttävää yleisöltä, Eric?

Eric Kavanagh: Meillä on, meillä on muutama. Menemme vähän kauan täällä, mutta heitän pari sinua kohti. Meillä oli muutama kysymys näkymättömien hakemistojen ympärillä. Yksi kysymys oli: ”Onko jonkun käytettävä työkaluasi nähdäksesi ne?” Toinen kysymys oli: ”No, entä jos olet sokea?”

Bert Scalzo: Se on hyvä asia.

Eric Kavanagh: Myös utelias kysymys, joten vain FYI.

Bert Scalzo: Ei, sinun ei tarvitse olla työkalumme. Se on Oracle-ominaisuus, näkymättömien hakemisto. Pohjimmiltaan datasanakirjassa, Oracle pitää vain metatiedot, jotka sanovat: ”Optimoija, sivuuta tämä hakemisto. Se on täällä, mutta ellet ole fyysisesti neuvottu vihjeen avulla, SQL-komennon optimointivihje, älä käytä tätä. ”Ja niin, ei, sinun ei tarvitse olla työkalumme, ja kaikessa suhteessa sitä on tavallinen vanha hakemisto, voit nähdä sen missä tahansa työkalussa, se vain sanoo, että optimoija sanoo: "Emme huomioi sitä normaalissa kyselyjen käsittelyssä." Sinun on ohjattava se, jos haluat sen tottuvan. Se on todella kätevä kuvailemalleni skenaariossa, joka on, jos haluat rakentaa hakemiston tuotannossa, mutta et ole vaarassa rikkoa raportteja tai jo käynnissä olevia asioita, mutta halusit testata niitä, voit tehdä sen. Sille se on hyödyllisintä.

Eric Kavanagh: Se on hyvää ja sitten täällä oli toinen hyvä kysymys. "Entä joillekin näistä uusista muistimuistion tietokannoista? Kuinka muistin sisäinen tietokantatekniikka muuttaa peliä indeksoinnin suhteen? ”

Bert Scalzo: Poika, no, me - nyt se on hyvä, olen iloinen, että joku kysyi kysymyksen, meidän on mentävä vielä puoli tuntia. Ei, muisti, se riippuu tietokannan myyjästä. Nyt normaalisti olen, puhun vain kiitosta kaikesta, mitä Oracle tekee, koska se on hämmästyttävää heidän rakentamaansa tekniikkaan, mutta kun repiä takaisin kansien alle ja katsot mitä muistia on Oraclessa, Oraclessa tietokanta, mikä se on todellisuudessa, onko se edelleen rivitallennus levyllä, ja se saa ladatun sarakevaraston muistiin, ja jos muistia ei ole riittävästi koko taulukon pitämiseen, se palaa takaisin osiin; se ei sovi muistiin, sillä se tehdään rivivarusteeksi, joten voit itse tehdä valinnan pöytää vasten ja puolet pöydästä käytät indeksointia lyömällä perinteisiä rivejä pöydässä, ja toiselle puolelle valitse, että se todella menee ulos ja vain tarttuu kaikkeen muistihausta, ja niin, se on erilainen siinä, että esimerkiksi SQL Server toteutti sen Hekaton-tekniikallaan, tiedätte, ja SQL 2014, ja sitä on parannettu SQL 2016: ssa, mutta tietyiltä osin heidän oma on totuudenmukaisempi versio muistilta, ja, mutta jokaisella toteutuksella on etuja ja haittoja, mutta sinun on tavallaan katsottava kansien alle ja toteutettava. Koska minulla oli asiakas, joka sanoi: "Voi tämän taulukon muistissa - aion vain laatia kaikki hakemistot", ja olen kuin "taulukko on suurempi kuin muisti, joka sinulla on palvelimella, joten jossain vaiheessa joidenkin kyselyjen on osuttava levylle. "

Eric Kavanagh: Se on hyvä kuvaus; se on hyvää kamaa. Ihmiset, meillä on vielä muutama webcast-lähetys näiden kavereiden kanssa loppuvuoden aikana, palaa milloin tahansa, kun kuulet Bertin esiintymästä esityksessä, koska tiedämme, että hän tietää hänen jutunsa. On aina hauskaa puhua asiantuntijoiden kanssa. Arkistoimme kaikki nämä verkkolähetykset myöhempää tarkastelua varten. Tässä on jälleen Bertin yhteystiedot ja yritämme kaivaa linkin ladattavaksi ja lähettää sen myös sähköpostilla, mutta voit aina lähettää sähköpostia sinulle todella: Meillä on vielä joukko uusia webcast-lähetyksiä tätä varten vuodessa ja teemme ed ed calla nyt, joten ihmiset, jos on aiheita, joista todella haluat kuulla ensi vuonna, älä ole ujo: Ole varovainen, ihmiset, puhumme kanssasi seuraavan kerran. Hei hei.

Techopedian sisältökumppani

Techopedia Staff on sidoksissa Bloor-konserniin, ja heihin voidaan ottaa yhteyttä käyttämällä oikealla olevia vaihtoehtoja. Tietoja siitä, miten työskentelemme alan yhteistyökumppaneiden kanssa, napsauta tätä.

• Profiili
• Verkkosivusto