Az adatok tárolása Indexek BME-AAIT 2015 Informatika 2 1
Memória hierarchia Cache Néhány MB Néhány ns Rendszermemória ~GB 10-100 ns Másodlagos tár ~TB ~10ms Harmadlagos tár ~PB s-min Virtuális memória Cache Rendszermemória Lemez Másodlagos tár Fájl rendszer Harmadlagos tár BME-AAIT 2015 Informatika 2 2
Adatok mozgatása a szintek között Blokkok Írás/olvasás egysége a lemezen (4-64kb) => A közösen használt adatokat célszerű egy blokkba tenni Harmadlagos tár Pl szalagos meghajtó: amire tipikusan egyszerre van szükség, azt egy egységre tesszük BME-AAIT 2015 Informatika 2 3
Szekvenciális keresés Szekvenciális keresés (sequential/table scan) A kérdéses reláció valamennyi rekordját felolvassa és megvizsgálja Az első rekordtól kezdve, szekvenciálisan az utolsó beolvasásáig Költséges I/O műveletek lassúak Feleslegesen foglalja a rendszermemóriát Tányér 1 Tányér 2 Tányér 3 BME-AAIT 2015 Informatika 2 4
Mikor jó a szekvenciális keresés? Nagyon kis méretű tábláknál Néhány blokkban elfér, minimális az I/O költség Ha nagyon sok rekord érintett Az egész táblát fel kell olvasni egyébként is Pl aggregálás szűrés nélkül SELECT SUM(Value) FROM Invoices A szűrőfeltételek nem nagyon korlátozóak Pl alacsony kardinalitású oszlopok (ember neme, családi állapota...) Olcsóbb, mint közvetlenül megcímezni minden egyes rekordot BME-AAIT 2015 Informatika 2 5
Mikor nem jó a szekvenciális keresés? A szűrőfeltétel szelktivitása nagy Csak néhány rekord felel meg a feltételnek (pl < 5%) Minél kevesebb, annál pazarlóbb A rekordok elszórtan helyezkednek el Pl SELECT * FROM Alkalmazott WHERE SzigSzam= AA123456 0 vagy egy rekord felelhet csak meg SELECT * FROM Alkalmazott WHERE TelMellek= 1234 Legfeljebb néhány alkalmazott osztozik egyszerre ugyanazon a telefonon BME-AAIT 2015 Informatika 2 6
Mikor nem jó a szekvenciális keresés? 2 Join művelet két reláció között Legalább az egyik reláció nagy Egyébként kevés I/O művelettel betölthetők a memóriába Csak néhány rekordban illeszkednek Lépésszám O(n*m) Pl SELECT * FROM Megrendeles INNER JOIN MegrendelesTetel ON Megrendeles.Id=MegrendelesId WHERE MegrendelesTetel Megrendeles BME-AAIT 2015 Informatika 2 7
Indexek Ötlet: készítsünk egy tartalomjegyzéket (indexet) a reláció egy (vagy több) oszlopához Egy érték => Illeszkedő rekordok (u.a. a mező, u.a. az érték) Index Tábla Sokkal kisebb helyen elfér, gyorsan betölthető A lemezműveletek dominálnak! Végezzük el a szűrést ebben BME-AAIT 2015 Informatika 2 8
Indexek 2 SELECT * FROM Alkalmazott WHERE SzigSzam= AA123456 Szekvenciális keresés helyett elég az indexet végignézni, majd az általa mutatott rekordot visszaadni (1-1 megfeleltetés). SzigSzam Index Alkalmazottak Valójában az index még csak nem is soros, hanem fa szerkezetű, még gyorsabb a keresés (lsd később) BME-AAIT 2015 Informatika 2 9
Indexek 3 Join: Keresés az indexben SELECT * FROM Megrendeles INNER JOIN MegrendelesTetel ON Megrendeles.Id=MegrendelesId WHERE Datum > 2014 Szekvenciális keresés a Megrendelések között, majd index alapján a tételek között O(n+m) (n*m helyett) MegrendelésTétel INDEX(MegrendelésId) Megrendelés BME-AAIT 2015 Informatika 2 10
Indexek Példa Adott 2 tábla t1: 100 sor és t2: 100.000 sor Mindkettőben unique index van a joinolt mezőkön (col1, col2) Feltételezzünk 1 rekord/blokk helyfoglalást (1 olvasás / rekord) t1: tfh. egy rekord: 2 index + 1 rekord olvasás => 3 olvasás t2: tfh. egy rekord: 3 index + 1 rekord olvasás => 4 olvasás Lekérdezés: SELECT * FROM t1, t2 where t1.col1=t2.col2 Szükséges I/O műveletek száma (lekérdezés optimalizálótól függően) Szekvenciális olvasás mindkét táblában, indexek használata nélkül 100*100.000 = 10.000.000 olvasás szekvenciális olvasás t2-ben, majd index alapján joinolás t1-hez 100.000 olvasás t2-hez, majd 100.000*3 olvasás a t1-ben való kereséshez 400.000 olvasás szekvenciális olvasás t1-ben, majd index alapján joinolás t2-höz 100 olvasás a szekvenciális olvasáshoz, 100*4 olvasás a t2-ben való kereséshez 500 olvasás BME-AAIT 2015 Informatika 2 11
Indexek SQL Nem része az SQL szabványnak CREATE INDEX [indexnév] ON [táblanév]([oszlopnevek]) CREATE INDEX idx_megrendelesid ON MegrendelesTetel(MegrendelesId) CREATE INDEX idx_ev ON Megrendeles(Ev) CREATE INDEX idx_vevo ON Vevo(Varos, Cim) Varos+Cim attribútumra lehet hatékonyan keresni Általában a két mező konkatenáltja Hatékonyan kereshető az első attribútum alapján is ALTER TABLE [táblanév] DROP INDEX [indexnév] BME-AAIT 2015 Informatika 2 12
Indexek megválasztása Ellentétes eredmények Gyorsítja a lekérdezéseket, amelyek használni tudják Szűrőfeltétel az indexált mezőn Joinok amelyek használják ezeket a mezőket Lassítja a módosítást, beszúrást, törlést Módosítani kell az indexstruktúrát is BME-AAIT 2015 Informatika 2 13
Indexek megválasztása 2 Tipikus indexek Elsődleges kulcson Sok lekérdezés használja, legtöbb join kulcs alapján történik DBMS-ek általában automatikusan létrehozzák Egy lekérdezés egy kulcs érték alapján legfeljebb egy rekordot ad Legfeljebb egy blokkot kell beolvasni + néhány blokkot az index beolvasásához (ha nincs a memóriában) Külső kulcs Hatékony join (törlésnél is) Egyedi értékek Így biztosított az egyediség a tábla végigolvasása nélkül (auto) Ha majdnem kulcs Viszonylag kevés rekord rendelkezik egyező értékkel Vásárló neve Bár az összes találat lehet különböző blokkban is, a reláció teljes méretéhez képes viszonylag kevés blokk érintett BME-AAIT 2015 Informatika 2 14
Indexek megválasztása 3 Adatok módosítása Az összes érintett indexet aktuálizálni kell Be kell olvasni, ki kell írni őket DE: a legtöbb módosító utasítás használ szelekciót Az indexekkel nagyságrendekkel gyorsítható Ha nem kicsi a szűrő mező szelektivitása DELETE FROM Vevo WHERE Id = 5 => nagy a szelektivitás DELETE FROM Vevo WHERE Varos= Budapest => kicsi a szelektivitás, nagyon sok rekord érintett Figyelembe kell venni a várható felhasználást Lekérdezés/módosítás aránya Sokszor automatikus támogatás a log alapján BME-AAIT 2015 Informatika 2 15