Indeksno ludilo: kako izbjeći kaos baze podataka

Osoblje Techopedia, 5. listopada 2016

Odlazak: Domaćin Eric Kavanagh razgovara o indeksiranju baza podataka s dr. Robin Bloor, Dez Blanchfield i IDERA-inog Berta Scalza.

Trenutno niste prijavljeni. Prijavite se ili prijavite da biste pogledali videozapis.

Techopedia Content Partner

Osoblje Techopedia povezano je s Bloor Groupom i s njima se može kontaktirati koristeći opcije s desne strane. Za informacije o tome kako radimo s industrijskim partnerima kliknite ovdje.

• Profil
• Web stranica

Eric Kavanagh: Dame i gospodo, zdravo, i dobrodošli još jednom. Srijeda je, u četiri sata istočno, i oni od vas koji znate program, znate što to znači, vrijeme je za još jednu epizodu Hot Technologies. Da svakako. Moje ime je Eric Kavanagh, bit ću vam moderator današnje sesije: "Indeksno ludilo: Kako izbjeći kaos baze podataka." Ili kao što sam spomenuo u posljednjem eksplozijama e-pošte koji se emitirao, „posustajanje baze podataka.“ Vruć izraz ovih dana, „svađa“. Svi to rade. Doista postoji slajd o vašem. I dosta o meni.

Dakle, serija Hot Technology stvarno je zamišljena da definira određeni prostor, za razliku od Savjeta za brifinge koji je samo jedan "na-jedan" živi analitičar, za Hot Tech imamo dva analitičara. Danas će to biti naš vlastiti doktor Robin Bloor i naš znanstvenik s podacima Dez Blanchfield. A mi govorimo o temi za koju mislim da je doista simbolična za ono što se danas događa na tržištu.

Suština je da se ovih dana nalazimo u svijetu složenosti. Doista, ako mislite unazad petnaest ili dvadeset godina, to je bio tada posve drugačiji svijet, posebno s obzirom na tehnologiju baza podataka. Ranije su baze podataka bile prilično jednostavne. Bilo ih je samo šačica; većina ih je bila relacijska. Sada imamo čitav niz tehnologija baza podataka. Doslovno bilježi opcije na stolu za sve koji žele stvoriti aplikaciju ili napraviti nešto s podacima. Sve se mijenja i to utječe na ljude koji pokušavaju upravljati tim sustavima. Danas ćemo razgovarati s Bertom Scalzo, koji je pravi stručnjak na tom području; on je viši menadžer proizvoda za IDERA o tome što možete učiniti kako biste dobili odgovor na sve te podatke. S tim ću ga predati doktoru Robinu Blooru da ga odnese. Robin, kat je tvoj.

Robin Bloor: U redu, hvala na uvodu. Mislim da - budući da je to stvar s dvije ruke, mislim da bih samo govorio o optimizaciji baze podataka kao uvodu u ovu Hot Tech emisiju. Započela sam život - u tehnologiji i analizi - započela sam život radeći to jer sam pisala članke o mogućnostima baza podataka na DEC VAX platformi. I zbog toga su me upućivali tražitelji baza podataka. A ono što mi se nekako događa jest to zašto biste imali bazu podataka? Mislim, u one dane je ogromno mnoštvo ljudi koristilo izradu datoteka s ključnim vrijednostima i koristilo one da bi imali svojevrsno indeksno pogrešno indeksiranje kako ih mi nazivamo, ali za stvaranje vrste sposobnosti baze podataka, i znate, zašto biste imali još nešto?

A odgovor na to, mislim da je Michael Stonebraker dao najbolji odgovor na to i rekao, "Baza podataka može znati više o tome gdje su podaci i kako brže doći do njih, nego što ikada svaki program može znati." I mislim da je to zanimljivo; to je priroda igre. Ali u 19 - otprilike 1989. godine koji sam započeo u tehnološkoj analizi i znate, u tom su trenutku baze podataka bile vrlo jednostavne, a relacijske baze podataka vrlo jednostavne. Imali su tako malo mogućnosti, mislim, očigledno su mogli pohraniti podatke, a vi biste mogli izraditi sigurnosnu kopiju i imali su, bili su kompatibilni s ACID-om, ali stvarno su imali vrlo slabe optimizatore. Zapravo, teško bi bilo tvrditi da su uopće imali mogućnost optimizacije.

Kasnije su postajali sve bolji i bolji, no, znate, kada baza podataka ne funkcionira - kao što izgledaju klokanici na ovaj ili onaj način koji ukazuju - može biti jako puno razloga zašto to ide sporo. I to me dovodi do toga: baze podataka imaju mnogo funkcija, ali najvažnija je optimizacija upita. Da nisu to učinili, ne biste ih koristili. Radi se o brzom dobivanju informacija, o tome da biste mogli to raditi kada postoji puno istodobnih korisnika, a to je težak problem. A kad zapravo pogledate, nazovimo ih zrele baze podataka, ako želite - ali svakako Oracle, u nešto manjem opsegu, Microsoft SQL Server, svakako Teradata i DB2 - koji su optimizirani ti baze podataka, desetljećima su bili u zgrada. Znate, nisu - netko se nije sjeo - šest momaka na dvojakom, godine, projektu i samo su ih pokupili zajedno. To ne funkcionira tako. Mogućnost optimizacije postupno je rasla, a potrebno je i mnogo toga. U svakom slučaju, razgovarajmo o pozadini baze podataka. Pa, sada postoji puno toga što se govori o NoSQL bazi podataka, a čak postoji i puno entuzijazma za bazu podataka grafikona. I upotreba SQL-a preko Hadoopa i slične stvari. No, istina je u tome da ako želite bazu podataka upravo sada, ako želite potpuno funkcionalnu, sposobnu za OLTP i veliki promet upita, to je relacijska baza podataka ili ništa.

Među relacijskim bazama podataka, Oracle je dominantan u popularnosti. Microsoft SQL Server, mislim, drugi je. Oboje se mogu koristiti za OLTP i pitati radno opterećenje, ali zapravo ne možete pobjeći od miješanja tih radnih opterećenja. Trebate različite incidente za OLTP radna opterećenja i upita za radna opterećenja. Postoje alternative SQL-u i grafu. Većina se tvrtki standardizira na jednoj određenoj bazi podataka, i zato - mislim da je nakon desetljeća borbe sa svim ostalim igračima Oracle postao najdominantniji. Jednostavno zato što su na kraju prodali korporacijske licence, pa bi tvrtke koristile alternativne proizvode samo u izuzetnim proizvodima, Oracle ih jednostavno nije učinio. A baze podataka su strateške u tome što se i razvijaju. I znate da sam malo istražio ovu prezentaciju, i to je neka vrsta - doći ću do nje za neko vrijeme, ali zanimljivo je kako se razvijaju, gledano sa stanovišta DBA-e. To je ono što ja nazivam nevidljivim trendom. Mooreov zakon je izrezan. Otprilike je ovako: Najveća baza podataka je i nove baze podataka, a ne postoji stara baza podataka koja bi mogla probati puno više podataka. Obično je to baza podataka koja se primjenjuje na novi problem. I zapravo rastu s obzirom na količinu podataka. Grubo na Mooreovoj kocki zakon. Dakle, Mooreov je zakon faktor deset puta svakih šest godina. VLDB-ovi imaju tendenciju porasta faktora od tisuću svakih šest godina. Godine 1991., 1992., velike baze podataka mjere se u megabajtima. '97 i '98, gigabajti. 2003, '4, terabajti. 2009, '10, počeli ste vidjeti baze podataka petabajta. Mislim da je trenutno postojala jedna ili dvije egzabajne baze podataka, ali najveće što sam čuo je 200 petabajta na vrijeme, i znate, ne dobivanje podataka u petabajtske baze podataka. Ali, većina toga očito će biti nove velike web 2.0 tvrtke, po mogućnosti, imate Facebook koji ide u tom smjeru.

Ali svejedno, ako to stvarno pogledate, očekujući da će baza podataka proći kroz takvu količinu eskalacija, puno će tražiti. I nevjerojatno, izgleda da su do razine petabajta prolazili prilično dobro. Mislim, govorim o starijim proizvodima, a ne o nečemu novom. Čini se da su izvrsno postupili. Ako pogledamo performanse baze podataka, uska grla, to me vraća u vrijeme koje sam se zapravo brinuo o njima i morao sam se brinuti o njima. Znate da je to u osnovi kvar hardvera. Postoji uska grla procesora, moguće, postoje uska grla, moguće, postoje uska grla diska. To može biti mreža koja vam stvara tugu, a također možete dobiti i probleme sa zaključavanjem, ovisno o tome što radite, ali to je normalno zato što program ne zna koga nazvati zaključavanjem. Dakle, ako ćete prilagoditi bazu podataka, zapravo je pokušavate podesiti tako da pleše između ovih pet mogućih uskih grla i što može učiniti. I to nije lako jer se količina memorije koju možete konfigurirati na bilo kojem poslužitelju drastično povećava. Tada su CPU-i postali višejezgreni, disk, i sad to možemo učiniti, mislim, čak i na robnim poslužiteljima, mislim da možete učiniti stotine i stotine terabajta, četvrtina petabajta, možda, čak i na robnom poslužitelju. Dakle, od svih ovih stvari s kojima se možete igrati, mreža naravno može ići različitim brzinama, ali uglavnom kada imate posla s bazama podataka, stvarno želite imati vlaknaste kablove između poslužitelja i ništa drugo na tome ne pokrenuti, posebno onuda.

