SQL – OLAP 7. óra. Hatékonysági kérdések Időigényes műveletek (ahol lehet javítani):  f(v) (C),  f(D.a) (C), D.a (C),  D, aggr (C) (és ahol nem…) C.

Az előadások a következő témára: "SQL – OLAP 7. óra. Hatékonysági kérdések Időigényes műveletek (ahol lehet javítani):  f(v) (C),  f(D.a) (C), D.a (C),  D, aggr (C) (és ahol nem…) C."— Előadás másolata:

1 SQL – OLAP 7. óra

2 Hatékonysági kérdések Időigényes műveletek (ahol lehet javítani):  f(v) (C),  f(D.a) (C), D.a (C),  D, aggr (C) (és ahol nem…) C 1  C 2 Adott kulcsú cellák megkeresése k1k2k3v1v2v3 A: szekvenciális keresés ? reménytelen !! B: index alapú keresés ? k1+k2+k3 : ha mindegyik kulcs adott költség : log (N 3 )ez OK !! de asszimnetrikus !

3 Hatékonysági kérdések k1k2k3v1v2v3 Több-dimenziós keresőfa : minden szint egy-egy dimenzióhoz rendelt ciklikusan k1 k2 k3 k1 k2

4 ha valamelyik kulcs tetszőleges (intervallum) akkor több ágon fut a keresés Ha keresési feltétel: k1 = %, k2=x, k3=% csomópontok száma: L,L 2,L 3 (L a B-fa fokszáma) költség: első k2 szinten: L, második k2 szinten: L*L 2, i. k2 szinten: L 2*i+1 ez is túl nagy még !!! Hatékonysági kérdések

5 Grid file Szimmetrikus az egyes dimenziókra Hash függvény jelöli ki a rekeszt h1(k1) h2(k2) Ha túlcsordul, egyik dimenzió mentén felhasad Lemez blokk Hátránya : reláció-őrző hash függvény kellene Hatékonysági kérdések

6 Legbiztosabb megoldás: többszörös indexelés, többszintű pointer láncolat k1 indexk2 indexk1-k2 index

7 Dorog Miskolc Baja AudiOpelFiatLada Fizikai megvalósítás 7,26,17,03,2 9,17,4 7,24,2 K GP LAFO többletköltség?

8 Hatékonysági kérdések k1 index Keresés menete: - megfelelő szintű index kiválasztása - érték megkeresés (log (N k )) - fő pointer-lánc bejárása - mellék pointer-láncok bejárása Csak a szükséges elemeket érinti

9 Indexelés:sparse - dense index ritka index: nem minden rekord indexelt (index szekvenciális) feltétel: rendezettség szélső elemre mutat lsd: cluster index sűrű index: minden rekord indexelt idő: log M (N/k) + [k] = log M N - log M k + [k] hely: N/k/M blokk

10 Indexelés:bitmap index értékek A B C rekordok 0 1 szűk domain esetére támogatja a logikai operátorokat gyakran társítják a projekciós index-szel C rekordok érték B 1 0 táblázatos tárolás

11 Összetett feltételek, több kulcs esetére is alkalmas a bitmap index fetétel: K1 = 5 and K2 > 5 B-fa szerint: K1=5 megkeresése majd szekvencia a K2> 5 ellenőrzésre 0 1 1 0 5 K1 0 1 1 0 6 7 + metszetképzés / unió / komplementer K2

12 Bitindexek típusai normál mód: minden érték egy sor 1 2 3 0 1 1 0 0 0 0 0 1 előnyös egzakt érték keresésnél tartomány mód: minden érték több sor (a tőle nagyobb értékek) 1 2 3 0 1 1 0 0 1 1 1 1 előnyös tartomány érték keresésnél

13 Bitindexek típusai dekompozíciós mód: a tábla több résztáblára bontott szám n-es alapján képzi a bitmintát: C = b 1 + b 2 *r 1 + … + b n+1 *r n Pl. n =1, b 1 = 3 –hez: 5 = 1*3 + 2 0 1 1 0 0 0 0 0 1 0 1 0 1 0 0 0 0 1 0 1 2 0 1 2 r n = D/szorzat n-1 (r i )

14 Bitindexek típusai hierarchikus bitindex: a zéró helyek felsőbb szinten jelzi 1 0 1 1 0 0 0 0 0 1 0 1 2 000000010 0101 1101

15 Join index A kapcsolódó rekordpárok kijelölése kulcs szerint rendezve Nem kell explicit keresést végezni TELEPHELY cim nev TERMEK cim nev OSSZDB SELEJTDB TELEP TERMEKOSSZDB B-fa tény-kulcshoz dimenzió-kulcsot vagy dimenzió-kulcshoz tény-kulcsot rendel

16 Cella keresési költségek B-fa teljes kulcsintervallum log M N módszer Grid-file bitmap részkulcs 1 fa: N k-fa: K’ log M N + K’*N’ 1 (metszetek) log M N+N/(2B) H K-K’ (H/2) K N :elemszám, M fokszám V : értékek száma, K’ kiválasztott dim. db B: blokkméret, H: bucketek száma, K:dimenziók száma V*N/B’V’*N/B’V*N/2/B’

