Indeksna norost: kako se izogniti kaosu baze podatkov

Avtor osebja Techopedia, 5. oktobra 2016

Odvzem: Voditelj Eric Kavanagh razpravlja o indeksiranju baz podatkov z dr. Robin Bloor, Dez Blanchfield in IDER-jem Bert Scalzo.

Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.

Partner za vsebino Techopedia

Osebje podjetja Techopedia je povezano z Bloor Group in z njimi je možno vzpostaviti stik z možnostmi na desni. Za informacije o tem, kako sodelujemo s panožnimi partnerji, kliknite tukaj.

• Profil
• Spletna stran

Eric Kavanagh: Dame in gospodje, pozdravljeni in še enkrat dobrodošli. Sreda je, ob štirih vzhodna ura, in tisti, ki poznate program, veste, kaj to pomeni, čas je za novo epizodo Hot Technologies. Da, resnično. Moje ime je Eric Kavanagh, jaz bom vaš moderator današnje seje: "Indeksno norost: Kako se izogniti kaosu baze podatkov." Ali kot sem to omenil v zadnjem pišu po e-pošti, ki se je iztekel, "spletna zbirka podatkov." Vroča beseda v teh dneh, "spopadanje". Vsi to počnejo. Resnično je diapozitiv o vašem. In dovolj o meni.

Torej, serija Hot Hot je bila resnično zasnovana tako, da definira določen prostor, v nasprotju s sektorsko predavalnico, ki je samo informiranje v živo za analitika v živo, za Hot Tech dobimo dva analitika. Danes bosta to lastna doktorica Robin Bloor in naš znanstvenik s podatki Dez Blanchfield. In govorimo o temi, za katero mislim, da je v resnici zelo pomembna za dogajanje na trgu danes.

Bistvo je, da smo v današnjem času v kompleksnem svetu. Res, če pomislite na petnajst ali dvajset let, je bil takrat še precej drugačen svet, zlasti kar zadeva tehnologijo baz podatkov. Podatkovne baze so bile dokaj enostavne. Bilo jih je le peščica; večina je bila relacijska. Zdaj imamo celotno paleto tehnologij baz podatkov. Dobesedno najde več možnosti na mizi za vse, ki želijo sestaviti aplikacijo ali narediti nekaj s podatki. Vse se spreminja in to vpliva na ljudi, ki poskušajo upravljati s temi sistemi. Danes se bomo pogovarjali z Bertom Scalzo, ki je pravi strokovnjak na tem področju; on je višje vodje izdelkov za IDERA, kaj lahko storite, da se lotite vseh teh podatkov. S tem ga bom izročil doktorju Robinu Bloorju, da ga odnese. Robin, tla so tvoja.

Robin Bloor: V redu, hvala za uvod. Mislim, da - ker gre za dvoročno stvar, mislim, da bi govoril le o optimizaciji baz podatkov na splošno kot uvodu k tej oddaji Hot Tech. Začel sem življenje - v tehnologiji in analizi - življenje sem začel s tem, ker sem pisal članke o zmogljivosti baz podatkov na platformi DEC VAX. In zaradi tega so me povabili pisci podatkovnih baz. In pri meni se dogaja takšno, zakaj bi imeli bazo podatkov? V teh dneh je ogromno ljudi ustvarilo datoteke s ključnimi vrednostmi in jih uporabljalo za nekakšno zaporedje napak v indeksu, kot jih imenujemo, ampak za ustvarjanje neke vrste baze podatkov in veste, zakaj bi imeli še kaj?

In odgovor na to, mislim, da je Michael Stonebraker najboljši odgovor na to in dejal: "Baza podatkov lahko ve več o tem, kje so podatki, in kako hitro jih je mogoče pridobiti, kot jih lahko katerikoli program sploh ve." In mislim, da je to zanimivo; je narava igre. Toda v devetnajstem - približno leta 1989, ko sem začel s tehnološko analizo, in veste, takrat so bile baze podatkov zelo preproste, relacijske baze podatkov pa zelo preproste. Imeli so tako malo zmogljivosti, mislim, da bi lahko shranili podatke, očitno pa bi lahko varnostno kopirali in imeli, bili so združljivi z ACID, vendar so imeli res zelo šibke optimizatorje. Pravzaprav bi težko trdili, da so sploh imeli sposobnost optimiziranja.

Kasneje so postajali le boljši in boljši, toda, veste, ko baza podatkov ne deluje - kot se zdi, da so kenguruji tako ali drugače pokazali -, je lahko veliko razlogov, zakaj gre počasi. In to me pripelje do tega: baze podatkov imajo veliko funkcij, najpomembnejša pa je optimizacija poizvedb. Če tega ne bi storili, jih ne bi uporabljali. Gre za hitro pridobivanje informacij, za to, da lahko to storite, ko je veliko sočasnih uporabnikov, in to je težaven problem. Ko si dejansko ogledamo, jih poimenujemo zrele baze podatkov, če hočete - vsekakor pa Oracle v nekoliko manjšem obsegu, Microsoft SQL Server, zagotovo Teradata in DB2 - ki so jih dobili optimizatorji teh baz, že desetletja v stavba. Veste, niso - nekdo se ni usedel - šestih fantov na dve osebi, letnik, projekt in samo enega skupaj. Ne deluje tako. Zmogljivost za optimizacijo je postopoma rasla in potrebno je veliko naraščanja. Kakor koli, pogovorimo se o ozadju baze podatkov. No, zdaj je o podatkovni bazi NoSQL res veliko povedanega in celo navdušenje nad bazo podatkov grafov. In uporaba SQL prek Hadoopa in podobne stvari. Toda resnica je v tem, da če želite trenutno bazo podatkov, če želite popolnoma funkcionalno, sposobno za OLTP in velik poizvedbeni promet, je to relacijska baza podatkov ali pa nič.

Med relacijskimi bazami podatkov je priljubljena Oracle. Microsoft SQL Server je po mojem mnenju drugi. Oboje je mogoče uporabiti za OLTP in poizvedovati o obremenitvi, a dejansko se ne morete izogniti z mešanjem teh delovnih obremenitev. Za OLTP delovne obremenitve in poizvedovalne obremenitve potrebujete različne primere. Obstajajo druge možnosti za SQL in graf. Večina podjetij standardizira eno bazo podatkov, zato je - Oracle je po desetletjih boja z vsemi drugimi igralci postal najbolj prevladujoč. Preprosto zato, ker so na koncu prodali dovoljenja za podjetja, zato bi podjetja uporabljala le alternativne izdelke v izjemnih izdelkih, jih Oracle preprosto ne bi storil. In baze podatkov so strateške tudi v tem, da se razvijajo. In veste, da sem za to predstavitev malo raziskal, in nekako je - do nje bom prišel čez čas, vendar je nekako zanimivo, kako se razvijajo, če pogledam na to s položaja DBA. Temu pravim nevidni trend. Moorov zakon je na kocko. Približno takole: Največja baza podatkov je in nove baze podatkov še nimajo stare baze podatkov, ki bi imela zaužiti veliko več podatkov. Običajno je to baza podatkov, ki se uporablja za novo težavo. In dejansko rastejo glede na količino podatkov. Približno Mooreeva kocka pravo. Moorejev zakon je torej dejavnik desetkrat vsakih šest let. VLDB ponavadi rastejo na tisoč na vsakih šest let. Leta 1991, 1992 se velike baze podatkov merijo v megabajtih. Leta '97 in '98 gigabajtov. 2003, '4, terabajti. 2009, '10, začeli ste si ogledati baze podatkov petabajtov. Mislim, da sta bila trenutno tam ena ali dve podatkovni zbirki podatkov, vendar največ, kar sem že slišal, je 200 petabajtov pravočasno, in veste, da podatkov ne dobimo v baze podatkov petabajtov. Toda večinoma gre za to, da bodo očitno nova velika spletna 2.0 podjetja, morda imate Facebook naslov v tej smeri.

Kakor koli, če dejansko pogledate na to, če pričakujete, da bo baza podatkov dosegla takšen obseg obsega, veliko zahteva. In presenetljivo je, da vse do stopnje petabajtov izgleda, da so se dobro odrezali. Hočem reči, da govorim o starejših izdelkih kot pa o nečem novem. Zdi se, da so naredili izjemno dobro. Če pogledamo uspešnost baz podatkov, ozka grla, me to vrne v čas, ko sem dejansko skrbel za njih, in moral sem skrbeti zanje. Veste, da je to v bistvu okvara strojne opreme. Mogoče obstajajo ozka grla procesorja, morda obstajajo ozka grla pomnilnika, morda obstajajo ozka grla na diskih. Lahko je tisto omrežje, ki vam povzroča žalost, prav tako pa lahko imate težave z zaklepanjem, odvisno od tega, kaj počnete, običajno pa zato, ker program ne ve, koga poklicati zaklepanje. Če torej nastavite bazo podatkov, jo pravzaprav poskušate prilagoditi tako, da pleše med temi petimi možnimi ozkimi grli in tudi lahko. In to ni enostavno, saj se količina pomnilnika, ki ga lahko konfigurirate na katerem koli strežniku, močno poveča. Potem so procesorji postali večjedrni, diskovni, kar lahko zdaj storimo, mislim, tudi na robnih strežnikih, mislim, da lahko naredite na stotine in sto terabajtov, četrtino petabajtov, morda celo na blagovnem strežniku. Torej, pri vseh teh stvareh, s katerimi se lahko igrate, omrežje lahko seveda poteka z različnimi hitrostmi, a večinoma, ko imate opravka z bazami podatkov, resnično želite, da med strežniki obstajajo vlaknasti kabli in nič drugega, kar deluje na tem tako.