Čimbenici uspješnosti baze podataka. Hoću reći, izostavljam o čemu se radi, jer znam da će Dez razgovarati o tome, ali loš dizajn baze podataka znači slabo izvedbu baze podataka. Loš programski dizajn može značiti bacanje vrlo glupog SQL-a na bazu podataka, što će trajati mnogo duže. Miješanje istodobne vrijednosti i radnog opterećenja, previše sukladnosti uzrokovat će probleme s uskim grlom. Miješanje radnog opterećenja, kada imate velike upite s vrlo malim, kratkim, oštrim upitima, to uzrokuje probleme. Postoji problem s uravnoteženjem opterećenja. Većina baza podataka vodi računa o tome, ali ako nemate sofisticiran proizvod, onda znate, samo dodavanje nekoliko poslužitelja nije sve što radite ako zapravo želite povećati veličinu klastera. Zapravo morate uravnotežiti opterećenje prije nego što postignete optimalne performanse. Trebate napraviti planiranje kapaciteta. Apsolutno. Naročito sada u današnje doba kada se količina podataka drastično povećava nego što je bila navika za baze podataka. A postoje i problemi s cijelim slojem podataka u načinu na koji gutate podatke, kako se podaci premještaju. Kasnije ne dobivanje podataka u bazu podataka može biti problem s performansama jer smo prešli od baza podataka koje rade u sustavu Windows, do dvadeset četiri prema sedam do tristo sedamdeset i pet operacija i nema prozora na kojima možete usporiti baza podataka dolje ili je malo vjerojatno da će je postojati danas.

Problem Oracle DBA. O tome sam razmišljao. Bio sam u Oracleovoj DBA s Oracle 7 i sjećam se kako to prilagoditi. A ako sada stvarno gledate na Oracle, to je način, način - to je način, puno više mogućnosti. Ima indeksacija bitmapa i slične stvari, ali zapravo sam uzeo vremena da pogledam i vidim koliko se u ovom trenutku u Oracle bazi podataka nalazi podešavanje parametara. A postoji preko tristo pedeset podešavanja parametara i postoji još stotinu skrivenih parametara o kojima stručnjaci DBA mogu znati, ali normalni Oracle DBA-i ne znaju. A to znači da je podešavanje ovakve baze podataka naporna stvar. To uopće nije jednostavna stvar. Moraš imati osjećaj za to, to moraš raditi dugo, dugo vremena i moraš točno znati koji problem misliš da rješavaš, jer podešavanje započinje kada performanse postaju slabe, ali možda to nije izvedba svega. Možda su bitni izvođenje specifičnih upita, a vi ćete to možda moći popraviti prikvačivanjem određenih podataka i memorije ili ćete morati popraviti indeksiranjem ili ćete možda trebati započeti s particiranjem na drugi način. Puno je stvari koje možete učiniti, poanta je. Dakle, prema tome, oni to neće učiniti u glavi - DBA trebaju alate. Sad ću proslijediti Dezu koji će vam reći o indeksiranju.

Eric Kavanagh: U redu Dez, odnesi to.

Dez Blanchfield: Hvala, Robin, i ja volim naslovnicu. Mislim da ste bacili rupu dolje da dođem čak i iz daleka blizu nečeg uzbudljivog. Ali koristio sam sliku naše male galaksije kao svoje viđenje onoga u što se pretvorio današnji izazov za administratore baza podataka, jer ovo je mentalna slika koju često dočaravam kada uđem u okruženje i više nisam u svijetu administriranja baza podataka ili više dizajniranja baza podataka na toj razini. Ali, kao i vi, Robin i ja smo imali mnogo godina uključeni u svijet baza podataka, bilo kao administrator ili programer, ili na kraju arhitekt, i tada smo shvatili da mogu učiniti bolje stvari kako bih zaradio koru. Ali ima osjećaj kao da buljite u ovu galaksiju podataka, i još više danas, kada krećemo od, kako ste naveli, megabajta do petabajta i egzo-skale u vrlo kratkom roku, u velikoj shemi stvari. Ali izraz koji imam na umu je da su indeksi baza podataka sada crna umjetnost i nisu baš takve stvari koje bi tek smrtnici trebali rešavati, za poslovne aplikacije i vrstu formulacije samo su razgovarali. Ali, htio sam proći kroz kratku prošlost one vrste povijesti koju imam sa svjetovima baza podataka i dovesti u kontekst gdje ćemo donijeti zaključak, a zatim proći kroz materijal danas s našim prijateljima na IDERA, jer mislim da postoji mnogo različitih razmišljanja o tome kako postići podešavanje performansi baze podataka, a jedan od njih je bacanje konzerva na stvar. Za mnoge trgovine s kojima se susrećem oni uvijek ne stižu prilagoditi performanse na sloju baze podataka, a posebno na indeksnom sloju dok ne prođu kroz teži put razmišljanja kako mogu bacati tuner na njega.,

Puno ljudi mi samo prilazi s velikim željeznim pristupom, a ja imam sliku Flash-a ovdje jer ako ste ikada gledali neke stare filmove ili sigurno najnoviju TV emisiju s Flashom, kao u Flash Gordon stari lik, a sada kad ga zovu "Bljesak", obično ide vrlo, vrlo brzo i uvijek mu ponestane energije. To se događa kada bacate veliko željezo na performanse baze podataka. Prema mom iskustvu, u igru ​​možete staviti visoke performanse, naporan rad, možete optimizirati svoje operativne sustave i prilagoditi ih određenom trenutku. Možete osigurati da imate brze multicore, multithreading procesore kako bi se aplikacija brže pokrenula, na nju možete baciti puno RAM-a, možete imati pozadinske ploče visokog propusnog opsega, možete prijeći s tvrdih diskova na predmemoriranje tvrdih diskova u čvrsto stanje i niz pohrane visokih performansi. Čak i sada, ljudi bacaju stvari poput flash-a i NVMe-a u svoje motore baza podataka, misleći kako će ovu prijavu dobiti dva puta. I oni uvijek imaju neki dobitak. No, sve se vraća istim osnovnim problemima u podešavanju performansi. Puno mrežnih veza s malim kašnjenjem, tako da klasteri rade brzo. I grupiranja baze podataka, tako da imate više od jednog stroja koji radi cijeli posao. Ali ipak se vraćate istom problemu s osnovnim performansama, a to je čitanje podataka. Pisanje podataka je u većini slučajeva prilično linearni izazov i ukoliko se ne izvrši pravilno.

I tada imamo izazov u današnjem svijetu: Nisu sve baze podataka stvorene jednakim. Postoje baze podataka i „baze podataka o citatu“. A kad razmišljamo o motorima baza podataka, ljudi često razmišljaju o tradicionalnim, uobičajenim sumnjivcima kao što su bili u svijetu SQL-a. Znate, imamo Oracle i Microsoft SQL Server, a oko toga postoji nekoliko ljudi u svijetu otvorenog koda s MySQL-om, koji je sada u vlasništvu Oraclea, ali još uvijek je open source. I tada imamo ne baš uobičajene osumnjičene, NoSQL motore, koji i dalje imaju problem oko indeksiranja i upravljanja performansama, i neću ulaziti u njih detaljno, ali sve je veći broj ovih stvari se pojavljuju svaki dan i izgledaju i osjećaju se kao motori baze podataka s gledišta programera i sa stanovišta performansi, ali oni su vrlo, vrlo različite zvijeri i imaju svoju malu nišu u svijetu koja će im također napraviti performanse u memoriji ili linearne razmjere na disku. Ali ovako izgleda svijet u svijetu baza podataka. Ovo je 2016., ovo je verzija tri karte mape ljudi koji izrađuju ovu trenutnu krajobraznu mapu kako izgledaju baze podataka, i to je to gdje - čak ni nadljudski arhitekt baze podataka ili administrator baze podataka ne bi mogli imati smisla od toga. Bukvalno stotine i stotine, i stotine različitih proizvođača, modela, proizvođača baza podataka, neizbježno SQL. A zanimljivo je da se svi vraćaju istom izazovu. Ugađanje performansi i performansi oko motora baze podataka, posebno prema indeksiranju podataka.

Dakle, brzo razmotrimo indeksiranje baza podataka, jer je to zanimljiva tema, pa moram, detaljnije, ući u nju detaljnije. Ali, mislim da je prilično dobro prihvaćena i uobičajena industrijska praksa da se podešavanje indeksa performansi baza podataka tamo gdje započinje i završava svijet do osiguravanja dostupnosti podataka u brzom i brzom formatu. Ali što je indeksiranje baza podataka? Ako razmišljamo o indeksiranju u obliku na koji smo navikli kao svakodnevni ljudi, pomislite na stranicu s indeksom u knjizi. Ako želite pronaći nešto u knjizi - posebno poput enciklopedije ili nešto slično referentnom materijalu nekog oblika - ako tražite nešto poput ove stranice, gdje tražim stvari poput teme brane u enciklopediji. Želim pronaći svaku referencu na brane, na sliv vode i na veliko područje nakupljanja koje je stvorio čovjek. Vratit ću se natrag, naći ću ga na abecednom popisu, poredani popis, od A do Z, slijeva udesno, i naći ću D. Pronaći ću riječ "brane" i to mogu vidjeti na stranice 16, 38, 41 tamo se spominje, a onda mogu prijeći na te stranice, mogu skenirati oči i naći ću referencu na riječ "brana". To je u osnovi isti koncept u bazi podataka, ali to je sada raketna znanost na više načina. Toliko toga, da učinkovito svaki administrator baze podataka kojeg sam ikada dobro poznavao smatra indekse jedinim najkritičnijim alatom za podešavanje performansi u bilo kojem svijetu baza podataka, bez obzira na to kakva iskustva mogu biti u vezi s bacanjem limenke na njega ili bez obzira na slučaj.

