Adattárház indexelési stratégiák Microsoftos környezetben

Nagyon nem ezzel kéne foglalkoznom, de megkérdezték és nem bírtam megállni, hogy ne írjam le. Kezdjünk is rögtön bele, de előre szólok, hogy lehet hogy ki fogok verni egy-két biztosítékot…

• Szoktál a ténytáblákra indexet tenni?
• Nem. A ténytáblákra nem szoktam indexet tenni.

Paff. Egyik biztosíték kiment.

• Szoktál-e Primary key - foreign key constraint-eket definiálni?
• Nem. Nem szoktam

Paff. Kiment a második biztosíték is.

Pedig constraint-eket tényleg nem szoktam tenni az adattárházra, mert csak a nyüg van vele, és lassítja a ténytáblák feltöltését is. Úgy gondolom, hogy a referenciális integritás megőrzése nem az adatbázis kezelő, hanem a betöltési folyamat feladata, és ezt egy jól megtervezett betöltési folyamat elég nagy biztonsággal el is tudja látni.

Indexek

Ténytáblák indexelése

Nagy általánosságban a ténytáblákra sem szoktam indexet rakni. És mielőtt az asztalra csapna, hogy micsoda butaság ez, hagy magyarázzam meg hogy miért nem.

A Microsoftos BI világban, ahol az OLAP és a relációs adatbázis-kezelő össze van csomagolva egy termékké (nem is lehet külön-külön megvásárolni őket) nagy butaság lenne parlagon hagyni az OLAP-ot.

Egy jól felépített csillagsémás adattárház tetejére ráültetni az OLAP-ot szinte gyerekjáték és nem kerül egy fillér pótlólagos szoftverköltségbe se.

Mindezeken túl az OLAP-nak számtalan előnye van még a relációs csillagsémákkal szemben:

• lényegesen jobb lekérdezési sebességet produkál (nem is lehet úgy megfektetni egy bonyolult lekérdezéssel, mint a relációs társát)
• Klasszisokkal jobb riportgeneráló (lekérdező) eszközök léteznek hozzá, mint a relációs adatbázis-kezelőkhöz,
• Lényegesen több elemzést támogató függvénnyel rendelkezik (Year-to-Date, …)
• Százszor kifinomultabb a jogosultság kezelése,
• ...

Hogy csak néhányat említsek.

Namost egy ilyen környezetben, ahol a csillagsémás adattárházon OLAP kockák ülnek, a lekérdezések 90 %-át az OLAP oldal felé indítják. (100%-ot akartam írni csak féltem, hogy ez kiveri a harmadik biztosítékot is…) Tehát a felhasználók ritkán futtatnak lekérdezéseket a relációs adattárház felé, így az adattárházat, a lekérdezések gyorsítása miatt felesleges indexelni.

Más kérdés azonban az, hogy a relációs adattárház betöltések és az OLAP adatbázis feltöltésének gyorsítására szükséges lehet indexet építeni. A relációs adattárház betöltésének gyorsítását most hagyjuk, mert ha kell is index, arra hogy az milyen legyen nincs általános szabály. Nézzük az OLAP felösszegzések gyorsítását:

Az OLAP adatbázis úgy tudjuk feltölteni és felösszegezni, hogy kiadjuk a „Process” parancsot, ami kihúzza az SQL adatbázisból a szükséges adatokat (Azaz lekérdezi a relációs adattárházat) Ezek a relációs lekérdezések javarészt olyan egyszerűek, hogy hiába teszünk indexet a ténytáblára, nem lesz tőle gyorsabb az OLAP adatbázis feltöltése. Persze vannak extrém esetek is, de még ekkor sem kell kihívni a világ legdrágább optimalizáló szakemberét, hiszen

Az OLAP mindig ugyanazt a lekérdezést fogja elküldeni a relációs adatbázis felé. Így nem kell mást tennünk, mint kimásolni az OLAP által elküldött lekérdezést, és erre a lekérdezésre ráengedni az Index Tuning Wizzardot, majd a kapott javaslatoknak megfelelően indexelni a ténytáblát.

Próbálja ki! Nem kerül sokba kimásolni az OLAP által a relációs adatbázis felé küldött lekérdezéseket és bemásolni az Index Tuning Wizzardba, majd indexelje fel a ténytáblát. Ismételje meg az utolsó betöltést, és ha jobb eredményt kap indexszel mint index nélkül, akkor kell az index. (A teljes betöltés időszükségletét nézze elejétől a végéig, ne csak az OLAP-ot!)

Ténytáblák indexelése OLAP mentes környezetben.

Persze lehet, hogy nem használ OLAP-ot, és színtisztán relációs lekérdezéseket ereszt az adattárházra. Ebben az esetben az ökölszabály azt mondja, hogy tegyen a ténytábla minden idegen kulcs oszlopára egy-egy indexet. Clusered-et az idő dimenzió kulcsoszlopára, és Nonclustered-et az összes többi idegen kulcs oszlopra.

Dimenziótáblák indexelése

Bár ténytáblákra nem szoktam, de a dimenziótáblákra mindig teszek indexet. Egy clustered indexet a Primary Key-re (a dimenziótábla mesterséges kulcs oszlopára) és egy Noncustered indexet a természetes kulcs oszlop(ok)ra.

Összefoglalás:

Egy adattárház indexelése a konkrét lekérdezések ismerete nélkül nem túl egyszerű feladat. Épp ezért megpróbáltam összeszedni azokat az általánosan bevált indexelési stratégiákat, amelyeket fel fog tudni használni az adattárháza első indexelési stratégiájának kialakításához.

Sok sikert a megvalósításhoz!