Miért gyorsak az OLAP adatbázis-kezelők?

Az OLAP adatbázis-kezelők gyorsaságának egyik oka az, hogy előre felaggregálják azokat az adatokat, amelyekről úgy gondolják, hogy szükségük lesz rájuk a felhasználóknak. A kérdés csak az, hogy honnan tudják, hogy mire lesz szükségük a felhasználóknak?

Először is le kell szögeznünk, hogy az adatok összes lekérdezési szempont (attribútum) szerinti felaggregálása több okból is hátrányos. Egyrészről azért mert az összes adat felaggregálása nagyon sokáig tartana, másrészről a túl sok aggregáció kiszámítása és letárolása egy bizonyos szint után már nem gyorsítaná tovább a lekérdezéseket.

A kérdés csak az, hogy hol ez a határ? Tapasztalatból tudjuk, hogy kb. 500-nál több aggregáció elkészítése már nem fogja tovább gyorsítani a lekérdezéseket. De melyik legyen ez az 500 aggregáció?

A kérdés megválaszolásához első körben ismerjük meg, hogy az Analysis Services hogyan dönti el mindezt.

Nos. Az Analysis Services meglehetősen konzervatívan viselkedik akkor, amikor eldönti, hogy mely attribútumokra készítsen aggregációkat és melyekre ne:

• A nem aggregálható attribútumokra MINDIG készít aggregációt
• Az elemi (kulcs) attribútumokra illetve a hierarchiák szintjeire LEHET, hogy képez majd aggregációt (azt, hogy igen vagy nem más szabályok alapján dönti el, de ezeket az attribútumokat mindenképpen figyelembe veszi az aggregációk tervezésekor)
• A többi attribútumra NEM készít aggregációt.

Mindezekből látszik, hogy az Analysis Services aggregáció tervezője szinte csak a kulcs- és a hierarchiákat alkotó attribútumokra készít aggregációt. Azokra is csak talán...

Nézzük meg hogyan téríthetnénk le az Analysis Services aggregáció tervezőjét e konzervatív útról és mivel segíthetünk neki, hogy ennél egy kicsit okosabban tervezze meg az aggregációkat

Meta adatok kitöltése

Minden dimenziónak és adatkockának vannak olyan meta adatai, amelyeket feltöltve segíthetünk az aggregáció tervezőnek, hogy jobban meg tudja határozni az aggregálandó attribútumok körét. Ha például a dimenzió- és ténytáblák elemszámát kitöltjük, akkor ezzel segítünk az aggregáció tervezőnek az aggregációk költségének becslésben, ami végső soron hatékonyabb aggregáció tervezést és így jobb lekérdezési teljesítményt eredményez.

Attribútumok javaslása

A meta adatok kitöltésén túl úgy is segíthetünk, az aggregáció tervezőnek, ha megsúgjuk neki, hogy szerintünk mely attribútumokra kéne aggregációt terveznie.

Ha például úgy gondoljuk, hogy a termék színe egy olyan attribútum lesz, amelyre érdemes aggregációt tervezni, akkor megmondhatjuk az aggregáció tervezőnek, hogy

• vegye figyelembe az aggregáció tervezése során ezt az attribútumot is (Ne felejtsük el, hogy a termék színe nem elemi cikk, nem része a hierarchiának így az Analysis Services alapértelmezés szerint nem is gondolkodik abban, hogy aggregációt tervezzen rá)
• mindentől függetlenül tervezzen rá aggregációt

Így végső soron további támpontokat tudunk adni az aggregáció tervezőnek amelyek révén hatékonyabbá válik az aggregáció tervezés.

Lekérdezés alapú aggregáció tervezés

Amikor egy kockát tervezünk még csak sejtjük, hogy mely aggregációkat fogják a felhasználók használni. Később, amikor már lesz információnk arról, hogy a mit használnak ténylegesen, akkor lehetőségünk lesz a tényleges felhasználói szokásokat figyelembe véve megtervezni az aggregációkat. Mindezt megvalósíthatjuk úgy, hogy explicit módon kijelöljük a felaggregálandó attribútumok körét, vagy úgy is, hogy a lekérdezési statisztikák alapján kiválasztjuk a top 100 leglassabban futó lekérdezést és ezek elemzése alapján határozzuk meg az aggregálandó attribútumok körét. (Így működik az Analysis Services usage based optimalizációs eljárása is.)

Különösen hasznos a lekérdezés alapú optimalizáció az idő mentén partícionált kockák esetén. Ha feltételezhetjük, hogy a következő hónap lekérdezési szokásai azonosak lesznek az előző hónap lekérdezési szokásaival, akkor megtervezhetjük az új partíció aggregációit az előző hónap lekérdezési szokásai alapján is. így elérhetjük azt, hogy a felhasználók szokásainak változásaihoz igazítsuk a kocka aggregációinak tervezését.

Összefoglalva: Az Analysis Services aggregáció tervezője meglehetősen konzervatív: Szinte csak a kulcs- és a hierarchiákan használt attribútumokra tervez aggregációkat. Azonban az esetek nagy részében ez is elegendő. Általános tapasztalat, hogy jó eredményeket kapunk, ha helyesen kitöltjük a kocka meta adatait (pl.: dimenzióelemek és ténytábla sorok száma) és a 30%-os aggregáció szintet állítunk be az aggregáció tervezésekor. Ha azonban a lekérdezési statisztikákból úgy látjuk, hogy ez kevés, vagy a betöltési ablak rövidsége miatt optimalizálnunk kell a felösszegzéseket, akkor van lehetőségünk a tapasztalataink és felhasználók szokásai alapján is segíteni az aggregáció tervezőnek. (Bővebb információt e témáról az alábbi dokumentumokban talál:Analysis Services Performance Guide; Analysis Services Processing Architecture; Analysis Services Processing Best Practices)

Végül pedig a szolgálati közlemény: Ma jár le a kedvezményes jelentkezési határidő az adattárház projektvezető képzésre.

Ha úgy tervezi, hogy jön, akkor még ma regisztráljon mert

• ma még sokkal kevesebbet kell fizetni érte
• holnap le fogom foglalni a termet így ettől a naptól kezdve már kötve leszünk a terem befogadó képességéhez.

Regisztrálok >>