Kad govorimo o indeksiranju baza podataka, postoji niz zajedničkih pristupa. I što složeniji indeksi baze podataka postaju, složeniji je pristup indeksiranju podataka. Ali u biti kad razmišljate o indeksiranju podataka - zamislite da imamo datoteku s popisom imena; možda nisu razvrstani po abecednom redu. Zamislimo da ih ima dvadeset. Ako ćemo sortirati - ako ćemo tražiti podatke na tom popisu, od vrha do dna, a recimo da je popis imena. Ako odaberem slučajno ime i počnem se pomicati po tom popisu, od vrha do dna, u linearnom formatu i to je neuredan popis, postoje dva kriterija o kojima razmišljam kao svoje prosječno vrijeme pretraživanja i moje maksimalno vrijeme pretraživanja - i Upisao sam pogrešku u drugom retku, trebao bi biti "maksimalno vrijeme pretraživanja", oprosti - ali moje prosječno vrijeme pretraživanja je u osnovi N plus jedan, podijeljeno na dva, a to je u prosjeku, potrebno mi je pedeset posto vremena skenirati s vrha popisa, pri dnu popisa kako biste pronašli bilo koju slučajnu stvar na tom popisu. I drugi redak, pod linearnim, trebao bi biti "maksimalno vrijeme pretraživanja". Ali maksimalno vrijeme pretraživanja u osnovi je broj predmeta, a to je da ako imam popis od dvadeset stvari, najviše vremena mi može oduzeti tražiti nešto u toj bazi podataka jest ići od vrha do dna, što je recimo 20 stavki u ovom pojednostavljenom primjeru. I to je vrlo spor proces i stvarno nema načina da se to prilagodi. Zatim postoje druge vrste načina uzimanja tih podataka i stvaranja indeksa, što je zapravo kratki popis pokazivača na to gdje su stvarni podaci, kao što su binarni, stablo B, bitmap, hashing, klasterirani i ne-klasterirani, i tada postoje različite vrste podataka kao što su prostorni, filtrirani, XML i cjeloviti tekst.

Binarna je upotreba vrlo česta za stvari u kojima se podaci predaju. B-stablo je vjerojatno najčešći pojedinačno u općem smislu, povijesno, po tome što je to uobičajen način strukturiranja indeksa u bilo koji oblik podataka i omogućuje da se dnevnici, odabiri, umetanja i brisanja razriješe relativno lako dok pomičete pokazivače oko referenca na pokazivače, točke. Postoje i druge vrste, poput bitmapa, gdje se tipovi podataka tiču ​​ako imamo pridruženi raspon nekog oblika. Hashing vrlo dobro djeluje na velike predmete, posebno blogove i slike. I možete vidjeti da postoji niz različitih vrsta znanstvenih pristupa, matematičkih pristupa indeksiranju podataka. Za obične smrtnike zanimljiv je izazov razgovarati na ovoj razini. Kad razgovarate o tome na razini performansi za administratora baze podataka, oni stvarno postaju raketni znanstvenik i ljudi imaju stupnjeve u njima, a znam da je to doktor Doctor Robin Bloor to sigurno i učinio, i napisao knjige o tome za IBM i druge velike marke u posljednjih nekoliko desetljeća. I tako, moje je mišljenje, da smo zapravo prošli vrijeme u kojem, znate da sam jednom osobno mogao sjediti ispred sustava i moći bih ga rastaviti i pokazati vam točno tamo gdje su problemi s performansama bili u naredbenom retku ili na alatu za pokretanje grafičkog korisničkog sučelja, i počnite prodirati u podatke i reći vam gdje su bili problemi, te ugraditi indekse, podindekse ili primarne i sekundarne indekse u to podataka i počnite ga koristiti za pronalaženje stvari. Ali kad razmišljate o tom krajoliku, pokazao sam vam, gdje imamo stotine i stotine marki, marki, modela i modela te proizvođače i vrste baza podataka, sada smo dobro i zaista prošli tamo gdje čovjek može napraviti osjetiti vrste motora koji se nalaze na bazama podataka. Osobito, čak i ako se vratimo na sličnosti Oracle-a, ovih dana prevladavajući brendovi na relacijskim platformama baza podataka.

Broj baza podataka s kojima se moraju baviti bilo iz vlasničke platforme poput ERP-a ili HR-a ili financijskog sustava ili jesu li oni iz različitih razloga platforma kućanstvo, broj baza podataka i tablica baza podataka i zapisa koji završimo baviti se samo astronomskim i fizički to ne možete učiniti rukom. I imali smo dodatnu komplikaciju sada, kada bi jednom začas vaš poslužitelj baze podataka mogao sjediti ispod vašeg stola. Znate, kao dijete u školi, išao sam i radio na softveru za baze podataka u, prvobitno, Apple IIes-u, a zatim i na sustavima temeljenim na DOS-u na PC-u, poput dBase II, dBase III, prošao je razdoblje s mainframima i sredinom, rasponu, pa čak i VAX-ovima i PDP-ovima i datoteci zapisa. I slično Saberu, a onda na kraju i kad se pojave neke od SQL baza podataka. Ali ovih dana kada razmišljamo o motorima baza podataka, oni izgledaju kao donji lijevi kut. Poslužitelj baze podataka više nije samo jedan stroj koji sjedi na podu ispod stola; to su stotine strojeva koji pokreću kopije motora baze podataka i klastera, i oni razmjeravaju do stotine i stotine terabajta podataka, ako ne petabajta podataka, što je tisuće terabajta. Čak i do krajnosti, kako je spomenuo doktor Robin Bloor, da neki posebni slučajevi upotrebe - zrakoplovne tvrtke, posebno vladine agencije - mogu doći do prekomjerne potrošnje. Oni su i dalje prilično niša-y, ali stotine terabajta i čak desetak petabajta više nije neobično, posebno od dotcom-ovog procvata do sad, nešto što nazivamo web 2.0 tvrtkama, poput Facebooka, Googlea, Yahoo-a i tako dalje.

Imamo i komplikaciju sada kada stvari prelaze na vanjsku službu. Imamo infrastrukturnu platformu i softver kao servisni pristup koji pruža infrastrukturu. Osobito uslugu platformi na kojoj ne možemo samo kupiti za primjerice Oracle i njihovu cloud platformu, baze podataka i poslužitelje. To nam omogućuje vrlo brzi razvoj aplikacije i samo povezujemo bazu podataka na poslužitelje. Ne moramo razmišljati o onome što se nalazi ispod haube. Loša strana je ta što često ne razmišljamo o tome kako dizajnirati i implementirati bazu podataka natrag sve dok ne počne povrijediti i performanse ne postanu problem, a onda na kraju moramo potražiti pravi alat za dijagnosticiranje zašto naša baza podataka boli i gdje su problemi s izvedbom. I neizbježno ga vraća tom uobičajenom problemu načina na koji smo indeksirali te podatke i vrste indeksa koje smo koristili za te podatke i koji nas tada vraćaju nadljudskim zahtjevima performansi. I netko tko ima pristup pravim sustavima i pravim alatima za izvođenje podešavanja tih motora i započinje s pronalaženjem zgodne točke i pogleda gdje su upiti, gdje se podaci kreću, vrste upita, kako su upiti strukturirani, tko vrši upite i jesu li upiti u redu i ima li ih predmemoriranje. Koju replikaciju tražite?

I tako smo dobro i uistinu - po mom mišljenju - u trenutku u kojem su čak i najbolji svjetski gurui baza podataka, u osnovi naši arhitekti baza podataka, naš administrator i baze podataka o izvedbi, po mom mišljenju oni vrlo potrebno započeti s korištenjem pravih alata pružiti optimalnu prilagodbu indeksa performansi za bilo koji motor baze podataka. Budući da razmjera kojom se bavimo i brzina kojom se stvari kreću, to jednostavno ne možemo učiniti rukom, a pokušaj da to učinimo uvijek može dovesti do drugih performansi, jer možda nemamo iskustva u tom prostoru koji pokušavamo riješiti problem. I vjerujem da ćemo se ovdje predati Bertu, a mi ćemo razgovarati o tome kako su riješili taj raznoliki problem i vrsti stvari koja njihov alat može ne, posebno za svijet Oracle. I s onim tamo, Bert, prenijet ću ti.