17 Aggregációs számítások SELECT sum(fiz) FROM dolgozok WHERE beosztas = ‘irnok’ - alap módszer: a kijelölt rekordok közvetlen beolvasása N: rekord db., B: blokk méret, R: eredmény rekord db. érintendő blokkok száma: O(N/B * (1 – e -RN/B )) nem egyszerű feladat a = szumma B (B* P(B)) P(B) = ((N:B))szorzat i ((S:i)) : 1<= i <= S R N/B a feltételt teljesítő rekordok pozíciót ismertnek tekintjük (B f )

18 Aggregációs számítások - projekciós index módszer: a kijelölt mező értékeket a a projekciós indexből vesszük be. előny: kevesebb blokk olvasás (B’ >> B) O(N/B’ * (1 – e -RN/B’ )) - mező indexen keresztül (B’’ >> B’): sum = 0 foreach v in DOM(fiz) { B v = foundset az index alapján sum = sum + v*|B f metszet B v | } O(V*N/B’’ + N/B’)

19 Aggregációs számítások A költség függ az aggregáció jellegétől SELECT max(fiz) FROM dolgozok WHERE beosztas = ‘irnok’ - közvetlen elérés: O(N/B * (1 – e -RN/B )) - bitmap index az elemre (metszet a B f -fel): O(V*N/B’’ ) - projekciós index: O(N/B’ * (1 – e -RN/B’ )) - mező index O(V/2*N/B’’ + N/B’)

20 Hatékonysági kérdések Az aggregáció gyorsítása: elő-aggregációk tárolása elemi érték (k1,k2) k1 szerinti aggregáció k2 szerinti aggregáció k1.k2 szerinti aggregáció

21 Cube-tree struktúra az alapadatok és az aggregált adatok hatékony elérésére szolgál alapadat aggregált adatok v(x,y,z) v(x,y,0) az adatok R-tree struktúrában tároltak v(0,0,0)

22 Előaggregáció előnye: gyorsabb válaszadás Hátránya: több helyfoglalás lassabb módosítás (load) Cél az egyéb költségek minimalizálása Csak a szükséges előszámításokat végezzük el Tapasztalat: egyes aggregációk kiszámíthatók más aggregációs értékekből  A, Sum (C)  A,B, Sum (C)  A,B,C, Sum (C) Származtatási háló ez egyes aggregációs szintek között

23 A,B,C A,BA,CB,C ABC Minden view-hoz helyköltség, minden élhez időköltség rendelhető   hely-költség +   idő-költség => minimális

24 Greedy algoritmus addig növeli a bevont elemek halmazát, amíg egy szigorú korlátba nem ütközik S = {alap-view} loop { v i = argmax i {B(v i,S) : v i  S} S = S  {v i } } B(v,S) =  w < v B w B w = Cost S (w) - Cost v (w), ha Cost S (w) > Cost v (w) 0, különben

25 0.7 0.50.20.4 2 3 1 3 1 4 5 2 1 2 2 3 0.2 Az eredő nyereség kiszámítsánál a v hivatkozási valószínűségét is figyelembe lehet venni.

26 Lekérdezések kapcsolati viszonya Milyen feltételek mellett lehet egy Q lekérdezést más V view-kból leszármaztatni? relációk: view-k egyenértékűsége és view-k egymásbafoglalása Általános esetre nem ismert még a megoldás speciális eset: pontos illeszkedés V1 < V2: - V1 mezői, hivatkozásai V2-ben is benne vannak - azonos aggregáció - V2 szelekciói V1-ben is benne vannak - V1 szelekciói szűkebbek V2: SELECT a,sum(b), avg(c), d FROM t1 WHERE t1.c > 5 GROUP BY a V1: SELECT a,sum(b) FROM t1 WHERE t1.c > 5 AND t1.d = 5 GROUP BY a

27 Hatékonyabb művelet optimalizálás a hagyományos QGM optimalizálás is módosulhat eddig csak SPJ műveleteket vettünk : szelekcio(proj) - join – szelekcio – csoportképzés? –aggregáció? SELECT B.b, sum(A.a) FROM A,B,C WHERE A.m=B.n AND A.h = C.f AND C.l = x GROUP BY B.b De! Az A és B tábla join-ja közben lehet aggregálni és csoportosítani, nem kell utána újra átfutni a táblát

28 Hatékonyabb művelet optimalizálás szabály : a csoportosítás lesüllyesztése minél lentebbre SELECT B.b, sum(A.a) FROM A,B,C WHERE A.m=B.n AND A.h = C.f AND C.l = x GROUP BY B.b alap left-deep join aggregáció ekvijoin scan transzformáció

29 Lesüllyesztés feltételei - a csomópont felett csak kulcs- idegenkulcs alapú join műveletek vannak - a csomópontban minden aggregációs mező szerepel - minden felettes join mező egyben csoportképzési mező is ez szűk esetben teljesül kapcsolt lesüllyesztések: - több csomópontra szétbontott select C.n,sum(A.c) from A,B,C where A.x = B.x and B.y=C.y group by C.n C.a C A A.x B B.y sum(A.c) ABC