Dejavniki baze podatkov Mislim, puščam, za kaj gre, saj vem, da se bo Dez o tem pogovarjal, vendar slaba zasnova podatkovnih baz pomeni slabo delovanje baze podatkov. Slaba programska zasnova lahko pomeni, da bi na bazo podatkov vrgli zelo neumen SQL, kar bo trajalo res veliko dlje. Mešanje sočasne valute in delovne obremenitve bo preveč sočasnosti povzročilo težave z omejevanjem ozkosti. Mešanje delovne obremenitve, ko imate velike poizvedbe z zelo majhnimi, kratkimi, ostrimi poizvedbami, kar povzroča težave. Težava z izravnavo obremenitve. Za to poskrbi večina baz podatkov, če pa nimate prefinjenega izdelka, potem veste, da samo dodajanje nekaj strežnikov ni vse, če želite dejansko povečati velikost grozda. Preden dosežete optimalno zmogljivost, morate dejansko uravnotežiti obremenitev. Načrtovati morate načrtovanje zmogljivosti. Vsekakor. Zlasti zdaj v teh dneh, ko se količina podatkov drastično poveča, kot je bila navada za baze podatkov. Obstajajo težave s celotnim podatkovnim slojem, kako zaužijete podatke, kako premikate podatke. Če pravočasno ne dobite podatkov v bazo podatkov, je lahko kasneje težava z zmogljivostmi, saj smo prešli od baz podatkov, ki delujejo v operacijskem sistemu Windows, na štiriindvajset, sedem, tristo, sedeminpetdeseto delovanje in ni oken, na katerih bi lahko upočasnili baze podatkov ali pa je malo verjetno, da jih bo danes.

Problem Oracle DBA. O tem sem razmišljal. Bil sem v Oracle-u DBA z Oracle 7 in se spomnim, kako to prilagoditi. In če zdaj dejansko gledate na Oracle, je način, način - način, način več zmogljivosti. Ima indeksiranje bitnih slik in podobne stvari, toda dejansko sem si vzel čas in si ogledal, koliko nastavitvenih parametrov je trenutno v bazi Oracle. Obstaja več kot tristo petdeset nastavitvenih parametrov in še sto skritih parametrov, o katerih strokovnjaki DBA morda vedo, a običajni Oracle DBA ne vedo. In to pomeni, da je uglaševanje tovrstne baze podatkov težka stvar. To sploh ni preprosta stvar. Moraš imeti občutek za to, to moraš početi že dolgo, dolgo in natančno moraš vedeti, kaj težavo misliš, da rešuješ, ker se uglasitev začne, ko zmogljivost postane slaba, vendar morda vse to ni uspešnost. Morda so pomembne izvedbe določenih poizvedb in jih boste morda lahko odpravili s pripenjanjem določenih podatkov in pomnilnika ali pa boste morda morali popraviti z indeksiranjem ali pa boste morda začeli delati particijo na drug način. V tem, kar lahko storite, je bistvo. Posledično tega ne bodo storili v glavi - DBA potrebujejo orodja. Zdaj bom prenesel Dezu, ki vam bo povedal o indeksiranju.

Eric Kavanagh: V redu, Dez, vzemi ga.

Dez Blanchfield: Hvala, Robin, in rad imam naslovnico. Mislim, da si me vrgel gorico, da sem prišel celo oddaljeno blizu nečesa vznemirljivega. Vendar sem uporabil sliko naše male galaksije, kot svoj pogled na to, v kaj se je današnji izziv za skrbnike baz podatkov spremenil, ker je to miselna podoba, ki jo ponavadi pričaram, ko zaidem v okolje in nisem več v svetu upravljanja podatkovnih baz ali oblikovanja baz podatkov na tej ravni. Ampak kot vi, sva z Robin že vrsto let sodelovala v svetu baz podatkov bodisi kot skrbnik ali razvijalec ali sčasoma arhitekt, nato pa ugotovila, da lahko naredim boljše stvari, da si zaslužim skorjo. Ponavadi je videti, kot da buljite v to galaksijo podatkov, še bolj pa danes, ko odhajamo, kot ste omenili, v zelo kratkem času prešli od megabajtov do petabajtov in ekso-obsega., v veliki shemi stvari. Toda stavek, ki ga imam v mislih, je, da so indeksi podatkovnih baz zdaj črna umetnost in v resnici niso takšne stvari, ki bi jih morali navaditi samo smrtniki, za poslovne aplikacije podjetij in vrsto njihovega oblikovanja so samo govorili. Ampak želel sem iti skozi hiter razplet vrste zgodovine, ki sem jo imel s svetovi baz podatkov, in se spraviti v kontekst, kjer bomo sklepali, in nato danes s prijatelji obiskati nekaj gradiva IDERA, ker mislim, da je veliko različnih razmišljanj o tem, kako doseči uglasitev zmogljivosti baze podatkov in eden od njih je metanje kositra na stvar. V številnih trgovinah, na katere naletim, vedno ne pridejo do tega, da izvajajo nastavitve zmogljivosti na ravni baze podatkov, še posebej na indeksni plasti, dokler ne prebijejo trde poti razmišljanja, da bi lahko nanjo vrgli tuner. .

V mislih je veliko ljudi, ki se zelo zavzemajo za železen pristop, in tu imam sliko The Flash, ker če ste že kdaj gledali stare filme ali zagotovo zadnjo TV oddajo s filmom Flash, kot v Flash Gordon, stari lik, in zdaj, ko se imenuje "Flash", ponavadi gre zelo, zelo hitro in vedno mu zmanjka energije. In to se zgodi, ko mečete veliko železo pri zmogljivosti baze podatkov. Po mojih izkušnjah lahko v igro vložite visoke zmogljivosti, trdo delo, optimizirate svoje operacijske sisteme in jih prilagodite na določeno točko. Zagotovite lahko, da imate hitre večopravilne, več zaporedne procesorje, da se aplikacija zažene hitreje, nanjo lahko vržete veliko RAM-a, lahko imate ozadja z visoko prepustnostjo, lahko greste od trdih diskov do predpomnjenja trdih diskov v trdno stanje in visoko zmogljiv niz shranjevanja. In tudi zdaj ljudje v svoje baze podatkov bazirajo stvari, kot sta flash in NVMe, misleč, da bodo to prijavo dobili dvakratno povečanje učinkovitosti. In vedno dobijo nekaj dobička. Vendar se vse vrne k istim težavam z nastavitvijo zmogljivosti. Veliko mrežnih povezav z nizko zakasnitvijo, tako da grozdi delujejo hitro. In združevanja infrastrukture baze podatkov, tako da imate več kot le en stroj, ki opravlja vse delo. Vendar se vsekakor vračate k isti osnovni težavi z uspešnostjo in to je branje podatkov. Pisanje podatkov je večinoma dokaj linearen izziv in razen če je opravljeno pravilno.

In potem imamo izziv v današnjem svetu: niso vse baze podatkov ustvarjene enako. Obstajajo baze podatkov in "baze podatkov", ko razmišljamo o motorjih baz podatkov, ljudje pogosto pomislimo na tradicionalne, običajne osumljence, kot so bili v svetu SQL. Veste, imamo Oracle in Microsoft SQL Server, v odprtokodnem svetu pa je nekaj skupaj z MySQL, ki je zdaj v lasti Oracle, vendar je še vedno odprtokodni. In potem imamo ne tako običajne osumljence, motorje NoSQL, ki imajo še vedno težave v zvezi z indeksiranjem in upravljanjem zmogljivosti, in ne bom se spuščal v njih veliko podrobnosti, vendar je vse več teh stvari se pojavljajo vsak dan in z vidika razvijalcev in z vidika zmogljivosti so videti kot motorji podatkovnih baz, vendar so zelo, zelo različne zveri in imajo svojo majhno nišo na svetu, ki jo lahko izklesajo bodisi zmogljivost v pomnilniku ali linearna lestvica na disku. Toda tako izgleda svet v svetu baz podatkov. To je leto 2016, to je različica tri zemljevida različnih ljudi, ki ustvarijo ta trenutni pokrajinski zemljevid, kako izgledajo baze podatkov, in to je to - tudi superhuman arhitekt baze podatkov ali skrbnik baze podatkov ne bi imel smisla od tega. Dobesedno na stotine in stotine in stotine različnih znamk, modelov, proizvajalcev baz podatkov, ki so vedno skladni s SQL. In zanimivo je, da se vsi vračajo k istemu izzivu. Učinkovitost in uglaševanje zmogljivosti okoli motorja baze podatkov, zlasti glede na to, kako so podatki indeksirani.