Bert Scalzo: Hvala. Dobrodošli svima, moje ime je Bert Scalzo, radim za IDERA. Ja sam stariji voditelj proizvoda za neke proizvode iz naše baze podataka. Danas ću demonstrirati neke od njih. Ali želim razgovarati o indeksima, jer se slažem sa svime što su svi ovdje rekli, posebno na zadnjem slajdu, da su indeksi sada toliko složeni da vam treba alat, a nadam se da ću vas uvjeriti. Dakle, dizajn Oracle indeksa nije nimalo lagan kao nekada. Mnogi ljudi neće biti sigurni u sebe kad gledaju mogućnosti, i sviđa mi se ova izreka koju sam povukao iz povijesti, "u tim stvarima je jedina sigurnost da ništa nije sigurno." mislite o indeksima ovih dana, jer čak i ako mislite da znate odgovor na koji biste trebali indeksirati X, Y ili Z, zaista ne možete biti sigurni dok to ne isprobate, jer se ti optimizatori ponekad ponašaju drugačije prema očekivanju. I tako kod dizajna indeksa ima puno pokušaja i pogrešaka. U stare stare dane, ako vam je trebao indeks, uglavnom su bila samo dva ili jedno pitanje. Je li bio jedinstven ili nije bio jedinstven? I možda ste pomislili na druge stvari poput "Koliko indeksa mogu imati najviše na jednoj tablici?", Jer previše indeksa usporava vaše umetke, ažurira i briše. Možda ste i vi bili u vašem sustavu baza podataka, imali ograničenja u tome koliko stupaca može biti u indeksu više stupaca, jer su ponekad postojala ograničenja na temelju veličine stranice ili bloka vašeg motora, ali u stvarnosti je to bilo prilično jednostavno. u dobrim starim danima. Ili ste ga indeksirali ili niste. I doista, sve je bilo u stablu B. Mogli smo dopustiti duplikate ili ne, i o tome se radilo. Život je bio dobar, život jednostavan.

Pa, danas, život nije tako dobar ili tako jednostavan. Stavio sam crveni znak Ghostbuster na način na koji smo to radili, jer sada imamo B-stablo nasuprot bitmapu, nasuprot bitmapu. I objasnit ću što su neki od njih u trenu. Klasterirani i neplasterizirani, jedinstveni ili duplikati, naprijed ili obrnuti redoslijed, temeljen na funkcijama, particioniran ili ne podijeljen. Ako je uključena particija, je li globalna ili lokalna podjela? Objasnit ću i to. A onda postoji i nešto što se naziva indeksirana organizirana tablica. A zapravo je ovdje ostalo pola tuceta drugih, jer mislim da ih sada imam dovoljno što bi vas moglo uvjeriti da su indeksi mnogo teži nego što ste možda mislili. U ovom posebnom dijapozitivu počet ću u gornjem lijevom dijelu dijagrama i imam tablicu. I prvo što moram odlučiti je da li dozvoljavaju objektne tablice, ovisno o verziji vaše baze podataka i dobavljaču baze podataka, ili su samo relacijske? Idem niz desnu stranu i kažem da gradimo relacijsku tablicu. Sljedeće pitanje koje moram sebi postaviti jest je li to u klasteru? I mnogi od vas koji ste neko vrijeme radili na Oracleu sjećat ćete se da su se grozdovi vraćali za Oracle 6 dana. Danas se vjerojatno više ne koriste previše, ali pusti me da prvo spustim tu granu.

Ako bih svoj stol stavio u klaster, na njemu bih morao imati indeks klastera. Sada, u Oracleu, kada ste sastavljali tablicu, u osnovi ste spremali redove ili su redovi bili blizu jedan drugome gdje su vrijednosti bile slične. I tako, morate imati klasterirani indeks i taj klasterirani indeks može biti ne particioniran. Drugim riječima, zapravo nisu postojale metode particioniranja kako biste napravili grupiranu tablicu. Bila je strogo nerazdijeljena. A zato što je bila nepodijeljena, bila je globalna. Objasnit ću vam što je globalno za minutu. I uvijek je bilo B-stablo. Drugim riječima, kada sam sišao s te grane, bilo je prilično jednostavno, nisam imao mnogo izbora. Ako bih na nekom klasteriranom stolu napravio indeks bez klastera, što je u nekim verzijama bilo dopušteno, opet nije bilo particionirano; kad nije podijeljen, tada je vaš jedini izbor globalan. I tako, tamo imate izbor B-stabla ili bitmape. Opet, to je ovisilo o vašoj verziji baze podataka. Ali sada se vratimo do relacijskog stola i počnimo opet niz desnu stranu, a sada ćemo imati običan, stari, pravilan stol s gomilama: relacijski. Bit će u prostoru za stolom. Prvo sam ovdje niz desnu stranu. Dakle, to je organizacija, hrpa. Sljedeće pitanje koje moram postaviti sebi jest: „Želim li podjeliti ovu tablicu ili ne?“ Ponekad biste podelili particiju jer ste mislili: „Hej, optimizator će biti pametniji u načinu na koji može optimizirati upite. "Ali mnogo DBA će vam reći da je razlog zbog kojeg to radite u administrativne svrhe. Ako imate tablicu od sto milijardi redaka, ako je podijelite na particije ili kante, kada želite dodati podatke u posljednju kantu, možete ispustiti i indeksirati to je samo nekoliko milijuna redaka. Možete umetnuti te podatke i onda možete ponovno izgraditi taj indeks samo na tom skupu.

Iako je to bila dobra tehnika za neke, optimizacijske tehnike poput uklanjanja particija, njegova stvarna vrijednost bila je mogućnost administriranja ili obavljanja administrativnih zadataka na manjim dijelovima. Kad odem u organizacijsku gomilu, prvo je pitanje bilo: "Jesam li je podijelio ili nisam?" Idemo slijeva, neću dijeliti stol. Sada vam se može činiti neobično kad vam to kažem, ali mogli biste imati nerazdijeljenu tablicu, a zatim ne možete particionirati indeks onako kako ste navikli ili možete particionirati indeks. Zaustavite se i razmislite. Vaš stol ima u osnovi jednu kantu, kao što ste oduvijek mislili, a svejedno će indeks imati više kanti. Kad se to dogodi, gdje postoji nesklad između broja kanti i tablice i broja kanti u indeksu, to je ono što globalno znači. I tako, ako tablica nije particionirana i ako je indeks podijeljen, smatra se globalnom, jer postoji neusklađenost. Eto, dopustite mi da se vratim na hrpu svojih organizacija i siđem umjesto na particiju. Sad, ako imam particijsku tablicu, a recimo da tablica ima četiri kante, četiri particije, moj bi indeks mogao imati četiri kante tako da moj indeks odgovara mom dizajnu tablice. I to je gotovo, s desne strane. To bi se smatralo lokalnim. Lokalni indeks znači u osnovi da se podjela tablice i indeksa vrši na isti način i ima isti broj skupina. I onda, kad imam lokalni indeks, to bi moglo biti B stablo ili bitmapa, a ona zelena strelica koja se uspinje, pokazuje vam da čak i ako je B stablo, još uvijek se mogu odlučiti. To bi se moglo zasnovati na funkciji. A također, ako se radi o bitmapu, postoje različite vrste bitmapa. Postoji nešto što se naziva indeks pridruživanja bitne slike. Ako obavljate skladištenje podataka, to je vrlo popularna vrsta indeksa za zvjezdanu shemu ili dizajn. Ono što se događa jest da indeks sadrži ID-ove retka za ono na što upućuje u tablici, ali također će imati i ID-ove retka za nadređene tablice, tako da kad morate - morate startati dizajn sheme i tražite u tablici činjenica, indeks na tablici činjenica upućuje na podatke koji vas zanimaju i upućuje vas na svaki red u vašim dimenzijama, tako da morate imati samo jedan indeks.

A zapravo je to nastalo zbog Red Brick-a, koji je bio baza podataka prije mnogo godina - puno ljudi se toga može sjetiti. Dakle, ako pogledate ovu sliku - i imajte na umu da nisam stavio sve na ovu sliku jer bi slika bila puno veća - još uvijek postoje dodatna pitanja o kojima imam ovdje u tekstu iznad gornjeg desnog dijela, Da li je to obrnuti redoslijed? I možda ćete reći: "Zašto bih želio indeks obrnutog redoslijeda? To nema smisla. "Pa, ako ste u grupi s klasterima u Oracleu, ako radite prave aplikacijske klastere, ako indekse držite u redu, tako da nisu obrnuti, ako imate mnogo obrada koje pogađaju iste vrijednosti ili iste vrijednosti indeksa, što bi se dogodilo je da imate vruća područja vašeg B-stabla. Znači da biste se svađali i vjerojatno zaključavali da biste pokušali pristupiti tim stvarima, a to biste radili preko čvorova u mreži. Pa, ako stavite obrnuti redoslijed indeksa, sada to možete poništiti. Možete reći, "Pa, slične vrijednosti su u različitim dijelovima stabala, tako da nemam svoje zasebne čvorove koji se natječu za topla područja u drvetu." I onda primijetite da jedinstveno ne funkcionira s nekim opcijama, Ako pogledate, nabrojio sam tri, pet, osam i jedanaest, tako da ima slučajeva da ne mogu imati jedinstveni indeks. Isto tako, postoje neki slučajevi u kojima ne mogu imati obrnuti indeks, a onda postoje dodatni problemi poput zapisivanja ili nepisivanja, te paralelne i nesparalelne. Mogu stvari dodijeliti određenom području u memoriji.

