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.

Egy nagy adatkocka feldarabolása perspektívákkal

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.


A LookupCube MDX függvény működése
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

Szia Attila! Mekkora kockánál járható ez az út? Okoz performancia gondot nagyobb adathalmaznál? Aggregációk és cahce szempontból mindegy az SSAS-nek, hogy egy nagy kocka van, vagy több kicsi? Üdv, István

Szia István,</br></br> A performancia kérdésében nincs egységes álláspont. Analysis Services 2005 használata esetén, a nagy kocka szétdarabolása után Vidas Matelis és Greg Galloway <a href="http://www.ssas-info.com/VidasMatelisBlog/40_splitting-analysis-services-2005-cubes-based-on-measure-groups">15-30 %-os lekérdezési teljesítménynövekedésről számoltak be</a>. Ők a vágással, illetve a kisebb MDX scripttel magyarázták a teljesítménynövekedést.</br></br> Chris Webb ugyanakkor már <a href="http://cwebbbi.spaces.live.com/Blog/cns!7B84B0F2C239489A!7728.entry">óvatosabban fogalmaz</a> a kérdésben. Ő azt mondja, hogy bár Analysis Services 2005 esetén néhány esetben megfigyelhető volt a teljesítménynövekedés, de ez nem következett be minden esetben. </br></br> Ami érdekes, és ami sok mindent megmagyaráz, az Akshai Mirchandani egyik <a href="http://social.technet.microsoft.com/Forums/en-US/sqlanalysisservices/thread/681e59bd-93ca-4a91-9f26-8ed96e825553">fórum hozzászólása</a>. Ő azt mondja, hogy a Storage Engine-re nincs hatással, hogy egy nagy kockát vagy sok kicsit kell kiszolgálnia. Ugyanakkor a Formula Engine-re igen, hiszen egyáltalán nem mindegy mekkora virtuális térrel kell megbirkóznia. </br></br> Magyarországi méretekben én sem tapasztaltam teljesítményben különbséget az egy nagy kocka több kis kocka megközelítés között. Tapasztalataim szerint a teljesítmény a kocka lyukacsosságától vagy kicsit másképpen fogalmazva attribútumainak elemszámának szorzatától függ. Minél lyukacsosabb, minél nagyobb a kocka dimenzióelemei által kifeszített többdimenziós tér, annál rosszabb a kocka teljesítménye. Namost a kocka szétvágásával pont ezeket tudjuk csökkenteni, így elképzelhető, hogy a vágással tényleg növelhető a teljesítmény. Azonban ha a nagy kocka jól van megtervezve és közel azonos dimenzionáltságú measure grouppokat tartalmaz, akkor már korántsem biztos, hogy bekövetkezik ez a fajta teljesítménynövekedés.</br></br> Üdv, Attila

Kösz szépen az infókat

Új hozzászólás