Zato na hitro opišimo indeksiranje baz podatkov, saj je to zanimiva tema, pri čemer morate verjeti, da se podrobneje seznanite s predstavitvijo. Vendar menim, da je precej dobro sprejeta in običajna industrijska praksa, da je prilagajanje uspešnosti indeksov baz podatkov tam, kjer se začne svet in konča, do zagotavljanja, da so vaši podatki dostopni v hitrem in hitrem formatu. Toda kaj je indeksiranje baz podatkov? Če razmišljamo o indeksiranju v obliki, ki smo je navajeni kot vsakdanje ljudi, pomislimo na indeksno stran v knjigi. Če želite v knjigi najti nekaj - zlasti všečke enciklopedije ali nekaj podobnega referenčnega gradiva neke oblike -, če iščete kaj takega na tej strani, kjer iščem stvari, kot je tema dam v enciklopediji. Želim najti vsako omembo jezov, zajetja vode in velikega območja kopičenja, ki ga ustvari človek. Pojdem nazaj, najdem ga po abecednem vrstnem redu, razvrščenem seznamu, od A do Ž, od leve proti desni, in poiščem D. Poiskal bom besedo "dam" in to lahko vidim na na straneh 16, 38, 41 se sklicuje nanje, potem pa lahko pojdem na te strani, lahko skeniram oči in najdem sklic na besedo "dam." To je v bistvu isti koncept v bazi podatkov, vendar je zdaj raketna znanost na več načinov. Toliko o tem, da dejansko vsak skrbnik baz podatkov, ki sem ga kdaj dobro spoznal, meni, da so indeksi najbolj kritično orodje za uravnavanje zmogljivosti v katerem koli svetu baz podatkov, ne glede na to, kakšna je njihova izkušnja z metanjem kositra nanj, ali ne glede na primer.

Na splošno, ko govorimo o indeksiranju baz podatkov, obstaja več skupnih pristopov. In bolj zapleteni indeksi baz podatkov postanejo bolj zapleten pristop k indeksiranju podatkov. Ampak v bistvu, ko razmišljate o indeksiranju podatkov - predstavljajte si, da imamo datoteko s seznamom imen; niso razvrščeni po abecednem vrstnem redu. Predstavljajmo si, da jih je dvajset. Če bomo razvrstili - če bomo iskali podatke na tem seznamu, od zgoraj navzdol, in recimo, da je to seznam imen. Če izberem naključno ime in se po seznamu začne vrteti navzdol, v linearni obliki in je neurejen seznam, se mi zdita dva merila kot moj povprečni čas iskanja in moj največji čas iskanja - in V drugi vrstici imam napisano napako, naj bo "najdaljši čas iskanja", žal mi je, toda moj povprečni čas iskanja je v bistvu N plus en, razdeljen na dva, in to je v povprečju, vzame mi petdeset odstotkov časa če želite skenirati od vrha seznama, na dno seznama, da najdete katero koli naključno stvar na tem seznamu. Druga vrstica pod linearno bi morala biti "najdaljši čas iskanja." Najdaljši čas iskanja pa je v bistvu število predmetov in to je, če imam seznam dvajsetih stvari, da mi lahko največ časa vzame iskanje nečesa v tej bazi podatkov pomeni, da gremo od vrha do dna, kar je recimo 20 elementov v tem poenostavljenem primeru. In to je zelo počasen postopek in resnično ni mogoče, da se to prilagodi. Potem pa obstajajo druge vrste načinov zajemanja teh podatkov in ustvarjanja indeksa, kar je dejansko kratek seznam kazalcev, kje so dejanski podatki, na primer binarni zapis, B-drevo, bitmap, hashing, grozdi in niso v gručah, in potem so tu različne vrste podatkov, kot so prostorski, filtrirani, XML in polno besedilo.

Binarna različica je zelo pogosta uporaba pri stvareh, pri katerih se ji podatki izpostavijo. B-drevo je verjetno najbolj razširjeno v splošnem smislu, v zgodovini je to, da gre za običajen način strukturiranja indeksa v katero koli obliko podatkov in omogoča, da se zapisovalci, izbire in vstavitve in izbrisi sorazmerno enostavni, ko premikate kazalce okrog sklicevanje na kazalce, točke. Obstajajo druge vrste, na primer bitmap, pri katerih se tipi podatkov nanašajo na primer, če imamo povezan obseg neke oblike. Hashing deluje zelo dobro za velike predmete, zlasti bloge in slike. In vidite, da obstaja veliko različnih vrst znanstvenih pristopov, matematičnih pristopov k indeksiranju podatkov. Za zgolj smrtnike so zanimiv izziv, na katerem se lahko pogovarjajo na tej ravni. Ko o tem na ravni zmogljivosti spregovorite za skrbnika zbirke podatkov, resnično postanejo raketni znanstveniki in ljudje delajo diplome v njih, in vem, da je to zagotovo storil tudi doktor Robin Bloor in o tem napisal knjige za všeč IBM in druge velike blagovne znamke v zadnjih nekaj desetletjih. In tako - po mojem mnenju je, da smo pravzaprav pretekli čas, ko bi, veste, nekoč osebno lahko sedel pred sistemom in bi ga lahko razstavil in pokazal natančno tam, kjer so bile težave z zmogljivostjo v ukazni vrstici ali orodju za zagon grafičnega uporabniškega vmesnika, in začnite poglabljati podatke in vam povedati, kje so bile težave, in vgradite indekse, podindekse ali primarne in sekundarne indekse v to Podatki in jih začeli uporabljati za iskanje stvari. Ko pa pomislite na to pokrajino, sem vam pokazal, kjer imamo na stotine in sto znamk, znamk in modelov ter proizvajalce in vrste baz podatkov, smo že resnično pretekli čas, kjer človek lahko naredi občutek za vrste motorjev baz podatkov, ki jih imamo. Še posebej, četudi se le vrnemo k všečkam Oracle, ki prevladujejo blagovne znamke v teh dneh na relacijskih platformah baz podatkov.

Število baz podatkov, s katerimi se morajo spoprijeti bodisi z lastniško platformo, kot je ERP, HR ali finančni sistem, bodisi, da so iz različnih razlogov domača platforma, število baz podatkov in tabel baz podatkov ter zapisov, ki jih končamo ukvarjanje je samo astronomsko in fizično tega ne morete storiti ročno. Zdaj smo se še dodatno zapletli, ko je nekoč strežnik baz podatkov lahko le sedel pod vašo mizo. Veste, kot majhen otrok sem po šoli hodil in delal programsko opremo za baze podatkov v prvotno Apple IIes in nato sistemih, ki temeljijo na računalniku DOS, kot so dBase II, dBase III, šel skozi obdobje z mainframom in sredi oz. obseg in celo VAX-ji in PDP-ji ter datoteko dnevnika. In podobno kot Saber in nato na koncu, ko so se pojavile nekatere zbirke podatkov SQL. Toda v teh dneh, ko razmišljamo o motorjih baz podatkov, so videti kot spodnji levi vogal. Strežnik baz podatkov ni samo en stroj, ki sedi na tleh pod mizo; gre za na stotine naprav, ki poganjajo kopije motorjev baz podatkov in grozdov, ki merijo do sto in sto terabajtov podatkov, če ne petabajtov podatkov, kar je na tisoče terabajtov. In celo do skrajnosti, kot je omenil doktor Robin Bloor, lahko nekateri konkretni primeri uporabe - letalske družbe, zlasti vladne agencije - pridejo do izhoda. Še vedno so dokaj niš-y, toda na stotine terabajtov in celo več deset petabajtov ni več nič nenavadnega, še posebej od dotcom booma do zdaj, kar imenujemo spletna podjetja 2.0, kot so Facebook, Google, Yahoo in tako naprej.

Zdaj se zapletamo tudi, ko stvari prehajajo na zunanjo storitev. Infrastrukturno platformo in programsko opremo imamo kot pristop k zagotavljanju infrastrukture. In še posebej storitev na platformah, kjer ne moremo kupiti le za Oracle in njihovo oblačno platformo, baze podatkov in strežnike. In to nam omogoča zelo hiter razvoj aplikacij in samo povezovanje baze podatkov v strežnike. Ni treba razmišljati o tem, kaj je pod pokrovom. Slaba stran je, da pogosto ne razmišljamo o tem, kako zasnovati in izvajati bazo podatkov nazaj, dokler ne začne škodovati in učinkovitost ne postane težava, nato pa moramo iskati pravo orodje za diagnozo, zakaj naša baza podatkov boli in kjer so vprašanja o uspešnosti. In vedno znova to pripelje do skupnega problema tega, kako smo indeksirali te podatke in vrste indeksov, ki smo jih uporabili za te podatke, in nas nato vrnili k nadčloveškim zahtevam glede uspešnosti. In nekdo, ki ima dostop do pravih sistemov in pravih orodij za uglasitev teh motorjev, začne iskati žarišče in pogledati, kje so poizvedbe, kam se podatki premikajo, vrste poizvedb, kako so poizvedbe strukturirane, kdo poizveduje in ali so poizvedbe v vrsti in jih je treba predpomniti. Kakšno kopijo iščete?

In zato smo po mojem mnenju dobro in resnično - zdaj, ko tudi najboljši svetovni guruji baz podatkov, v bistvu naši arhitekti baz podatkov in naš skrbnik baz podatkov ter baze delovanja, po mojem mnenju zelo potrebujejo, da začnejo uporabljati prava orodja za zagotavljanje optimalne nastavitve indeksa zmogljivosti za kateri koli motor baze podatkov. Ker obseg, s katerim se ukvarjamo, in hitrost, s katero se stvari premikajo, tega enostavno ne moremo storiti z roko in poskusi tega nenehno lahko uvedejo druge težave glede uspešnosti, saj morda v tem prostoru nimamo izkušenj, poskušamo rešiti težavo. In verjamem, da bomo tu namenili Bertu, in govorili bomo o tem, kako so rešili ta raznolik problem in o vrsti stvari, ki jih lahko njihovo orodje naredite, zlasti za svet Oracle. In s tem tam, Bert, te bom prenesel.