A ovo izostavlja još uvijek prilično značajki u Oracleu. Rekao bih da kad pogledate Oracle 12, vjerojatno postoji još oko pola tucete stvari koje bih mogao dodati ovoj slici. Indeksiranje je stvarno složeno i stvarno se slažem s prethodnim govornikom, da biste se kretali kroz ovo i napravili dobar izbor, potreban vam je alat. Možda vam je potrebna slika poput ove i nekakva metodologija o tome kako ćete odabrati stvari i nadam se da će vam alat pomoći da stignete tamo. A onda će biti proba i pogreške. Uvijek kažem ljudima pri indeksiranju, "pogledaj prije nego što skočiš." I tada ovdje možeš vidjeti malog psa, kako skače bez pogleda, završit će u vodi s morskom psom, ili se momak sprema skočiti u vodu, i nagazit će se. Morate razmišljati o indeksiranju, jer stvaranje indeksa ne znači da uvijek stvari postaju bolje. U stvari, stvaranje indeksa može usporiti stvari. I izvedba upita može biti bolji stupanj bolje s jednim izborom nad drugim. I dat ću vam dobar primjer. Ako radite zvjezdanu shemu dizajna, a na tablicama dimenzija koristite jedan indeks bitmapa u jednom slučaju, a u drugom slučaju kažete: "Koristit ću indekse B-stabla", dobili ste bitmap u odnosu na B- stablo. Mogu vam reći da će jedno rješenje biti redoslijed veličine ili, možda, nekoliko reda veličine brže od drugog. Ali imajte na umu da ono što djeluje u jednom okruženju, primjerice u okruženju skladištenja podataka, vjerojatno nije dobar izbor u OLTP okruženju.

Na primjer, ako ste uzeli transakcijsku tablicu i stavili bitmap indekse na transakcijsku tablicu, skupo je izračunati i resetirati bitmape, ove duge nizove i tako u OLTP tablici, možete udariti u tablicu toliko snažno da bitmap indeks može postati korumpiran i usporiti vaš sustav jer jednostavno nisu namijenjeni ažuriranjima. Izvrsni su za brzi pristup, ali nisu dobri za ažuriranja. Mislim da indeks uzima pokušaje i pogreške. Doista više nema zlatnog pravila - u ovoj jednadžbi ima previše različitih varijabli da biste znali - i na kraju ćete morati pogledati izvršenje ili objasniti planove u bazi podataka da biste vidjeli hoćete li napraviti dobar odabir. A ponekad analiza plana gotovo i sama može biti znanost. Neću to danas pokrivati ​​- to je druga tema - ali ne uzimajte dizajn indeksa zdravo za gotovo. Postoje opravdani razlozi zašto postoje svi ti ludi tipovi indeksa koje sam vam pokazao na prethodnoj slici i o kojima je govorio prethodni govornik. To nisu samo stvorene, jer je to bila uredna značajka stavljanja negdje na kontrolni popis za dobavljača baze podataka; postoje slučajevi uporabe ili scenariji u kojima su ovi indeksi važni i značajno će se promijeniti. Uz to, pokazat ću vam nekoliko primjera različitih vrsta indeksa u jednom od naših alata. Dopustite mi da dignem zaslon da ga možete vidjeti. Okej, pa ovdje sjedim - dopustite da ovu aplikaciju svede na minimum. Sjedim u VMware-u i pokreću VM Windows Windows 2012.

I vidite, imam baš svaki alat poznat čovjeku. Kao menadžer proizvoda moram biti svjestan svoje konkurencije, tako da nije samo ono što imam alate, već i što moji konkurenti rade? I ovdje imamo ovaj alat nazvan DBArtisan, koji sam već pokrenuo, ali idem - pa ću ga samo predstaviti. A ono što možete vidjeti je da je to stvarno lijep alat, jer umjesto da koristite, recimo upravitelj poduzeća za Oracle i SQL Management Studio za SQL Server, te MySQL Workbench za MySQL i dvanaest drugih baza podataka koje podržavamo, imam sve svoje baze podataka ugrađene u ovaj jedan alat. Tu je DB2, postoje MySQL, Oracle, Postgres, SQL Server i Sybase, i to je - u ovoj konkretnoj stvari imam samo šest baza podataka, jer ne mogu - alat podržava dvanaest baza podataka, ali moj loši VM, istovremeno pokreće šest baza podataka i pokušava raditi demo, otprilike je onoliko koliko će moj hardver olakšati. Dopustite da se sada vratim natrag u Oracle i ako primijetite, sve su ove stvari iste. Ako želim izmjeriti svoju izvedbu u DB2, to su isti izbori kao i u Oracleu. Sada pod koricama radimo puno različitih stvari tako da ne morate znati što se događa, ali mi vam dajemo dosljedno sučelje kako biste mogli biti stručnjak za više platformi baze podataka. A to bi uključivalo rad s indeksima, tema ove rasprave.

Dopustite mi da dođem ovdje i da prvo počnem tako što ću pregledati neke tablice, a ja imam bazu filmova koja ima samo nekoliko tablica. A ako pogledam određenu tablicu, poput tablice kupaca, kad je dovedem ovdje, mogu vidjeti dizajn svoje tablice, evo mojih stupaca u mojoj tablici i evo informacija o svakom stupcu. Imam svojstva za tablicu, ali imajte na umu da ovdje imam karticu za indekse i ovdje vidim indekse na tablici. Primijetite da je jedan od tih indeksa moj PK indeks, moj primarni ključ. Ovi drugi izgledaju samo kao indeksi za poboljšanje pristupa upitima, možda upitamo imenom ili prezimenom, ili gledamo telefone i poštanski brojevi. A ako odaberem određeni indeks, poput ovog zip koda, i dvostruko kliknem na njega, sada vidim da je, hej, to je jedinstven indeks i evo nekih drugih vrsta, bitmapa, jedinstvenih, jedinstveno, bez obzira je li sortirano ili ne, bez obzira na to je li prijava ili ne, bez obzira je li obrnuto ili ne, bez obzira na to je li to funkcija. Oh, evo zabave koju nisam pokrio. Zapravo možete imati nevidljive indekse. A vi biste rekli: "Pa, zašto bih htio raditi nevidljivi indeks?" Pa, dat ću vam dobar primjer. Vi ste u svom proizvodnom sustavu i imate problem s performansama i niste sigurni da će stvaranje indeksa riješiti problem, tako da ne želite kreirati indeks i usporiti proizvodnju, ali nekako ili drugo što želite biti u mogućnosti testirati. Možete stvoriti indeks u proizvodnji kao nevidljiv, što znači da će se taj indeks koristiti mnogo aplikacijskog koda, pozivajući optimizaciju. Stvoreno je, valjano je, ali neće se koristiti. Zatim možete pokrenuti upit za koji mislite da bi vam ovaj indeks pomogao ili niz upita, a možete staviti nagovještaj i reći: "Hej, optimizator, tamo je nevidljivi indeks. Želim da ga upotrebite i pustite znam jesam li poboljšao stvari. "I sada sam nešto testirao u proizvodnji, ali nisam pokvario aplikacije koje su u tijeku. U tome se koristi nevidljivi indeks. Zvuči glupo kad prvi put čujete za to, ali ima koristi.

Na indeksima također možemo definirati jesu li paralelne, kao i u koliko slučajeva su paralelni. Sada, u okruženju aplikacijskog klastera ili ne stvarnom aplikacijskom okruženju, tako da nije paralelno, paralelno bi značilo koliko podprocesa može pokrenuti moj upit da bih pokušao i radnički procese pokušao riješiti stvar brže ili brže, I paralelni slučajevi bi bili, ako se nalazim u pravoj aplikacijskoj grupi, recimo da imam deset čvorova, koliko čvorova mi je dopušteno da podijelim posao na? Možda je četiri od deset, a na svakom od njih četiri podprocesa. To je primjer. I tada imamo kompresiju ključa. Možete zapravo komprimirati indekse? Da ili ne. I onda, naravno, imate svoje parametre pohrane koje možete odrediti u indeksima. E sad, nisam ih pokrio jer su u stvari više parametara za pohranu nego broja indeksa. I konačno, moramo li napraviti ili ne particionirati ili ne particionirati. Pustite me na trenutak. Idem na drugu shemu. Ovo je shema zvijezda i, primjerice, ta je tablica razdoblja tablica dimenzija. Ako ste ikada radili dizajn sheme zvijezda obično imate dimenziju za vrijeme pa tako u ovoj bazi i ovoj shemi zvijezda razdoblje predstavlja vremensku dimenziju. E sad, znam da će izgledati smiješno, a vi ćete reći: "Bože, pogledaj sve te stupce - je li momak ikad čuo za normalizaciju?" Pa, kad ste u skladištu podataka ili u obliku zvijezdane sheme, vi obično imate ne - imate tablice na koje bi tipična osoba gledala i rekla: "Ma, ovo nisu baš dobro dizajnirane." Ali to je način na koji to radite u okruženju čuvanja podataka.

