Analysis Services 2008 újdonságok - Block computation

Ha egyetlenegy mondattal kéne összefoglalnom a block computation lényegét, akkor az a következő lenne: A block computation egy olyan újdonság, aminek eredményeképpen jelentősen felgyorsulnak az MDX lekérdezések, és ez első sorban annak köszönhető, hogy a szerver figyelmen kívül hagyja a NULL tartalmú cellákat.

Később majd még finomítjuk ezt a definíciót, mert a teljesítmény növekedés nem csak nagyon lyukacsos (tele van NULL értékekkel) kockákra lesz érvényes. De most még induljunk el így és nézzük meg, hogy miért lettek jelentősen gyorsabbak az Analysis Services 2008 felé küldött MDX lekérdezések, mint az Analysis Services 2005 felé küldöttek.

Megjegyzés: A block computation szinonimájaként elterjedt fogalom még a Subspace Computation és a Bulk evalution is. (Ezen fogalmak ugyanazt jelentik mint, a block computation)

A blokkonkénti számítás (block computation) működése az Analysis Services 2008-ban

Képzeljük el a következőt: Le kell kérdeznünk az előző év és az aktuális év internetes megrendelésének összegét, városonként (kicsit holdbéli a példa, de könnyen elmagyarázható vele a block computation működése)

Nézzük meg, hogy néz ki az aktuális év (2004) és az előző év internetes megrendelése városonként:

A feladatunk tehát az, hogy előállítsuk a két év gördülőösszegét, amit a következő lekérdezéssel érhetünk el:

WITH MEMBER [Measures].[RollingSum] AS ([Date].[Calendar Year].PrevMember, [Internet Order Quantity]) + [Internet Order Quantity]

SELECT

[Date].[Calendar Year].&[2004] ON 0,

[Customer].[City].members ON 1

FROM [Adventure Works]

WHERE [Measures].[RollingSum]

Most nézzük meg, hogyan dolgozta fel ezt a lekérdezést az Analysis Services 2005: Mivel az Analysis Services 2005 még celláról cellára dolgozta fel a lekérdezést, ezért összeadta minden város internetes megrendeléseinek számát, pedig a fenti példában összesen 3 olyan város van, aminek volt internetes megrendelése. Így a maradék városok rendelésösszegét teljesen feleslegesen számolta ki az Analysis Serviced, hiszen onnan nem történt megrendelés.

Kiértékelés celláról cellára (Analysis Services 2005)

Képzeljen el egy bazi nagy lyukacsos kockát. Celláról cellára kiszámolni minden elemhez a szummákat meglehetősen nagy erőforrás pocsékolás. De a celláról cellára való kiértékelésnek nem csak lyukacsos kockán van teljesítmény romboló hatása, hiszen az Analysis Services belső folyamatai is celláról cellára ismétlődnek (pl egy rekurzivitás vizsgálat), ahelyett, hogy ez egyszer, egy nagyobb blokkon történne csak meg.

Most, hogy már ismert a probléma, nézzük meg milyen megoldást ad erre az Analysis Services 2008: Az Analysis Services 2008 két blokkot fog összeadni:

1. 2003 nem üres internetes rendeléseit (Esetünkben Ballard, Basingstoke hants és Baytown városokét)
2. 2004 nem üres internetes rendeléseit (Esetünkben Ballard városét)

Ez a példában szereplő 10 összeadás helyett mindössze 3-at jelent.

Kiértékelés blokkonként (Analysis Services 2008)

Hát ez remek! Ezzel a fejlesztéssel rendkívüli módon fel fognak gyorsulni a lekérdezéseink. De - és itt álljunk meg egy szóra (ahogy Grétsy tanár úr mondta).

Ahhoz, hogy a lekérdezéseink a Block computation hatására felgyorsuljanak, ahhoz olyanokat kell írnunk, amelyeket kihasználják a block computation előnyeit.