Bert Scalzo: Hvala. Dobrodošli vsi, moje ime je Bert Scalzo, delam za IDERA. Sem višji vodja izdelkov za nekatere izdelke iz naše baze podatkov. Danes bom demonstriral nekatere od teh. Želim pa govoriti o indeksih, ker se strinjam z vsem, kar so tukaj povedali vsi, zlasti na zadnjem diapozitivu, da so indeksi tako zapleteni zdaj, da potrebujete orodje, in upam, da vas bom prepričal. Torej oblikovanje indeksa Oracle ni tako enostavno, kot nekoč. Veliko ljudi ne bo prepričalo vase, ko bodo gledali na možnosti, in všeč mi je ta rek, ki sem ga potegnil iz zgodovine, "v teh zadevah je edina gotovost, da nič ni gotovo." In tako sem nekako Te indekse počutite v teh dneh, saj tudi če menite, da veste, da bi odgovorili nanje, bi morali indeksirati X, Y ali Z, res ne morete biti prepričani, dokler ne preizkusite, saj se ti optimizatorji včasih obnašajo drugače, kot pričakujete. In tako je pri oblikovanju indeksov veliko preizkusov in napak. Zdaj, v dobrih starih časih, če bi potrebovali indeks, sta bili na splošno samo dve vprašanji ali eno vprašanje. Je bil edinstven ali ni bil edinstven? In morda ste pomislili na druge stvari, na primer: "Koliko indeksov lahko imam največ v eni tabeli?", Ker preveč indeksov upočasni vaše vstavke, posodobitve in brisanje. Mogoče ste bili tudi v sistemu podatkovnih baz, imeli ste omejitve, koliko stolpcev je lahko v indeksu več stolpcev, ker so včasih obstajali omejitve glede na velikost strani ali bloka vašega motorja baze podatkov, v resnici pa je bil precej preprost nazaj v dobrih starih časih. Ali ste ga indeksirali ali pa niste. In res je bilo vse v B-drevesu. Dvojnike bi lahko dovolili ali ne, in o tem je šlo. Življenje je bilo dobro, življenje preprosto.

No, danes življenje ni tako dobro ali tako preprosto. Rdeči znak Ghostbuster sem postavil na način, kot smo ga včasih, saj imamo zdaj B-drevo proti bitmapu in bitmap. In razložil bom, kaj od tega je v trenutku. Grozdni in neprustrirani, enolični ali podvojeni, naprej ali v obratnem vrstnem redu, na osnovi funkcij, particionirani ali nerazdeljeni. Če gre za particijo, gre za globalno ali lokalno particijo? To bom tudi razložil. In potem tudi nekaj, kar imenujemo indeksirana organizirana tabela. In pravzaprav sem tukaj odšel pol ducata, ker mislim, da jih imam zdaj že dovolj, kar bi vas moralo prepričati, da so indeksi veliko strožji, kot ste morda mislili. V tem posebnem diapozitivu bom začel v zgornjem levem delu diagrama in dobil sem tabelo. In prva stvar, ki se je moram odločiti, je, ali odvisno od različice vaše baze podatkov in prodajalca baze podatkov dovolijo tabele predmetov ali so samo relacijske? Šel bom po desni strani in rekel, da gradimo relacijsko tabelo. Naslednje vprašanje, ki si ga moram zastaviti, je, ali je to v grozdu? In veliko vas, ki ste že nekaj časa opravljali Oracle, se bo spomnilo, da so se grozdi vrnili za Oracle 6 dni. Verjetno jih danes več ne uporabljajo preveč, ampak naj najprej spustim to vejo.

Če bi mizo postavil v gručo, bi moral imeti na tej mizi gručasti indeks. Zdaj ste v Oracleu, ko ste združili tabelo, v bistvu shranjevali vrstice ali so bile vrstice blizu drug drugemu, kjer so bile vrednosti podobne. In tako moraš imeti indeks v gruči, in da bi lahko združeni indeks ostal nerazdeljen. Z drugimi besedami, ni bilo res nobenih načinov razdelitve, kako bi naredili razvrščeno tabelo. Bilo je strogo nerazdeljeno. In ker je bila nerazdeljena, je bila globalna. Bom razložil, kaj je globalno čez minuto. In vedno je bilo B-drevo. Z drugimi besedami, ko sem šel po tej veji, je bilo precej preprosto, nisem imel veliko izbire. Zdaj, če sem naredil nekrustriran indeks na grundirani tabeli, kar je bilo dovoljeno v nekaterih različicah, je bil spet nerazdeljen; kadar ni razdeljen, potem je vaša edina izbira globalna. In tako, tam imate na izbiro B-drevo ali bitmap. Spet je bilo odvisno od vaše različice baze podatkov. A zdaj se vrnimo nazaj do relacijske mize in začnite znova padati po desni strani in zdaj bomo imeli navadno, staro, redno mizo: relacijsko. To bo v prostoru za mize. Tu se nekako spusti po desni strani. Torej, to je organizacija, kup. Naslednje vprašanje, ki si ga moram zastaviti, je: „Ali želim to tabelo razdeliti ali ne?“ Zdaj bi včasih razdelili, ker ste mislili: „Ej, optimizator bo pametnejši, kako lahko optimizira poizvedbe. "Toda veliko DBA bo povedalo, da je vaš razlog za administrativne namene. Če imate tabelo s sto milijardami vrstic, če jo razdelite na predelne stene ali vedra, ko želite dodati podatke v zadnje vedro, lahko spustite in indeksirate le nekaj milijonov vrstic. Lahko vstavite te podatke in nato lahko ponovno sestavite ta indeks samo v tem vedru.

Čeprav je bila za nekatere dobra tehnika, optimizacijske tehnike, kot je odstranjevanje particij, je bila njegova resnična vrednost zmožnost upravljanja ali opravljanja administrativnih nalog v manjših delih. Ko grem na organizacijsko kopico, je bilo prvo vprašanje: "Ali sem ga razdelil ali ne?" Pojdimo na levo, ne bom razdelil mize. Zdaj se vam lahko zdi čudno, ko vam to povem, vendar bi lahko imeli tabelo, ki ni particionirana, in indeksa ne morete razdeliti tako, kot ste navajeni, ali pa lahko indeks razdelite. Ustavite se in pomislite. Vaša miza ima v bistvu eno vedro, kot ste vedno mislili, in kljub temu bo imel vaš indeks več vedra. Ko se to zgodi, če obstaja neskladje med številom veder in tabele in številom veder v indeksu, to pomeni globalno. In če tabela ni razdeljena in če je indeks razdeljen, velja za globalno, ker obstaja neskladje. Zdaj pa naj se vrnem gor na svojo organizacijsko gručo in se spustim namesto na particijo. Zdaj, če imam predelno tabelo in recimo, da ima tabela štiri vedra, štiri particije, bi lahko moj indeks imel štiri vedra, tako da se moj indeks ujema z mojo tabelo. In tako je na desni strani konec. To bi veljalo za lokalno. Lokalni indeks pomeni v bistvu, da se razdelitev tabele in indeksa izvede na enak način in ima enako število vedra. In potem, ko imam lokalni indeks, bi to lahko bilo B-drevo ali bitmap in če se ta zelena puščica dvigne, vam pokaže, da tudi če je B-drevo, lahko še vedno izbiramo. Lahko bi temeljila na funkciji. In tudi, če gre za bitne slike, obstajajo različne vrste bitnih slik. Nekaj ​​se imenuje indeks pridružitve bitne slike. Če hranite podatke, je to zelo priljubljen indeks za zvezdno shemo ali oblikovanje. Zgodilo se je, da ima indeks ID-je vrstice za tisto, na kar kaže v tabeli, vendar bo imel tudi ID-je vrstic za nadrejene tabele, tako da, ko ste - morate zasnovati načrt sheme in iščete v tabeli dejstev ta indeks na tabeli dejstev kaže na podatke, ki vas zanimajo, in vas usmeri na vsako vrstico v vaših dimenzijah, tako da morate imeti samo en indeks.

In pravzaprav je to nastalo zaradi Red Brick-a, ki je bil pred mnogimi leti baza podatkov - veliko ljudi se tega morda spomni. In če pogledate to sliko - in ne pozabite, da na to sliko nisem vsega postavil, ker bi bila slika veliko večja - še vedno obstajajo dodatne težave, o katerih imam v besedilu tukaj zgoraj desno . Ali gre za indeks obratnega vrstnega reda? In lahko bi rekli: "Zakaj bi si želel indeks obratnega vrstnega reda? To nima nobenega smisla. "No, če ste v grozdnem okolju v Oracleu, če delate prave grozdaste aplikacije, če ohranjate svoje indekse v redu, tako da ni obratno, če imate veliko obdelave, ki je hit iste vrednosti ali iste vrednosti indeksa, kar bi se zgodilo, bi imeli vroča območja vašega B-drevesa. To pomeni, da bi imeli prepir in morda zaklepanje, da bi poskusili in dostopali do teh stvari, in to bi počeli prek vozlišč v omrežju. No, če vstavite indeks obratnega vrstnega reda, lahko to zdaj razveljavite. Lahko rečete: "No, podobne vrednosti so v različnih delih dreves, zato nimam svojih ločenih vozlišč, ki tekmujejo za vroča območja na drevesu." In potem tudi opazite, da edinstvena ne deluje z nekaterimi možnostmi . Če pogledate, sem oštevilčil tri, pet, osem in enajst, zato je nekaj primerov, ko ne morem imeti enoličnega indeksa. Prav tako obstajajo nekateri primeri, ko ne morem imeti povratnega indeksa, potem pa obstajajo dodatne težave, kot so beleženje ali brez beleženja, vzporedno in ne vzporedno. Stvari lahko dodelim določenemu področju v spominu.