Pazite što će se dogoditi jer, u redu, postoje svi ti stupci, pogledajte to, imam indeks na svakom stupcu. Sada, u OLTP okruženju koje bi bilo ne-ne. Usporio bi sve moje operacije. U okruženju skladištenja podataka ispuštao bih ih tijekom ciklusa učitavanja u paketu. Učitaj bez režijskih ili indeksnih vrijednosti, a ja bih ponovno stvorio indekse. A ako sam podijelio svoju tablicu, onda umjesto da moram spustiti indeks za svaku kantu u tablici, mogao bih jednostavno baciti indeks na kantu ili kante u koje će podaci ući tijekom tog ciklusa učitavanja serije. A zatim ponovno stvorite samo dio indeksa za te kante. I to ga čini vrlo upravljivim. A ako pogledam - pa evo stupca pod nazivom "Holiday Flag" i u osnovi to je da ili ne. Primjetite da je ovo bitmap indeks, a za većinu ćete reći: "Pa, to ima smisla." Da ili ne, Y ili N, postoje samo dvije vrijednosti koje imaju smisla. I zato što kad pročitate dokumentaciju za bitmap indekse, uvijek vam kažu da odaberete nešto sa slabom kardinalnošću.

Pustite me sada da uđem u jednu od svojih tablica činjenica, pa ovdje imamo moje naredbe. A ovo su moje naredbe dnevno. A sada ćete vidjeti da opet imam dosta stupaca i opet ću imati više od nekoliko indeksa. I upravo ovdje, imamo nešto što se zove univerzalni kôd cijene. Ovo je bilo za maloprodajnu trgovinu, tako da znate one male bar kodove kada nešto kupujete u trgovini, ovo je univerzalni kôd cijene. Sada postoje milijuni univerzalnih cjenovnih kodova. Sada, za ovu određenu tvrtku koja je prodavala stvari, vjerojatno su imali 1, 7 do 2 milijuna univerzalnih cjenovnih kodova, tako da ćete očekivati ​​da to neće biti bitmap indeks, jer 1, 7 milijuna različitih vrijednosti zvuči kao velika kardinalnost. Ali u stvarnosti, u okruženju skladištenja podataka, želite da ovo bude bitna mapa. Dopustite mi da objasnim zašto. Pa, može postojati 1, 7 milijuna različitih vrijednosti za ovaj univerzalni kôd cijena, broj redaka u ovoj tablici redoslijeda iznosi stotine milijuna do milijardu redaka. Moj indeks je niska kardinalnost u odnosu na veličinu ili kardinalnost tablice. Zbog toga je niska kardinalnost. To čini bitmap indeks korisnim, iako je kontraintutivan s 1, 7 milijuna različitih vrijednosti koje biste ovdje odabrali. Ako sam znao da želim koristiti indeks pridruživanja bitmape, proizvod trenutno ne podržava to, dodajem ga za sljedeće izdanje, ali to bi bila druga alternativa. I u zvjezdanoj shemi, zapamtite, indeks bitmape nalazio bi se na tablici činjenica, a jedan indeks u B-stablu upućivao bi na red u tablici činjenica, a zatim na svaki red koji je u tablici dimenzija bio vidljiv za tu činjenicu, I tako, tamo imate drugu opciju. I tako, da vidimo, sada želim izaći iz tablica i želim vam brzo pokazati da imam iste podatke, pod indeksima, i napravit ću istu osnovnu stvar.

Razlog zašto sam to iznio je taj što možete primijetiti, hej ovdje nema primarnih ključeva. Primarni ključevi se rade s ograničenjem ključa, tako da su zapravo pokriveni definicijama ograničenja. To bi bili indeksi koji nisu dio ograničenja. Sad biste mogli reći, "Pa, pričekajte malo, to bi moglo izgledati kao strani ključ, a strani ključ predstavlja ograničenje", ali strani ključevi i većina baza podataka ne stvaraju automatski indeks na stupcu stranog ključa, iako je preporučljivo, i eto vas - opet imam sve iste izbore. A ako se želim promijeniti samo kako bih bio komprimiran, mogu to i učiniti.

Sada kompresija djeluje samo na indeksu B-stabla. Ono što to omogućuje jest, kada gledate različite čvorove u B-stablu, omogućava sažimanje nekih vrijednosti. To stvarno nije kompresija poput kompresije tablice, to je kompresija onoga što je pohranjeno u B-stablu u čvorovima koji ne ostavljaju listove. To ne štedi ni tonu prostora, ali može značiti razliku. I s tim sam primijetio da se vremenom prilično približavam, pa ono što želim učiniti je da se želim vratiti i zaustaviti svoje dijeljenje. Naš proizvod se nalazi na četrnaestodnevnoj probi na idera.com. To je prilično dobar proizvod, pogotovo ako radite s više platformi baze podataka. Ako radite s dvije ili tri različite baze podataka, ovaj će vam alat znatno olakšati život. Imamo alate koji će vam pomoći u dizajniranju i odabiru indeksa, a imamo i alat pod nazivom DB Optimizer. Danas to jednostavno ne bih mogao pokriti, to bi bilo previše. Ako me želite kontaktirati, evo moje adrese e-pošte, ili me možete uhvatiti na moju privatnu adresu e-pošte, a ja imam blogove, imam web stranicu i blogove i LinkedIn profil. Dakle, slobodno mi se obratite o bilo čemu, čak i ako nije povezano s proizvodima, ako samo želite razgovarati s bazama podataka, ja sam štreber u srcu i volim bacati oko technobablea.

Eric Kavanagh: U redu, dobro Dez, Robin, siguran sam da imate barem par pitanja, ovdje imamo još nekoliko minuta. Dez, što misliš?

Dez Blanchfield: Imam jedno veliko pitanje koje vam moram postaviti, sjedi mi u srcu. Koji je najluđi scenarij koji ste vidjeli? Čitao sam vaš blog, pratim vas pomno, vi ste, vjerovatno, jedan od rijetkih ljudi koji su živjeli u gotovo svim vjerovatnoćama, a mislim da je dr. Robin Bloor drugi koji sam upoznao u moj životni vijek. Ali, znate, vjerojatno ste vidjeli svaki ludi scenarij, koji su od najluđih scenarija koje ste vidjeli, na koje ste naišli i poput ljudi koji se jednostavno nisu mogli nositi, uspjeli ste hodati i izvodite trikove s Jedi uma s cijelim tim DBArtisanom?

Bert Scalzo: Jednom smo imali kupca koji je u svom dizajnu baze podataka razmišljao vrlo onako kako bi razmišljali u izgledu izgleda datoteka. I tako, kad normalizirate bazu podataka, prvo što pokušate učiniti je da se riješite ponavljajućih grupa. Pa, imali su stupac i napravili su ga dugačkim ili BLOB ili CLOB, a u njega bi stavili vrijednost, broj jedan, zarez i točku, vrijednost broj dva, tačku sa zarezom, broj vrijednosti, zarez i oni bi imali tisuće vrijednosti tamo, ali oni su trebali pretraživati ​​taj stupac i oni su pitali: "Zašto se to tako sporo odvija?", a ja sam rekao: "Pa, ne možete stvoriti indeks onoga što ste napravili, to je samo to im nije dopušteno. "Mi smo im zapravo, pomoću planova, pokazali da ono što trebaju učiniti je normalizacija te tablice. Ne zato što je normalizacija neka akademska vježba koja stvari čini boljom, nego zato što su htjeli upit na tom polju, što znači da žele da ga mogu indeksirati, a vi to niste mogli indeksirati na ponavljajuću skupinu, ili barem ne lako, I tako je to vjerojatno najgore što sam ikad vidio.

Dez Blanchfield: Da, zanimljivo je koliko često nailazite, mislim da je izazov s bazama podataka, ljudi zaboravljaju da je to znanost. I u ovom cijelom prostoru postoje ljudi koji diplomiraju i doktoriraju, na njih pišu radove, a vi ste napisali čitav bris, uključujući vaše TOAD-ove priručnike i druge stvari iz memorije. Trend ka nekakvim, velikim brojem podataka, sada, vidim da puno ljudi zaboravlja osnove arhitekture baza podataka i tehnologije baze podataka, ako želite, nauku o bazama podataka. Što vidite na terenu što se tiče odstupanja od tradicionalnih platformi baza podataka i tradicionalnog razmišljanja baze podataka koje smo učinkovito priveli na zemlju, a to je bio samo slučaj podešavanja i skaliranja performansi. Vidite li da se puno ljudi ponovno podučava i imaju iskustva gdje samo sjede i imaju „a-ha“ trenutak, poput eureka trenutka, gdje shvate, da su ove velike podatke o podacima zapravo samo neke velike baze podataka? Je li to stvar vani i ljudi vam odgovaraju i nekako kažu: "Zaboravili smo, što smo znali i možete li nas vratiti s mračne strane?"

Bert Scalzo: Pa, ne, i ovo je grozno morati priznati, ali prodavači relacijske baze podataka popili su i taj Kool-Aid. Ako se sjećate, ne znam, prije desetak godina počeli smo nestrukturirane podatke stavljati u relacijske baze podataka, što je bilo neobično, a onda se tim podacima, relacijskim bazama podataka, dodaje NoSQL-tip stvari. Zapravo, u Oracle 12, CR2 - znam da još nije izašao - ali ako pogledate beta verziju, ako ste u beta programu, to podržava izoštravanje. I tako, sada imate relacijsku bazu podataka kojoj nije dodan koncept iz NoSQL izoštravanja. I tako, čini se da je "a-ha" trenutak više za ljude na relacijskoj strani koji idu "a-ha". Nitko to više neće ponoviti kako treba, čak ni upravitelji baza podataka, tako da imamo moram prijeći i pridružiti se mračnoj strani.