Tudnunk kell ugyanis, hogy nem mindegyik MDX függvényt optimalizálták a block computation-re. Szerencsére a Books Online tartalmazza, hogy mely függvényeket igen. (bár megpróbálták jól eldugni ezt az információt egy „Performance Improvements for MDX in SQL Server 2008 Analysis Services" című dokumentumba, amelyben egyszer sem szerepel a block computation szó...)

Nézzünk egy konkrét példát. Maradjunk a fenti lekérdezésnél, és fogalmazzuk át úgy, hogy mutassuk meg hány olyan terméket rendeltek, amelyre legalább 5 rendelés érkezett az interneten. Íme a lekérdezés:

WITH MEMBER [Measures].[5-nel tobb interneten rendelt termek] AS Count(Filter([Product].[Product].[Product], [Measures].[Internet Order Quantity] > 5))

SELECT

[Customer].[Customer Geography].[Country] ON 0,

[Date].[Calendar].[Date].MEMBERS ON 1

FROM [Adventure Works]

WHERE [Measures].[5-nel tobb interneten rendelt termek]

Lefuttatva ezt a lekérdezést egy Analysis Services CTP 5-ös virtuális masinán 1 perc 6 másodperces válaszidőt kaptam. (vekkerrel mérve meleg cache-en). Hmmm. Ez nem az a performancia amire számítottunk. Elővéve az előbb említett doksit, kiderül, hogy a filter MDX függvény nincs optimalizálva a Block computation-ra, tehát az továbbra is cell by cell módon értékelődik ki. Ez egyben azt is jelenti, hogy ez a lekérdezés ugyanannyi idő alatt fog lefutni Analysis Services 2008-on, mint 2005-ön.

Essünk neki az MDX lekérdezésnek az átírásának úgy ahogy Mosha javasolja, hogy kiküszöböljük a cell by cell módon kiértékelődő filter MDX függvényt.

Miközben ezen sorokat írom Galyatetőn vagyok a családdal. Már késő van, a gyerkőcök alszanak, és én a szálló bárjában írom a cikket miközben a zenekar a Trombitás Frédi, a besszame múcsó után eljátszotta az „I need a hero" című számot. Erről nekem rögtön eszembe jutott a Microsoft „hősök" témája, és képzeletben mindenkit befoglaltam kapcsos zárójelek közé. (Mint az OTP Sajátkártya reklámban, akik tartanak egy nagy plexi lapot, ami mögül kijön a vonat, csak az én plexilapomon kapcsos zárójelek vannak...)

És még az időt sem sajnáltam e borzalmas ábra beillesztésére...

De kanyarodjunk vissza az MDX optimalizálásához. A fenti filter-es MDX-szel egyenértékű lekérdezést kapunk, ha átalakítjuk az alábbi formára:

WITH MEMBER [Measures].[5-nel tobb interneten rendelt termek] AS Sum( [Product].[Product].[Product], Iif([Measures].[Internet Order Quantity] > 5,1,NULL))

SELECT

[Customer].[Customer Geography].[Country] ON 0,

[Date].[Calendar].[Date].MEMBERS ON 1

FROM [Adventure Works]

WHERE [Measures].[5-nel tobb interneten rendelt termek]

Ez a lekérdezés már nem cell by cell értékelődik ki és így képes kihasználni a block computation előnyeit. És az eredmény? 1 másodperces válaszidő (szintén vekkerrel mérve, meleg cache-en) Ez nagyjából 66 szoros sebességnövekedést eredményezett. Meggyőző nem?

Na jó. Egy kicsit csaltam, mert ezen a lekérdezésen a Count(Filter()) cseréje Sum(iif())-re, még SSAS 2005-ön is jelentős teljesítménynövekedést eredményezett volna. :-) De Mosha tesztje is az mutatja, hogy pusztán a block computation-ból származó teljesítmény növekedés is lehet 20 szoros!

Összefoglalva: A block computation valószínűleg az Analysis Services 2008 legfontosabb újdonsága lesz. Ha hihetünk a jelenleg rendelkezésre álló információknak és teszteknek, akkor Analysis Services 2008-ra váltva a lekérdezések jelentős része sokkal gyorsabban fog futni, mint 2005-ön futott.

De ez nem lesz minden lekérdezésre automatikusan igaz, hiszen vannak olyan MDX függvények, amelyek nem lettek a Block computation-re optimalizálva és azokat továbbra is cell by cell módon fogja az Analysis Services lekérdezni. A mi feladatunk az, hogy erre odafigyeljünk és kerüljük a block computationra nem optimalizált MDX kifejezések használatát.