In to izpušča še kar nekaj funkcij v Oracleu. Rekel bi, da ko pogledam Oracle 12, je verjetno spet približno pol ducata, ki bi jih lahko dodal tej sliki. Indeksiranje je resnično zapleteno in resnično se strinjam s predhodnim govornikom. Če želite krmariti po tem in se dobro odločiti, potrebujete orodje. Morda boste potrebovali takšno sliko in nekakšno metodologijo, kako boste izbrali stvari in upajmo, da vam bo orodje pomagalo priti tja. In potem bo poskus in napaka. Ljudem pri indeksiranju vedno rečem: "poglej, preden skočiš." In potem lahko tukaj vidiš malega psa, skače, ne da bi pogledal, bo z morskim psom končal v vodi ali pa se človek pripravlja skočiti v vodo, in napihnil se bo. Morate razmišljati o indeksiranju, ker ustvarjanje indeksa ne pomeni vedno, da se stvari izboljšajo. Pravzaprav lahko ustvarjanje indeksa upočasni stvari. Učinkovitost poizvedb je lahko za en vrstni red boljša. In bom dal dober primer. Če delate zvezdno shemo oblikovanja in v tabelah dimenzij uporabljate indekse bitnih map v enem primeru, v drugem primeru pa rečete: "Uporabil bom indekse B-drevesa", imate bitmap v primerjavi z B- drevo. Lahko vam povem, da bo ena rešitev vrstnega reda ali morda več vrst velikosti hitrejša od druge. Vendar ne pozabite, kaj deluje v enem okolju, na primer v okolju za shranjevanje podatkov, v okolju OLTP verjetno ni dobra izbira.

Na primer, če bi vzeli tabelo transakcij in postavili indekse bitnih slik na transakcijsko tabelo, je drago izračunati in ponastaviti bitne slike, te dolge nize in tako v OLTP tabeli, lahko udarite v tabelo tako močno, da je bitmap indeks lahko postane poškodovan in upočasni vaš sistem, ker preprosto ni namenjen posodobitvam. Odlični so za hiter dostop, vendar niso dobri za posodobitve. Mislim, da ima indeks poskus in napake. Zlatega pravila res ni več - v tej enačbi je preveč različnih spremenljivk, in na koncu boste morali pogledati izvedbo ali razložiti načrte v svoji bazi podatkov, če želite videti, ali izbirate dobro ali ne. In včasih je analiza načrta skoraj lahko sama sebi znanost. Danes tega ne bom pokrival - to je že druga tema -, vendar oblikovanja indeksov ne jemljite kot samoumevno. Obstajajo utemeljeni razlogi, zakaj obstajajo vse te nore vrste indeksov, ki sem vam jih prikazal na prejšnji sliki in o katerih je govoril predhodni govornik. Te niso bile ustvarjene samo zato, ker je bila čedna funkcija, da bi nekje na prodajalcu baze podatkov postavili kontrolni seznam; obstajajo primeri uporabe ali scenariji, kjer so ti indeksi pomembni in bodo bistveno vplivali. Zdaj vam bom pokazal nekaj primerov različnih vrst indeksov v enem od naših orodij. Dovolite mi, da zaslon postavim, da ga boste lahko videli. V redu, torej tukaj sedim - dovolite, da to aplikacijo čim bolj zmanjšam. Sedim znotraj VMware-a in izvajam sistem Windows Server 2012.

In vidite, imam skoraj vsako orodje, ki ga človek pozna. Kot produktni vodja se moram zavedati svoje konkurence, zato ne gre samo za to, katera orodja imam, ampak kaj počnejo moji konkurenti? In tukaj imamo to orodje imenovano DBArtisan, ki sem ga že sprožil, vendar grem - zato ga bom samo predstavil. In to lahko vidite, da je to res lepo orodje, saj namesto da bi ga morali uporabljati, recimo vodja podjetij za Oracle in Studio za upravljanje SQL za SQL Server ter MySQL Workbench za MySQL in dvanajst drugih baz podatkov, ki jih podpiramo, dobro imam vse svoje zbirke podatkov vgrajenih v to eno orodje. Tu je DB2, obstajajo MySQL, Oracle, Postgres, SQL Server in Sybase, in to je - v tej konkretni stvari imam samo šest baz podatkov, ker ne morem - orodje podpira dvanajst baz podatkov, toda moj slabi VM, ki hkrati poganja šest baz podatkov in poskuša narediti predstavitev, je približno toliko, kot bo olajšala moja strojna oprema. Naj se zdaj vrnem nazaj v Oracle in če opazite, so vse te stvari enake. Če želim izmeriti svojo uspešnost v DB2, gre za enake odločitve kot jaz. Zdaj pod platnicami počnemo veliko različnih stvari, tako da vam ni treba vedeti, kaj se dogaja, mi pa vam dajemo dosleden vmesnik, da boste lahko strokovnjak z več platformami baz podatkov. In to bi vključevalo delo z indeksi, tema te razprave.

Naj pridem sem in naj najprej začnem s pregledovanjem nekaterih tabel, in imam bazo filmov, ki ima le nekaj tabel. In če pogledam določeno tabelo, na primer tabelo strank, ko jo pripeljem sem, vidim zasnovo mize, tukaj so moji stolpci in tukaj so podatki o vsakem stolpcu. Za tabelo imam lastnosti, vendar upoštevajte, da imam tukaj zavihek za indekse in lahko vidim, da so indeksi na tabeli. Upoštevajte, da je eden od teh indeksov moj PK indeks, moj primarni ključ. Te druge so videti le kot indeksi za izboljšanje dostopa do poizvedb, morda poizvedujemo po imenu ali priimku ali pa pogledamo telefone in poštne številke. In če tukaj izberem določen indeks, kot je ta poštna številka, in dvokliknem nanjo, zdaj vidim, hej, to je unikatni indeks in tukaj je še nekaj drugih vrst, bitmap, unikatno, edinstveno, ne glede na to, ali je razvrščeno ali ne, ne glede na to, ali je to beleženje, ne glede na to, ali je v obratnem vrstnem redu, ne glede na to, ali gre za bazo funkcij. Oh, tukaj je zabavno, ki ga nisem skrival. Pravzaprav lahko imate nevidne indekse. In rekli bi: "No, zakaj bi za vraga želel narediti neviden indeks?" Ste v svojem proizvodnem sistemu in imate težave z zmogljivostmi in niste prepričani, da bo ustvarjanje indeksa odpravilo težavo, zato ne želite ustvariti indeksa in upočasniti proizvodnje, ampak nekako ali drugače želite biti sposoben preizkusiti. Indeks v proizvodnji lahko ustvarite kot neviden, kar pomeni, da ne bo veliko aplikacijske kode, ki kliče orodje za optimizacijo, uporabil ta indeks. Ustvarjeno je, veljavno je, vendar ga ne bomo uporabljali. Potem lahko vzamete poizvedbo, za katero mislite, da bi ji ta indeks pomagal, ali vrsto poizvedb, in lahko vstavite namig in rečete: "Hej, optimizator, tam je neviden indeks. Želim, da ga uporabite in pustite vem, ali sem stvari izboljšal. "In zdaj sem nekaj preizkusil v proizvodnji, vendar še nisem prekinil aplikacij v proizvodnji, ki so se izvajale. To je uporaba za neviden indeks. Nevarno se sliši, ko prvič slišiš za to, vendar ima to koristi.

Na indeksih lahko tudi določimo, ali so vzporedni, in tudi, koliko primerkov je vzporednih. Zdaj bi v nestorjenem ali neresničnem aplikacijskem grozdnem okolju, torej ne-rack, vzporedna pomenila, koliko podprocesov lahko sproži moja poizvedba, da poskusim, in delavski procesi, da bi poskušali hitreje ali hitreje rešiti stvari. . In vzporedni primeri bi bili, če sem v resnični aplikacijski grozdu, recimo, da imam deset vozlišč, koliko vozlišč mi je dovoljeno, da delo razdelim na vse? Mogoče gre za štiri od desetih in na vsakem od njih štiri podprocese. To je primer. In potem imamo stiskanje tipk. Lahko dejansko stisnete indekse? Ja ali ne. In potem seveda imate svoje pomnilniške parametre, ki jih lahko določite v indeksih. Zdaj jih nisem zajemal, ker so resnično več pomnilniškega parametra kot izdaje indeksa. In potem končno imamo, ali bomo te particionirane ali nerazdeljene naredili ali ne. Naj za trenutek spustim tukaj. Grem na drugo shemo. To je shema zvezd in na primer ta tabela obdobij je tabela dimenzij. Če ste kdaj naredili zasnovo zvezdne sheme, imate običajno razsežnost za čas in tako v tej bazi podatkov in tej shemi zvezdic je obdobje časovna razsežnost. Zdaj vem, da bo videti smešno. Rekli boste: "Gee, poglejte vse te stolpce - je človek že kdaj slišal za normalizacijo?" No, ko ste v skladišču podatkov ali v obliki zvezdaste sheme, ponavadi nimate tabel, ki bi jih tipična oseba pogledala in rekla: "Gee, ti niso zelo dobro zasnovani." Ampak to je način, kako to počnete v okolju za shranjevanje podatkov.