Dez Blanchfield: U redu, tako da govorite o promjeni na puno neurednih podataka, ako sam dobro shvatio, stavljanje u, ono što sada nazivamo velikim platformama podataka, što je pomalo smiješno, jer oni nije tako staro, ali ne znači li to da se preispituju na ono što rade sa svojom relacijskom bazom podataka kako bi dobili više novca za svoj dolar?

Bert Scalzo: Ne, obično, ako imaju potrebu za - to bi bilo citiranje "potrebe velikog tipa podataka", oni otkrivaju da umjesto da moraju ići na drugu platformu baze podataka i učiniti nešto u ne -relacijski način, dobavljači baze podataka sada im daju iste nerelacijske tehnike u njihovoj relacijskoj bazi podataka. Mislim, dobar primjer bi bio, ako imate nestrukturirane podatke, poput JSON-ovog tipa podataka ili nekog drugog složenog tipa podataka koji ima značenje ugrađeno u same podatke, dobavljači baze podataka ne samo da to podržavaju, već će vam dati ACID poštivanje nestrukturiranih podataka. Baze podataka relacije prihvatile su novije tehnike i tehnologije, pa se, opet, čini se da "a-ha" više nije to, "Hej, mi, programeri aplikacija, nešto smo naučili i to moramo ponovo naučiti", to je "Hej, sada radimo na ovaj način, kako to mogu učiniti u vašoj tradicionalnoj relacijskoj bazi podataka i raditi to kao što radim u ovoj bazi podataka? "i to postaje sve rasprostranjenije, i kao što rekoh, i sami dobavljači baza podataka omogućuju da.

Dez Blanchfield: Da, tko su tradicionalni osumnjičeni za ovaj alat Alat DBArtisan i to? Napravio sam domaću zadaću na onome što ste nedavno napisali, a iz pamćenja ste napisali nešto, mislim da je to bio jedan od vaših blogova, o ekstremnim performansama baza podataka u svijetu Oraclea. Ne mogu se sjetiti kad je to bilo, mislim da je to negdje ove godine napamet ili sa kraja prošle godine ovo ste napisali. I činilo mi se da je to tradicionalni, uobičajeni sumnjiv tip vrste o kojoj danas govorimo, gdje će ljudi ići u vrlo veliko okruženje baze podataka i tražiti ono što vi nazivate ekstremnim dobicima u tome. Tko su ti uobičajeni osumnjičeni koji se bave DBArtisanom i dobro ga koriste?

Bert Scalzo: Pa, imamo puno mušterija, u stvari, danas sam bio na sastanku s vrlo velikom vladinom agencijom koja - i oni doslovno imaju gotovo 1.000 primjeraka našeg softvera, jer ljudima omogućuje da se usredotoče na ono što čine " radiš, a ne kako to učiniti. Mislim, u redu je, svatko bi trebao znati kako nešto učiniti, ali produktivnost postiže ono "što". Ako me posao zatraži da obavim zadatak, to je sve što ih zanima. Kada sam dobio kvačicu da kažem kada je zadatak obavljen? Ne koju tehniku ​​ili ono što sam koristio da bih stigao tamo. I tako, naš alat omogućuje im da se usredotoče na ono, i omogućuje im da budu daleko produktivniji, a to je zaista ogromna prednost, i kao što sam rekao, neke baze podataka nude alat samo za platformu njihovih baza podataka. Nudimo ga za dvanaest platformi baza podataka. Imam isti tijek rada, isto grafičko korisničko sučelje, iste navigacije. Ako znate kako odobriti privilegiju korisniku ili kako napraviti tablicu ili stvoriti indeks u bazi podataka, to možete učiniti u svih dvanaest jer je to isti izgled i izgled i isti tijek rada. To ima veliku vrijednost za naše kupce.

Dez Blanchfield: Da, valjda, ljudi žele dobiti puno više novca za svoj novac iz svojih ljudskih resursa. A dani prolaska pojedinačnog stručnjaka za Oracle, Ingres i DB2 prolaze. Očekuje se da će ljudi biti Jack svih obrta, pa mislim da im je ova stvar apsolutno spasila život.

Samo jedna zadnja brza stvar prije nego što je predam doktoru Robinu Blooru. Spomenuli ste da postoji besplatno preuzimanje za četrnaest dana, što se događa - ako idem naprijed, a ja ću to učiniti, usput, staviću ga u laboratorij Bloor tech i vršiti ovo ustati i sam se riješiti toga - prije današnjeg dana to nisam imao priliku. Spomenuli ste četrnaestodnevno suđenje, rekli ste da ga izvodite na VM računalu, pretpostavljam da je to laptop. Što su, kakva je postavka na ulaznoj razini da netko dođe u ruke i iskoristi četrnaestodnevno suđenje, neposredno prije nego što se vratim Robinu na njegova pitanja?

Bert Scalzo: Bilo koji Windows okruženje, pa Windows 7, virtualni stroj s jednim CPU-om i četiri giga memorije. Nismo baš debeli ili skupi alat. Ako biste htjeli pokrenuti poslužitelj baze podataka na tom istom VM-u pod istim Windowsom, da, trebali biste dodati više, ali ako vašu bazu podataka pokrećete na poslužitelju baze podataka ili na zasebnom VM-u, VM će se učitati i pokrenite naš proizvod je vrlo lagan: jedan CPU, četiri giga memorije, gotovo svaka inačica sustava Windows - a podržavamo i trideset dvije- i šezdeset četiri bitne instalacije. Ali morate instalirati klijenta dobavljača baze podataka. Dakle, ako ste se htjeli povezati s Oracleom, morate instalirati neto klijent SQL-a, jer to Oracleu treba kako biste mogli razgovarati s bazom podataka.

Dez Blanchfield: Zvuči prilično izravno. Mislim da je jedna stvar od toga više od svega čega se nadam da će ljudi oduzeti, osim spoznaje da će ovaj alat spasiti život, a to je da bi trebali otići i preuzeti je i igrati se s njom, s obzirom da nudiš četrnaestodnevno besplatno probno razdoblje. A može se pokretati na njihovom trenutnom prijenosnom računalu bez instaliranja ičega dodatnog, jer ako već rade administraciju baze podataka, već rade s bazama podataka koje imaju sve te alate i bez obzira rade li na lokalnom VM-u ili na njihovom na lokalnoj radnoj površini, zvuči kao da je bezbolno instalirati i igrati se. Zato toplo preporučujem ljudima.

Robin, siguran sam da imaš pitanja i Eric, vjerojatno si dobio nešto od publike, pa Robin, kako bi bilo da pređem k tebi, a onda natrag do Erica?

Robin Bloor: Da, u redu, pa imam stvari za reći, mislim, uvijek sam smatrao ovo područje fascinantnim jer je to bilo - šijekao sam zube na njemu. Ali istina je da sam, vjerojatno otprilike od 1998., 1999. godine, u nevolji onoga što je Oracle zapravo sposoban. I, znao sam Sybase i Microsoft SQL Server, oba su prilično jednostavna u usporedbi s onim što Oracle može učiniti. Nasmijao si me kad si - mislim, pokrio sam usta kad ste počeli govoriti o oštrini. Oracle je to učinio i prije. Oracle predstavljen u nekom trenutku, oni su postali nervozni od objektno-relacijske ideje, pa su uveli sposobnost stvaranja svojevrsne notacije objekta i pohrane predmeta u Oracleu, a ja sam razgovarao s jednim od njihovih inženjera, nešto poput nekoliko godina nakon što su ga predstavili i pitao sam koliko ga ljudi koristi, a on je rekao da mislim da su ga dva kupca probala i to je bilo to. I mislim da će se ista stvar dogoditi ako počnu pokušavati i raditi trendovske NoSQL stvari. Znaš, mislim da je greška, mislim, nekako me zanima kakve su tvoje misli. Svakako, oni - piju Kool-Aid. Osjećaju se kao da bi trebali moći iznositi tvrdnje slične velikim NoSQL bazama podataka kao što je Cassandra, ali znate, ima li to smisla za vas?

Bert Scalzo: Ne, udario si noktom pravo u glavu. Za mene bih, ako idem raditi relacijsko, odabrao dobavljača relacije kao što je Oracle ili SQL Server ili DB2 ili Postgres, ali ako ću raditi nešto što nije povezano, u velikom prostoru podataka ili NoSQL prostoru, pokupit ću pravi alat za pravi posao. I ne mislim da bi to prirodno prvo otišlo kod mojih dobavljača relacijske baze podataka. I onda mu dodate drugu bora, a to je, što je dostupno u oblaku? Toliko ljudi koji žele izvaditi svoje baze podataka. Zatim morate pogledati svog davatelja usluga oblaka i reći: "U redu, što nudiš, koje baze podataka imaš na raspolaganju za mene koje odgovaraju mojim potrebama i koliko su isplative? Iskreno, kolika je stopa ili naknada za upotrebu te baze podataka u oblaku na sat ili po danu. A po gigabajtu ili terabajtu? "A ono što ćete naći su možda neke relativno novije baze podataka poput Mongo ili Cassandra, možda su njihove stope jeftinije, pa ako idete raditi velike podatke s multi-petabajtom, možda moraju - samo s gledišta troškova - uzeti u obzir NoSQL baze podataka u oblaku jer su to možda najisplativiji način za to.

