[nemu]

Buffer cache saab muud jura täis?
Võid cache hinti proovida:

[serk]

[2korda2]

serk,
kui suuri süsteeme oled teinud? Niikaua, kui ülesandeks on Kalle Kusta pagaritöökoja 10 kuklit kolmele hulgimüüjale müüa, on kõik ilus ja lihtne. Ükspäev aga satud ülesande otsa, kus tabelites on miljoneid kirjeid ja klient ootab süsteemilt regeerimist sekundi jooksul. Siis võid ennast halliks optimeerida aga denormaliseerimisest ei pääse.

"ligipääs baasile" - on päris erineval tasemel ja meetodil ligipääsu võimaldamist. Üldjuhul välistele pooltele kuvatakse andmeid läbi view - selle definitsiooni saab muuta jooksvalt vastavalt vajadusele ilma, et teine pool peaks andmemudeli muudatuste tõttu andmevahetust muutma hakkama (lisaks on õiguste probleem sellega lihtsalt lahendatav). Kui teisel poolel on vaja andmeid lisada, siis selleks tehakse eraldi tabel või protseduur. Jällegi selleks, et väljast tulevad andmed oleksid võimalikult eraldatud muust andmemudelist ja liides ei sõltuks andmemudeli muudatustest. Ma olen näinud ka lahendust, kus sisuliselt kogu salvestus baasi käis läbi protseduuride (ma ei ütle, et see mõistlik oleks aga ka nii saab ja seal oli isegi vaieldav põhjus).

Le Inc,
Oracle (ja ka muud "suured" serverid) optimeerivad oma tööd jooksvalt. Üks päring võib seetõttu tõesti võtta erinevalt aega sõltuvalt sellest, millise plaani alusel server selle lahendab. Nii umbes 8 aastat tagasi olin ise tunnistajaks, kus Oracle baas vajas iga paari nädala tagant sunniviisilist statistika ümberarvutamist, sest suutis ennast jooksvalt "lolliks optimeerida". Mis siis lahendus oli, ei mäleta kahjuks.

[serk]

[2korda2]

Kui aru ei saanud, ju pole piisavalt keerulisi süsteeme teinud. Väide, et andmete dubleerimine on IGAL JUHUL paha ei päde lihtsalt.

[serk]

[2korda2]

EI! Ma ei pidanud silmas mat. viewsid vaid justnimelt andmemudeli denormaliseerimist! Küsimus ei ole aruandes - küsimus on töökuvade kiires toimimises. Kui suur aruanne sekundiga ei avane, siis see üldjuhul kedagi ei morjenda, kui aga tavaline töökuva 2 sekundit avaneb, siis on kasutaja õigustatult kuri. Kui korraga on kuval andmeid 5-7 tabelist ja igaühes on miljoneid kirjeid, siis kasulikum on paar veergu dubleerida ja saada tabelite hulk <=3 peale.

[serk]

Olgu, teeme rahu, kuna me ei tea üksteise tööstussektoreid, siis vaielda raske, ühele sobib üks, teisele teine.
Aga arvestades sellega, et käesolevas foorumis, ka käesolev topic, tehakse üldjuhul tavalisi veebilahendusi, siis nendel juhtudel ei küündi nende andmemaht eales tasemeni, mil tuleks hakata denormaliseerima

Aga nagu ennist öeldud, denormaliseerimist mina isiklikult ei poolda ja väldiks igal võimalikul viisil, kuna see tekitab siiski probleeme:
1) Andmete up-to-date hoidmine
2) Lisa kettaruum
3) Andmemudeli lisa keerukus ja insert, update, delete aeglustumine(FK;PM;Constraindid)
4) Arenduskulu tunduvalt kallim, nii baasi kui UI seisukohast.

Andmete kuvamise kiirus on tegelt lõputu probleem ning lähenemisviise on erinevaid, kes soovitab osta kõvemat rauda, kes süsteemi ümber kirjutada jne ... Ainuõiget teed polegi.

Aga oli tore vaielda Edu.

[Le Inc]

[2korda2]

Plaan vaja üle vaadata. Kas päring kasutab indekseid või laseb full scan? Kui indekseid ei kasuta, siis muuda kas päringut või lisa indeks, kuhu vaja. Kui group by vms sees pole, siis 4 sekundit sellise hulga juures on hiiglama palju (tingimusel, et sa ei lae üles mingit suurt "pildiinfot" vms).
Veel 1 asi mida kindlasti tähele panna - tarkvaraliselt (ehk päringuid optimeerides, mudelit kohendades) võid teinekord võita kiiruses tuhandeid kordi, riistvara annab ka väga heal juhul tubli suurusjärgu võrra vähem tagasi. Samas riistvara on tihtipeale odavam ja seetõttu ka lihtsama vastupanu tee Mul on endal jälle kogemus, kus üks üsna suur protseduur töötas esimeses "ah peaasi et töötab" versioonis ca 30 minutit. Pärast kahte päeva optimeerimist sai selle alla 20 sekundi peale. Seejuures andmemudelit ei muudetud (kui mitte arvestada protseduuri töö käigus juurde tekkinud ajutisi tabeleid). Riistvaraliselt poleks sellise tulemuseni lihtsalt jõudnud.

serk,
sry, ma olen hellaks tehtud igasugu "hiilgavate" lahendustega ja seetõttu kipun järsult reageerima. Mõte on ikkagi selles, et andmete dubleerimine suurte süsteemide korral on paratamatus. Jah, on kallim arendada ja hallata aga kui alternatiiviks on tatina veniv rakendus, siis lihtsalt pole muud võimalust. Samas tõsi ta on - siit foorumist abi otsiv tegelane tõenäoliselt sellist süsteemi ei tee. Peace!