Zdaj pa glejte, kaj se bo zgodilo, ker v redu je vseh teh stolpcev, poglejte to, na vsakem posameznem stolpcu imam kazalo. Zdaj v okolju OLTP, ki bi bil ne-ne. Upočasnilo bi vse moje operacije. V okolju za shranjevanje podatkov bi jih spuščal med cikli paketnega nalaganja. Naložite brez režijskih ali indeksov, in jaz bi znova ustvaril indekse. In če bi razdelil svojo tabelo, bi lahko namesto tega, da bi spuščal indeks za vsako vedro v tabeli, samo spustil indeks na vedro ali vedra, kamor bodo šli podatki v tem ciklu serijskega nalaganja. Nato ustvarite samo del indeksa za ta vedra. In zato je zelo vodljiv. In če pogledam - torej tukaj je stolpec z imenom "Počitniška zastava" in v bistvu je to da ali ne. Upoštevajte, da gre za indeks bitne slike in za večino vas boste rekli: "No, to je smiselno." Da ali ne, Y ali N, obstajata le dve vrednosti, ki imata smisel. In ker preberete dokumentacijo za indekse bitnih slik, vam vedno povedo, da izberete nekaj z nizko kardinalnostjo.

Zdaj pa naj grem v eno od svojih tabel dejstev, tako da imamo tukaj moja naročila. In to so moja naročila na dan. In zdaj boš videl, da imam znova kar nekaj stolpcev in spet bom imel več kot nekaj indeksov. In prav tu imamo nekaj, kar imenujemo univerzalni kode cene. To je bilo za maloprodajno trgovino, tako da poznate tiste majhne črtne kode, ko nekaj kupite v trgovini, to je univerzalna koda cene. Zdaj obstaja na milijone univerzalnih cenovnih kod. Zdaj so za to podjetje, ki je prodajalo stvari, verjetno imelo od 1, 7 do 2 milijona univerzalnih cenovnih kod, zato pričakujete, da to ne bo bitmap indeks, ker 1, 7 milijona različnih vrednosti zveni kot velika kardinalnost. V resnici pa v okolju za shranjevanje podatkov želite, da je to bitna karta. Zdaj pa naj pojasnim, zakaj. No, lahko za to univerzalno cenovno kodo obstaja 1, 7 milijona različnih vrednosti, število vrstic v tej razpredelnici je v stotih milijonih do več milijard vrstic. Moj indeks je nizka kardinalnost v primerjavi z velikostjo ali kardinalnostjo tabele. Zaradi tega je nizka kardinalnost. Zaradi tega je indeks bitmap uporaben, čeprav je kontraturen z 1, 7 milijona različnih vrednosti, ki bi jih tukaj izbrali bitna slika. Zdaj, če sem vedel, da želim uporabiti indeks pridruževanja bitnim mapam, trenutno izdelek tega ne podpira, bom to dodal za naslednjo izdajo, vendar bi to bila druga možnost tukaj. In v zvezdi shemi, ne pozabite, indeks bitmap bi bil v tabeli z dejstvi in ​​en indeks v B-drevesu bi nakazoval na vrstico v tabeli dejstev in nato na vsako vrstico, ki je bila za to dejstvo vidna v tabeli z dimenzijami. . In tako, tam imate še eno možnost. In tako, poglejmo, zdaj želim priti iz tabel in samo hitro vam želim pokazati, da imam iste podatke pod indeksi in bom storil isto osnovno stvar.

Zdaj sem razlog, da sem to izjavil, morda opazil, hej, tu ni primarnih ključev. Primarni ključi so narejeni s ključno omejitvijo, tako da jih dejansko zajemajo definicije omejitve. To bi bili indeksi, ki niso del omejitve. Zdaj si lahko rečete: "No, počakajte malo, ki bi lahko bil videti kot tuji ključ, tuji ključ pa je omejitev, " toda tuji ključi in večina podatkovnih baz ne ustvarijo samodejno indeksa v stolpcu tujih ključev, čeprav je priporočljivo, in tam pojdi - spet imam vse iste odločitve. In če se želim spremeniti samo zato, da me stisne, lahko to storim.

Zdaj stiskanje deluje samo na indeksu B-drevesa. To, kar si lahko ogledate, je, če pogledate različna vozlišča v B-drevesu, omogoča stiskanje nekaterih vrednosti. V resnici ni stiskanja kot stiskanje tabel, temveč stiskanje tistega, kar je shranjeno v B-drevesu v ne-listnih vozliščih. To ne prihrani veliko prostora, vendar lahko spremeni. In s tem sem opazil, da se čas precej približujem, zato se želim vrniti nazaj in prenehati z deljenjem. In naš izdelek imamo tam za štirinajstdnevno preskušanje na idera.com. Je dober izdelek, še posebej, če delate z več platformami baz podatkov. Če delate z dvema ali tremi različnimi zbirkami podatkov, vam bo to orodje olajšalo življenje. Imamo orodja, ki vam bodo pomagala pri oblikovanju in izbiranju indeksov, imamo orodje z imenom DB Optimizer. Tega danes preprosto nisem mogel pokriti, to bi bilo preveč. Če me želite kontaktirati, je tu moj e-poštni naslov, ali pa me lahko ujamete na moj zasebni e-poštni naslov, in jaz imam bloge, imam spletno mesto in bloge ter profil LinkedIn. Torej, prosim, da se obrnete na karkoli, tudi če to ni povezano z izdelkom, če se želite samo pogovarjati o bazah podatkov, sem po srcu gej in zelo rad pokukam v tehnično babico.

Eric Kavanagh: V redu, dobro, Dez, Robin, prepričan sem, da imaš vsaj nekaj vprašanj, tu imamo še nekaj minut. Dez, kaj misliš?

Dez Blanchfield: Imam eno veliko vprašanje, ki vam ga moram zastaviti, sedel sem zadnji del svojega razmišljanja. Kateri najslabši scenarij ste videli? Prebral sem vaš blog, vas pozorno spremljam, ste - verjetno ste eden redkih ljudi, ki živi skorajda malo verjetno, in mislim, da je dr. Robin Bloor drugi, ki sem ga srečal moje življenje. Ampak, veste, verjetno ste videli vsak nori scenarij, kateri od najbolj norih scenarijev, ki ste jih videli, na katere ste naleteli, in kot ljudje, ki se preprosto niso mogli spopasti, ste uspeli hoditi in izvajate Jedi miselne trike s celotnim DBArtisanom?

Bert Scalzo: Nekoč smo imeli stranko, ki je v svoji zasnovi baz podatkov zelo dobro razmišljala tako, kot bi si zamislili pri oblikovanju postavitve datotek, in tako je - ko normalizirate bazo podatkov, se najprej poskušate znebiti ponavljajočih se skupin. No, imeli so stolpec in so ga naredili dolgega, ali BLOB ali CLOB, in v njem bi postavili vrednost, številka ena, podpičje, vrednost številka dve, podpičje, vrednostno število, podpičje in bi imeli na tisoče vrednosti noter, ampak so morali iskati v tem stolpcu in so kot: "Zakaj ta stvar deluje tako počasi?" In sem všeč: "No, ne moreš ustvariti indeksa, kaj si naredil, to je samo ni dovoljeno. "Tako smo jim z načrti dejansko pokazali, da morajo to normirati normalizirati. Pa ne zato, ker je normalizacija neka akademska vaja, ki stvari naredi boljše, ampak zato, ker so želeli poizvedbo na tem področju, kar pomeni, da jo želijo indeksirati in je ne morete indeksirati v ponavljajoči se skupini ali vsaj ne enostavno . In to je verjetno najslabše, kar sem jih kdaj videl.

Dez Blanchfield: Ja, zanimivo je, kako pogosto naletiš, mislim, da izziv z bazami podatkov ljudje pozabijo, da je to znanost. In v tem prostoru obstajajo ljudje, ki delajo diplome in doktorate, pišejo prispevke in ste napisali celoten bris, vključno s svojimi priročniki TOAD in drugimi stvarmi iz spomina. Zdaj trend k nekakšnim „velikim podatkom“, kotiram na citat - vidim, da veliko ljudi pozabi na osnove arhitekture baz in tehnologije baz podatkov, če želite, znanost o bazah podatkov. Kaj opazite na terenu, kolikor se odmikate od tradicionalnih platform baz in tradicionalnega razmišljanja baz podatkov, ki smo jih dejansko prikovali do tal, in to je bil samo primer uravnavanja in spreminjanja zmogljivosti. Ali vidite, da se veliko ljudi ponovno nauči in ima izkušnjo, kjer samo sedijo tam in imajo "a-ha" trenutek, kot eureka trenutek, kjer se zavedajo, da so te velike podatkovne stvari pravzaprav le neke vrste resnično velike baze podatkov? Je to stvar tam in ljudje vam odgovarjajo nazaj in nekako: "Pozabili smo, kaj smo vedeli in ali nas lahko vrnete s temne strani?"

Bert Scalzo: No, ne, in to je grozno, če se moramo nekako sprijazniti, toda prodajalci relacijskih baz so to pili tudi Kool-Aid. Če se spomnite, ne vem, pred približno desetletjem smo začeli vnašati nestrukturirane podatke v relacijske baze podatkov, kar je bilo nekaj čudnega, nato pa podatki, relacijske baze podatkov, zdaj dodajo tip NoSQL stvari. V bistvu v Oracle 12 CR2 - vem, da ga še ni, - če pa pogledate na beta različico, če ste v programu beta, podpira ostrenje. Torej, zdaj imate relacijsko bazo podatkov, ki ji koncept NoSQL ne dodaja koncepta. In tako se zdi, da je "a-ha" trenutek bolj za ljudi na relacijski strani, ki gredo "a-ha". Nihče ne bo spet naredil prav, niti upravljavci baz podatkov, tako da moram iti čez in se pridružiti temni strani.