Robin Bloor: Da, točno. Mislim, moja vrsta - stvar o relacijskim bazama podataka iz mog iskustva - koja je dovoljno dugačka da ima ožiljke, to je sigurno - postoji puno zdravog razuma da, ako ga počnete primjenjivati, i - ako shvatite što je zapravo odnos, to je, Mislim, sjećam se da sam jednom obavio savjetovanje s jednim kupcem, a oni su me uveli u sobu i napravili su svojevrsni dijagram entiteta i stvorili treći normalan oblik, model kakvog su primarni sustavi tvrtke. Imalo je dvije stotine i četrdeset stolova i govorili su: "Pa, što misliš o tome? Za to ćemo izgraditi bazu podataka ", i rekao:" Što mislite o tome? "Rekao sam, " Mislim da neće raditi. "I baš je tačno, znate, jer oni su završavali gore kako bi se stvorila određena struktura unutar jedanaest smjera. I to je stvar koju treba razumjeti u relacijskim odnosima. Stoga me na neki način zanimaju koliko lošeg dizajna nailazite. Mislim, nemam problema s DBArtisanom - on radi vrlo razumne stvari, a činjenica da se zapravo možete prikazati na više platformi, mislim da je predivno - ali koliko ćete susresti vani gdje je dizajn dizajn gdje su ljudi mogli riješiti sve vrste srčanih bolova ako se spuste na zvjezdanu shemu, umjesto da dobiju pahuljicu-y o tome, znate?

Bert Scalzo: Pa, ne želim zvučati poput, samozadovoljan ili arogantan, ali rekao bih češće nego ne. Jasno je da većina baza podataka s kojima se susrećem vani ima problema ili problema. Što je dobro, jer naši alati, poput našeg alata za optimizaciju baze podataka, mogu im pomoći u rješavanju tih problema i, no ono što je meni stvarno smiješno jest da su mnogi problemi isti i jednostavni problemi iznova i iznova. Neki dan sam radila s klijentom koji je imao jedanaestotračni upit za pridruživanje, a ja sam rekao: "ok, zašto nisi upotrijebio klauzulu?" I oni su poput, "pa, nisam "Ne znam što je to." I tada sam rekao, "I pogledaj svoje pod-selektore ovdje na korelirane i one koji nisu u korelaciji", rekao sam, "U nekim slučajevima imate svoju klauzulu gdje na najdubljoj razini, Referenca tablice je od vanjske. "Rekao sam, " To je, pomaknite je na pravu razinu, nemojte je ugrađivati ​​dublje nego što je moralo, zbunit ćete optimizator. "I s nekoliko podešavanja uzeo je nešto što je radilo oko dva sata i sveo ga na deset minuta i to je bilo jednostavno - u tom slučaju nismo učinili ništa drugo nego poboljšati SQL koji su napisali. Mislim da je problem u tome što puno sveučilišta i puno ljudi koji programiraju u neakademskom okruženju, oni to uče kao zapisano-vremenski procesi ili proces orijentiran na redove, a relacijski je skup orijentiran po prirodi, i tako vi moraju razmišljati u setovima kako bi napisali dobar SQL.

Robin Bloor: Da, mislim da je to točno. I morate shvatiti, stvari su takve, ljudi bi trebali znati ove ABC-ove stvari. Nije važno. Nećete moći racionalne stvari ako ne shvatite da će čak i dobro osmišljena, dobro modelirana baza podataka trajati vrijeme, a neke će vam trebati vremena. To rade zato što svijet nikad nije pronašao način da ih brzo natera. Pronašli su načine organiziranja podataka tako da idu brže nego inače, a veliko entuzijazam koji moram reći za NoSQL baze podataka je jednostavno što izbjegavaju pridruživanje. Oni tek počinju graditi baze podataka s istim širenjem podataka u njima, jer ako se pridružite bilo kojoj od NoSQL baza podataka, oni mogu sisati. Ne mislite li?

Bert Scalzo: Apsolutno. I moram se smijati jer, započeo sam povratak prije relacijskih baza podataka i natrag kad je Ingres bio RTI, Institut za relacijsku tehnologiju, a nismo imali SQL, imali smo pre-SQL relacijske jezike. Mislim da se u Ingresu tada zvao Quel. Tako ste dobili od ovih starih paradigmi baze podataka poput mreže i više grafičke, ili hijerarhijske, i prolazite kroz relacijske paradigme nakon nekoliko desetljeća i sada mi se čini kao da se opet vraćamo na gotovo hijerarhijske. Skoro da smo se okrenuli.

Robin Bloor: Da, točno. Bolje da se predaš Ericu, trošim previše vremena, ali imamo li pitanja publike, Eric?

Eric Kavanagh: Imamo, imamo ih nekoliko. Dugo ćemo ići ovdje, ali bacit ću na vas par. Imali smo par pitanja oko nevidljivih indeksa. Jedno je pitanje glasilo: „Treba li netko koristiti vaš alat da bi ih vidio?“ Drugo je pitanje glasilo: „Pa, što ako si slijep?“

Bert Scalzo: To je dobro.

Eric Kavanagh: I znatiželjno pitanje, pa samo FYI.

Bert Scalzo: Ne, ne morate imati naše alate. To je Oracle značajka, indeks nevidljivih. Oracle u osnovi u podatkovnom rječniku zadržava samo dio metapodataka koji glase: "Optimizator, zanemari ovaj indeks. Ovdje je, ali ako vas fizički ne upute putem nagovještaja, nagovještaj optimizatora u SQL naredbi, ne koristite ovo. "I tako, ne, ne morate imati naše alate i u svakom pogledu to je običan stari indeks, možete ga vidjeti u bilo kojem alatu, samo će optimizator reći: "Zanemarivat ćemo ga u uobičajenoj obradi upita." Morate ga usmjeriti ako želite da se naviknemo. Stvarno je prikladno za scenarij koji sam opisao, a to je da, ako želite izgraditi indeks proizvodnje, ali ne riskirati probijanje izvještaja ili stvari koje se već pokreću, ali želite ih testirati, to biste mogli i napraviti. To je ono za što je najkorisnije.

Eric Kavanagh: To su dobre stvari i onda je tu bilo još jedno dobro pitanje. "Što je s nekim od tih novih baza podataka u memoriji? Kako tehnologija baze podataka u memoriji mijenja igru ​​u odnosu na indeksiranje? "

Bert Scalzo: Dečko, dobro - sad je to dobro, drago mi je što je netko postavio to pitanje, morat ćemo krenuti još pola sata. Ne, memorija, to ovisi o dobavljaču baze podataka. E sad, normalno jesam, ne govorim ništa drugo nego hvalim sve što Oracle radi jer je to nevjerojatna tehnologija koju su ugradili, ali kad se ponovno zavučete ispod pokrivača i pogledate što vam je u memoriji u Oracleu, u Oracleu. baza podataka, kakva je u stvarnosti, je li i dalje zadržana trgovina redovima na disku, i ona će se učitati u memoriju spremljenih stupaca, a ako nema dovoljno memorije za držanje cijele tablice, vratit će se za dijelove; neće se uklapati u memoriju, ako to spremate u redove, i na taj ćete način zapravo napraviti odabir prema tablici i za polovicu tablice, upotrebljavate indeksiranje pogodivši tradicionalne redove za stolom, a za drugu polovicu odabirom se zapravo izlazi i samo je hvatanje svega iz in-memorije pretraživanja, i tako, različito je na način na koji ga je, na primjer, SQL Server implementirao sa svojom Hekaton tehnologijom, znate i SQL 2014, i to je poboljšano u SQL-u 2016, ali je u nekim aspektima njihova istinitija inačica memorije i, ali svaka implementacija ima svoje prednosti i nedostatke, ali morate ih pogledati ispod korica i shvatiti. Jer, imao sam kupca koji je rekao, "Oh, ova tablica je u sjećanju - upravo ću sastaviti sve indekse", a ja sam kao "Stol je veći od memorije koju imate na poslužitelju, pa će se u nekom trenutku neki upit naći na disku. "

Eric Kavanagh: To je dobar opis; to su dobre stvari. Pa, ljudi, imati ćemo još nekoliko web emisija s tim momcima tijekom ostatka ove godine, vratite se kad god čujete da je Bert bio na prezentaciji, jer znamo da on zna stvari. Uvijek je zabavno razgovarati sa stručnjacima. Sve te internetske emisije arhiviramo za kasnije pregledavanje. Evo Bertovih kontakt podataka ponovo, a mi ćemo pokušati iskopati tu vezu za preuzimanje i poslati je e-poštom, ali uvijek možete poslati e-poštu uistinu:, za ovo imamo gomilu još webcast godine i trenutno radimo ed, tako da, ljudi, ako postoje teme o kojima biste stvarno željeli čuti iduću godinu, nemojte se sramiti: Pazite, ljudi, razgovarat ćemo s vama sljedeći put. Doviđenja.

Techopedia Content Partner

Osoblje Techopedia povezano je s Bloor Groupom i s njima se može kontaktirati koristeći opcije s desne strane. Za informacije o tome kako radimo s industrijskim partnerima kliknite ovdje.

• Profil
• Web stranica