[serk]

Hei

Esimene full scan käib sul 5.3 sekki, järgmine päring mis sul käib 1.7 sekki käib mälust. Paari tunni pärast on mälust päring minema lükatud ja tehakse järjekordselt full scan.
Tuunimise aitamiseks oleks hea kui saaksid postitada create tabel scriptid koos veergude kommentidega - data võin ise insertida. Ning peamine, päring mis seal peal käib - on vaja äriliseslt aru saada mida tahetakse näidata. Peale seda saab mõelda kuidas seda kõike tuunida. Explain plan ei teeks samuti paha.

Aga nagu eelmine postitaja ütles, siis tõenäoliselt korrektsed indeksid aitaks.

Näiteks:
1) Teha ta mat. view'ks kuhu esmalt täitagi ainult need 15 rida mida tahad näidata ning edaspidi kasutada fast refreshi
2) Indekseerida tabel
3) Tõmmatagi tabel jõuga mällu
4) jne ... väga palju erinevaid võimalusi

Aga ennem kui postitad tableite struktuure või datat, ole kindel et sa võid seda teha!

[kiiver]

[Le Inc]

Nõus. Indekseid pole, nüüd tegin. Võtsin ID (unikaalne nr igas reas) indeksi aluseks. Ilmselt on mul jah sql päring optimeerimata. Proovin ümber kõpitseda .. asi sai tehtud kunagi ammu, kui veel sql suurt midagi ei jaganud.

Kahjuks vist veebilehe põhised ~3 sekised vist jäävad. Seal on väga palju mitme tabeli vahelist suhtlemist, aga ehk annab midagi teha.

[Fukiku]

[mirko28]

[Le Inc]

Indexitega ID luges 650k rida kokku 0,57 sekki, ilma index'iteta 2,1 sekki. Töötab.

[2korda2]

Fukiku,
tabelis veerg ID peaks oma olemuselt olema PK ja seega automaatselt indekseeritud. Ilma PK-ta tabel on saadanast, nagu siin ühes teises teemas sai nenditud.
Aasta oli siis umbes 2002, kui huvi pärast sai testitud indekseerimata Sybase IQ baasi: 4M kirjega tabelist "group by" jms koledate tingimusega 100 rida tuli ~12 sekundiga (serveriks tavaline tolle aja lauaarvuti). Korralikult indekseeritult tavalised mootorid (Oracle, Sybase ASE) suutsid sama päringu läbi teha ca 5 sekundiga. Koos indeksitega oli IQ kordi kiirem aga need hinnad.... $15000 ainult ühe protsessoriga serveri litsentsi eest (kasutajad tulid veel juurde) oli vähestele tollal jõukohane. Kui tuli veel selgitada, et see ei ole mitte töökeskkonna vaid ainult andmelao jaoks, siis... Praeguseks peaks Eesti pinnal olema päris mitu IQ kasutajat (Elisa ja SEB tulevad nagu meelde).

[Fukiku]

[2korda2]

Jah, said õigesti aru. Päringus peab üldiselt kasutama indekseeritud veergu(sid). Samas kui mul on näiteks isikute tabel ja ma tahan kõiki meessoost isikuid, siis veerg SUGU, mis omab väärtusi M,N ei ole hea indekseerida - ei anna suurt midagi juurde. Üldiselt on mõtet indekseerida veergusid, kus on piisavalt palju erinevaid väärtusi ja ühtlasi selle veeru väärtusi kasutatakse päringute tegemisel. Kuupäev on tüüpiline näide.

[Le Inc]

Tundus et minu puhul oli kala tabelis endas. Nimelt 650k veeruga tabelist tegin lahjema 170k veeruga tabeli (enne kopeerimine, siis delete), aga lugemise kiirus langes paarkümmend %. Tegin uue tabeli vana põhjal ja kopeerisin info 1:1 üle. Nüüd loeb ~5..6x kiiremini. Ka veebileht on 3..4x kiirem.

Ilmselt oli oracle tabeli suurema hulga peale ära optimeerinud, seega ei tulnud ka 4x andmete vähendamine erilist kiiruse võitu. Muide hetkel ei oli ühtegi indeksit, töötab kenasti.

[serk]

Indeks on efektiivne siis kui sa pärid vastavalt indeksile suhteliselt väikest osa tabeli andmetest - ei mäleta peast enam seda rule of thumb % määra.
Üldiselt oleks tark peale indeksi loomist vaadata päring uuesti explain planiga üle.

Sinu tabeli probleemi kohta:
Oracle soovitab uuesti statistika arvutada kui 10% andmetest muutub ja kui selle peale query pange paneb. Defauldis peaks Oracle iga 24h tagant seda anyway ise tegema - võin siin muidugi hetkel eksida, pean järgi vaatama manualist.
Mälu järgi oli käsk selleks: DBMS_STATS.gather_table_stats -viitsimist on siis, proovi.

See 10% on muidugi "pseudo" väärtus ja pole kuldne reegel, kõik sõltub paljudest muudest teguritest. Mõnikord võib isegi väiksem data change käivitusplaani jumala metsa keerata ja vastupidi... Muudad, testid, muudad, testid, muudad, testid .... ja toodangus võib ikka asi pekkis olla

[nemu]

DBMS_STATS.gather_table_stats "deprecated", kuid lihtsamini meeles püsiv alternatiiv on:

[serk]

[nemu]

Kogu eelmine postitus viitab ju kiirele testile kui segaseks jäi.

[morgoth]