Egy nagy kocka vagy sok kicsi - A fejlesztői élmény
A múlt heti cikkben a „sok kis adatkocka vagy egy nagy" problémát az üzleti felhasználók oldaláról közelítettük meg. Azt vizsgáltuk, hogy a felhasználói élmény szempontjából melyik a jobb megoldás. Csak emlékeztetőül:
A hardcore üzleti felhasználók, kontrollerek, power userek előbb-utóbb ki fogják maguknak követelni a nagy, minden dimenziót és mutatószámot tartalmazó kockát. A „turistáknak" és a vezetőknek viszont nem erre van szükségük. Ők ebben a hatalmas térben eltévednének. Nem értenék, hogy miért van egy hierarchiának többfajta változata, mit keres a költségek mellett a termék dimenzió. Nekik kicsi, egyszerűen használható, tömör minden metszetében értelmezett adatkockákra van szükségük.
E kettősséget úgy tudjuk feloldani, hogy egy nagy kockát készítünk és ezt a nagy kockát a relációs nézetekhez hasonló „perspektívákkal" szétvágjuk kis kockákra. Lesznek aktuális (ahogy van) és historikus (ahogy volt) nézetek; megrendelt, kiszámlázott, kiszállított, stb. nézetek. Ezeket a nézeteket adjuk majd oda a tömegeknek, és a nagy kocka megmarad a hardcore kontrollereknek, üzleti elemzőknek.
Nagy adatkocka feldarabolása perspektívákkal
Még egy gondolat az előző cikkhez kapcsolódó jegyzetből: Egyszerűbb úgy megtervezni egy adatpiacot, egy vezetői információs rendszert, ha nem egyből az egész tervezésének ugrunk neki, hanem részfolyamatokra/szakterületekre koncentrálunk, nekik tervezünk kockákat, majd ahogy bővül, gyarapodik tudásunk, úgy fordulunk a nagy kocka megtervezése felé. Természetesen jó lenne az is, ha ezt a fajta megközelítést támogatná az alkalmazott technológia, esetünkben az Analysis Services. Nézzük:
Nagy kocka építése sok kis kocka összekapcsolásával
Az Analysis Service kétféle szolgáltatással is támogatja, hogy a több kis fizikai adatkockákból egy nagy „virtuális" adatkockát építsünk. Ezek a LookUpCube MDX függvény és a linked measure group szolgáltatások. Mindkét szolgáltatás azt a célt szolgálja, hogy egy már meglévő adatkockába be tudjunk hivatkozni egy másik adatkockát, vagy annak egy szeletét. Ezek segítségével kis kockából el tudunk indulni elvileg a nagy kockák felé. Azért mondom, hogy elvileg, mert a gyakorlatban ezek a szolgáltatások nem mindig váltják be a hozzájuk fűzött reményeket.
LookupCube MDX függvénnyel behivatkozott részkocka
A LookUpCube MDX függvény sokszor túlságosan lassú, a Linked measure group pedig, bár minden szempontból nagyon ígéretes, de lehetetlen karbantartani. Addig minden OK, amíg összelinkeljük a kockákat, de ha valamelyikben változtatunk valamit, például egy új attribútumot adunk az egyik dimenzióhoz, vagy megváltoztatjuk egyik számított mezőnk képletét, akkor ezeket a változtatásokat abban az adatkockában is le kell követni, amelyik hivatkozik a megváltozott kockára. Kézzel. Frissítésre lehetőség nincs.
Mindezeket figyelembe véve a gyakorlatban nem érdemes kis kockákból egy nagyot építenünk. Egy nagy kockát kell terveznünk és azt kell szétdarabolnunk a perspektívák segítségével. Ám ennek az útnak is vannak nehézségei:
Az egy nagy kocka koncepció hátrányai
- Egy nagy kockában sokkal nehezebb a jogosultságokat menedzselni, mint sok kis kockában
- Üzemeltetés, karbantartás szempontjából jóval egyszerűbb kis kockákkal dolgozni, mint egy naggyal. (kis kocka esetén átláthatóbbak az MDX scriptek, ha nem sikerül felösszegezni egy kis kockát attól a többi még elkérhető marad, ...)
- A perspektívákkal történő vágás lehetőségét csak az Enterpise Edition tartalmazza. A Standard edition-ből ez a szolgáltatás kimaradt
Mindent összefoglalva: Ha úgy látja, hogy előbb utóbb szükség lehet a kis kockák összekapcsolására, akkor mindenképpen célszerű nagy kockában gondolkodni. Jobb teljesítményt fog adni a nagy kocka, mint az összekapcsolt kis kockák, sokkal szofisztikáltabb elemzési igényeket lesz képes kielégíteni, mint a szeparált adatkockák, stb. Persze nehezebb egy ilyen kockát megtervezni, de ebben tudok segíteni.
Egy dologra azonban ügyeljen: csak olyan kockákat kapcsoljon össze, amelyeknek közel azonos a dimenzionáltsága. Sok példa kering az interneten, sőt maga Kimball is azt javasolja, hogy egy kockát építsünk az adattárházra, azonban ettől mindenkit óva intenék...
Más. A héten megtörtént az MSDN előfizetés kisorsolása. A 9 tagú sorsolási bizottság jelenlétében kihúzott nyertesek:
Ragasits Csaba és Palotai László
Nekik gratulálok a többieknek pedig köszönöm, hogy bemutatkozásukkal hozzásegítettek ahhoz, hogy számomra is és mások számára is érthető legyen, hogy kik, és miért olvassák a BI projekt blogot. KÖSZÖNÖM!
Kővári Attila - BI projekt
hozzászólás
Köblös István
h, 09/20/2010 - 11:06
Permalink
Performancia
Kővári Attila
k, 09/21/2010 - 20:54
Permalink
Egy nagy kocka vagy sok kis kocka - a teljestímény szempontjai
Köblös István
p, 09/24/2010 - 14:04
Permalink
Kösz szépen az infókat
Új hozzászólás