Dez Blanchfield: Prav, torej govorite o premiku na veliko zmešanih podatkov, če prav razumem, dajanje v tisto, čemur pravimo velike platforme podatkov, kar je nekako smešno, ker so ni tako staro, toda ali to potem ne pomeni, da se ponovno osredotočajo na to, kar počnejo s svojo relacijsko bazo podatkov, da dobijo več denarja za svoj dolar?

Bert Scalzo: Ne, običajno, če imajo potrebo po - to bi navajalo "veliko potrebo po vrsti podatkov", ugotavljajo, da namesto da bi morali iti na drugo platformo baze podatkov in narediti nekaj v ne -relacijski način, zdaj jim prodajalci baz podatkov dajejo enake nerelacijske tehnike v njihovi relacijski bazi podatkov. Mislim, dober primer bi bil, če imate nestrukturirane podatke, na primer podatkovni tip JSON ali kakšen drug zapleten tip podatkov, ki ima pomen vgrajen v same podatke, prodajalci baz podatkov ne samo to podpirajo, ampak vam bodo dali ACID skladnost z nestrukturiranimi podatki. Relacijske baze podatkov so zajele novejše tehnike in tehnologije, zato se zdi, da je "a-ha" bolj kot ne, "Hej, mi, razvijalci aplikacij, smo se nekaj naučili in se ga moramo še enkrat naučiti, " je to "Hej, to storimo tako zdaj, kako lahko to storim tako v svoji tradicionalni relacijski bazi podatkov in to storim tako kot jaz v tej bazi tukaj? "in to postaja vse bolj razširjeno in, kot sem že rekel, tudi sami ponudniki baz podatkov omogočajo da.

Dez Blanchfield: Kajne, kdo so tradicionalni osumljenci v tem prostoru za orodje DBArtisan in to? Naredil sem nekaj domače naloge, ki ste jo napisali pred kratkim, in iz spomina ste nekaj napisali, mislim, da je bil to eden od vaših blogov, o ekstremni učinkovitosti podatkovnih baz v svetu Oracle. Ne morem se spomniti, kdaj je bilo, mislim, da je bilo to leto napisano iz spomina ali konec lanskega leta. In zdelo se mi je, da gre za tradicionalnega, običajno osumljenca za vrsto teme, o kateri govorimo danes, kjer bodo ljudje šli v zelo obsežno okolje baze podatkov in iskali, kaj v tem kličete izredni dobički. Kdo so običajni osumljenci, ki jih opazite tam, ki se lotevajo DBArtisan-a in ga dobro izkoristijo?

Bert Scalzo: No, imamo veliko strank, pravzaprav sem danes sodeloval z zelo veliko vladno agencijo, ki ima - in imajo dobesedno skoraj 1000 kopij naše programske opreme, saj ljudem omogoča, da se osredotočijo na to, kar delaš in ne kako to storiti. V redu, mislim, vsi bi morali vedeti, kako nekaj storiti, vendar produktivnost doseže tisto, kar »naredimo«. Če me podjetje prosi, naj opravim neko nalogo, to je vse, kar jih zanima. Kdaj sem dobil kljukico, da povem, kdaj je bila naloga opravljena? Ne s kakšno tehniko ali s kakšno tehniko, ki sem jo uporabil, da sem prišel tja. In tako nam naše orodje omogoča, da se osredotočijo na tisto, kar jim omogoča veliko bolj produktivnost, in to je res velika prednost, in kot sem že rekel, nekatere baze podatkov ponujajo orodje samo za njihovo platformo baz podatkov. Ponujamo ga za dvanajst platform podatkovnih baz. Imam enak potek dela, isti grafični uporabniški vmesnik, iste navigacije. Če veste, kako uporabniku dodeliti privilegij ali kako narediti tabelo ali ustvariti indeks v bazi podatkov, lahko to storite v vseh dvanajstih, ker gre za enak videz in občutek ter enak potek dela. To ima za naše stranke veliko vrednost.

Dez Blanchfield: Ja, verjetno mislim, da ljudje želijo od svojih človeških virov dobiti veliko več. In dnevi, ko imamo posameznega strokovnjaka za Oracle, Ingres in DB2, že minevajo. Od ljudi se pričakuje, da bodo Jack vseh poslov, zato mislim, da jim je ta stvar popolnoma rešila življenje.

Še zadnja hitra stvar, preden jo izročim doktorju Robinu Bloorju. Omenili ste, da obstaja brezplačen prenos za štirinajst dni, kaj pa - če bom šel naprej in bom to storil, mimogrede, to bom dal v laboratorij Bloor tech in vrtel to stvar Spravi se in se sama lotite tega - do danes tega nisem imel možnosti. Omenili ste štirinajstdnevno preskušanje, rekli ste, da ga izvajate na VM v računalniku, predpostavljam, da gre za prenosnik. Kakšna je, kakšna je nastavitev začetne ravni, da se nekdo prijeme na roke in uporabi štirinajstdnevno preizkušnjo, tik preden se vrnem Robinu na njegova vprašanja?

Bert Scalzo: Vsako okolje Windows, torej Windows 7, virtualni stroj z enim procesorjem in štirimi gibi pomnilnika. Nismo zares debelo ali drago orodje. Če bi želeli zagnati strežnik baz podatkov na istem VM-ju v istem sistemu Windows, ja, morali bi dodati več, če pa svojo bazo podatkov izvajate na strežniku baz podatkov ali na ločenem VM-ju, bo VM naložil in Izvedite, da je naš izdelek zelo lahek: en procesor, štirje pomnilniki, skoraj vsaka različica sistema Windows - in podpiramo dvaindvajset- in šestinštirideset-bitne namestitve. Morate pa namestiti odjemalca prodajalca baze podatkov. Če se želite povezati z Oracleom, morate namestiti odjemalca SQL net, ker to zahteva Oracle, da se lahko pogovarjate z bazo podatkov.

Dez Blanchfield: Zveni precej naravnost. Mislim, da je ena izmed stvari več kot vse, za kar upam, da jih bodo ljudje odvzeli, razen spoznanja, da bo to orodje rešilo življenje, to, da bi ga morali iti, prenesti in igrati z njim, glede na to, da ponujate štirinajstdnevno brezplačno preizkusno različico. In se lahko zažene na njihovem trenutnem prenosnem računalniku, ne da bi namestili ničesar dodatnega, ker če že upravljajo bazo podatkov, že delajo z bazami podatkov, ki jih imajo na voljo, in ne glede na to, ali deluje v lokalnem VM-ju ali na svojem lokalno namizje, zveni, kot da je neboleče namestiti in se igrati. Zato toplo priporočam ljudem.

Robin, prepričan sem, da imaš vprašanja, Eric, verjetno si jih nekaj dobil od občinstva, torej Robin, kaj pa grem k tebi in potem nazaj k Ericu?

Robin Bloor: Ja, v redu, dobro, imam stvari za povedati. Mislim, vedno sem se mi zdelo to področje fascinantno, ker je bilo - na njem sem si rekel zobe. Resnica pa je, da sem verjetno od približno leta 1998, 1999 dober, česar je Oracle dejansko sposoben. In vedela sem, da sta Sybase in Microsoft SQL Server oba v primerjavi s tistim, ki ga lahko uporablja Oracle, precej preprosta. Nasmejali ste se, ko ste … Mislim, pokril sem usta, ko ste se začeli pogovarjati o striženju. Oracle je to storil že prej. Oracle, ki so ga v nekem trenutku predstavili, se je naveličal na objektno-relacijsko idejo, zato so v Oracleu vnesli možnost, da ustvarijo nekakšno notacijo predmetov in shranjevanje predmetov, in pogovarjal sem se z enim od njihovih inženirjev, nekaj podobnega leta po tem, ko so ga predstavili, in vprašal sem, koliko ljudi ga je uporabljal, in rekel je, da mislim, da sta ga preizkusila dva kupca in to je bilo to. In mislim, da se bo isto zgodilo, če bodo začeli preizkušati in početi trending stvari NoSQL. Veste, mislim, da je napaka, mislim, nekako me zanima, kakšne so vaše misli. Zagotovo - pijejo Kool-Aid. Imate občutek, kot da bi morali uveljavljati trditve, podobne velikim bazam podatkov NoSQL, kot je Cassandra, ampak veste, ali je za vas to smiselno?

Bert Scalzo: Ne, noht si udaril desno po glavi. Če bi naredil relacijsko oddajo, bom izbral prodajalca relacij, kot je Oracle ali SQL Server ali DB2 ali Postgres, če pa bom storil nekaj, kar ni povezano, v velikem prostoru podatkov ali v prostoru NoSQL bom izbral pravo orodje za pravo opravilo. In mislim, da to seveda ne bi bilo prvo pri prodajalcu moje relacijske baze podatkov. In potem mu dodate še drugo gubo, to je, kaj je na voljo v oblaku? Toliko ljudi, ki želijo svoje baze podatkov spraviti pred prostore. Nato morate pogledati svojega ponudnika oblakov in reči: "V redu, kaj ponujate, katere baze podatkov imate na voljo za mene, ki ustrezajo mojim potrebam in kako lahko so plačljive, in odkrito povedano, kakšna je cena ali strošek za uporabo te baze podatkov v oblaku na uro ali na dan. In na gigabajt ali terabajt? "In kar boste našli, so morda nekatere sorazmerno novejše zbirke podatkov, kot sta Mongo ali Cassandra, morda so njihove cene cenejše, tako da če boste delali velike podatke z več petabajti, boste morda morajo - samo z vidika stroškov - upoštevati baze podatkov NoSQL v oblaku, ker so morda najbolj stroškovno najučinkovitejši način za to.

Robin Bloor: Ja, prav. Mislim, moja vrsta - stvar glede relacijskih baz podatkov po mojih izkušnjah - ki je dovolj dolga, da lahko ostanejo brazgotine, to je zagotovo - obstaja veliko zdrave pameti, da če jo začnete uporabljati, in - če razumete, kaj relacijska pravzaprav je, , Mislim, spomnim se, da sem enkrat opravil nekaj posvetovanja z eno stranko, in pripeljali so me v sobo in naredili nekakšen diagram entitete in ustvarili tretjo normalno obliko, model, kakšni so bili primarni sistemi podjetja. Okrog mize je bilo dvesto štirideset in rekli so: "No, kaj misliš o tem? Za to bomo zgradili bazo podatkov, "in rekel:" Kaj misliš o tem? "Rekel sem:" Mislim, da ne bo šlo. "In točno je tako, saj veste, ker so se končale da bi ustvarili določeno strukturo znotraj enajstih poti. In to je treba razumeti pri relacijskih. Zato me nekako zanima, koliko slabe zasnove srečate. Mislim, da z DBArtisanom nimam težav - dela zelo smiselne stvari in dejstvo, da se dejansko lahko prikažete na več platformah, se mi zdi čudovito - toda koliko srečate tam zunaj, kjer je izdana zasnova kje bi se ljudje lahko rešili vseh vrst bolečine, če bi prišli do zvezdne sheme, namesto da bi dobili snežinko-y o tem, veste?

Bert Scalzo: No, nočem se slišati kot samozadovoljen ali aroganten, ampak bi rekel bolj pogosto kot ne. Jasno je, da ima večina zbirk podatkov, s katerimi se ukvarjam tam, težave ali težave. Kar je dobro, saj jim lahko naša orodja, kot je naše orodje za optimizacijo baz podatkov, pomagajo rešiti te težave, ampak, kar se mi zdi resnično smešno, je, da so številni problemi znova in znova enaki. Nekega dne sem ravno delal s stranko, ki je imela enajstmestno poizvedbo o pridruževanju in sem si rekla: "V redu, zakaj nisi uporabil klavzule?" In so kot: "No, nisem "Ne vem, kaj je to." In potem sem si rekel: "In poglej svoje podzbirnike tukaj na svoje korelirane in na neskladne, " sem rekel, "V nekaterih primerih imaš klavzulo kje na najgloblji ravni, referenca tabele je zunanja. "Rekel sem:" To je, premaknite jo na pravo raven, ne vtirajte je globlje, kot mora biti, zmešajte jo z optimizatorjem. "In z nekaj prepleti vzel nekaj, kar je trajalo približno dve uri, in ga spravil na deset minut, in bilo je preprosto - v tem primeru nismo naredili nič drugega kot izboljšali SQL, ki so ga napisali. Mislim, da je težava v tem, da veliko univerz in veliko ljudi, ki se programirajo v neakademskem okolju, se ga učijo kot zapisane procese ali procese, usmerjene v vrstico in relacijski, je naravnana narava, mora razmišljati v sklopih, da napiše dober SQL.

Robin Bloor: Da, mislim, da je ravno to. In to morate razumeti, ljudje bi morali poznati takšne ABC-je. Ni važno. Saj ne boste mogli narediti racionalnih stvari, če ne boste vedeli, da bo celo dobro zasnovana in dobro modelirana baza podatkov vzela čas, da bo vrsta trajala. To počnejo zato, ker svet še nikoli ni našel načina, kako bi lahko hitro šli. Našli so načine organiziranja podatkov, tako da grejo hitreje kot sicer, in veliko navdušenja, ki ga moram povedati za baze podatkov NoSQL, je preprosto, da se izogibajo pridruževanju. Pravkar začnejo graditi zbirke podatkov z enakim širjenjem podatkov v njih, ker če se pridružiš kateri koli od baz podatkov NoSQL, jih močno sesajo. Se ti ne zdi?

Bert Scalzo: Vsekakor. In smejati se moram, ker sem začel nazaj pred relacijskimi bazami podatkov in nazaj, ko je bil Ingres RTI, Institut za relacijsko tehnologijo in nismo imeli SQL, imeli smo relacijske jezike pred SQL. Mislim, da se je takrat v Ingresu imenoval Quel. Torej ste dobili iz teh starih paradigem baze podatkov, kot so omrežje in višje grafične ali hierarhične, in čez nekaj desetletij greste skozi relacijske paradigme in zdaj se mi zdi, kot da se spet vračamo na skoraj hierarhično. Skoraj tako, kot da smo se vrnili.

Robin Bloor: Ja, prav. Bolje, da te predaš Ericu, porabim preveč časa, toda ali imamo od publike še kakšno vprašanje, Eric?

Eric Kavanagh: Imamo, nekaj jih imamo. Tukaj gremo še malo, a vrgel bom par nate. Imeli smo nekaj vprašanj okoli nevidnih indeksov. Eno vprašanje je bilo: "Ali mora kdo uporabiti vaše orodje, da jih vidi?" Drugo vprašanje je bilo: "Pa kaj, če si slep?"

Bert Scalzo: To je dobro.

Eric Kavanagh: Tudi radovedno vprašanje, zato le FYI.

Bert Scalzo: Ne, ni treba imeti naših orodij. To je funkcija Oracle, indeks nevidnosti. Oracle v bistvu v podatkovnem slovarju hrani le metapodatke, ki pravijo: "Optimizator, prezrite ta indeks. Tukaj je, toda če vas fizično ne naložijo z namigom v, namig za optimizacijo v ukazu SQL tega ne uporabljajte. "In tako, ne, ne bo vam treba imeti naših orodij in v vsakem pogledu to je navaden stari indeks, lahko ga vidite v katerem koli orodju, samo optimizator bo rekel: "Pri običajni obdelavi poizvedb ga bomo ignorirali." Če ga želite uporabiti, ga morate usmeriti. Res je priročno za scenarij, ki sem ga opisal, in sicer, če bi želeli sestaviti indeks v proizvodnji, vendar ne tvegati zloma poročil ali stvari, ki se že izvajajo, vendar ste jih želeli preizkusiti, bi to lahko storili. To je tisto, za kar je najbolj koristno.

Eric Kavanagh: To je dobro in potem je bilo tu še eno dobro vprašanje. "Kaj pa nekatere nove baze podatkov v pomnilniku? Kako tehnologija baz podatkov v pomnilniku spreminja igro glede na indeksiranje? "

Bert Scalzo: Fant, no, zdaj je to dobro, vesel sem, da je nekdo postavil to vprašanje, da bomo morali iti še pol ure. Ne, v pomnilniku, odvisno je od prodajalca baze podatkov. Zdaj ponavadi sem, ne govorim nič drugega kot hvalim karkoli, kar Oracle počne, ker je neverjetna tehnologija, ki so jo vgradili, ko pa se strgaš pod pokrovi in ​​pogledaš, kaj je v spominu v Oracle, v Oracle baze podatkov, v resnici je, če še vedno hrani shranjevanje vrstic na disku in naložila se bo v pomnilnik shranjenega stolpca, in če ni dovolj pomnilnika za shranjevanje celotne tabele, se bo vrnila nazaj na dele; se ne prilega spominu, če ga shranite v vrstico, in tako lahko dejansko naredite izbiro za tabelo in za polovico tabele, uporabljate indeksiranje, ki zadene tradicionalne vrstice na mizi, in za drugo polovico Izberite, da se dejansko izide in samo zgrabite vse iz iskanja v pomnilniku, in tako je drugače, kot ga je na primer SQL Server izvajal s svojo tehnologijo Hekaton, veste, in SQL 2014, in to je bilo izboljšano v SQL 2016, vendar je v nekaterih pogledih njihova bolj resnična različica spomina in, vendar ima vsaka implementacija prednosti in slabosti, vendar morate nekako pogledati pod platnice in se zavedati. Ker sem imel stranko, ki je rekla: "Oh, ta miza je v spominu - samo sestavil bom vse indekse" in sem takšen, "Tabela je večja od pomnilnika, ki ga imate na strežniku, tako da se v nekem trenutku nekaj poizvedb mora zadeti na disk. "

Eric Kavanagh: To je dober opis; to so dobre stvari. No, ljudje, v tem letu bomo imeli še nekaj spletnih oddaj s temi fantje, vrnite se kadarkoli slišite, da je Bert na predstavitvi, saj vemo, da pozna svoje stvari. Vedno je zabavno govoriti s strokovnjaki. Vse te spletne oddaje arhiviramo za poznejši ogled. Tukaj so še Bertovi kontaktni podatki in poskušali bomo povezati povezavo za prenos in jo poslati tudi po e-pošti, vendar lahko resnično pošljete svoje: vedno imamo še nekaj spletnih oddaj za to Leto in trenutno delamo ed, zato, ljudje, če imate teme, o katerih bi res radi slišali naslednje leto, ne bodite sramežljivi: Bodite pozorni, ljudje, se bomo pogovorili naslednjič. Adijo.

Partner za vsebino Techopedia

Osebje podjetja Techopedia je povezano z Bloor Group in z njimi je možno vzpostaviti stik z možnostmi na desni. Za informacije o tem, kako sodelujemo s panožnimi partnerji, kliknite tukaj.

• Profil
• Spletna stran