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!

 

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Kővári Attila
2010. szeptember 20.
Címkék:

3 Hozzászólás

Performancia

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

Egy nagy kocka vagy sok kis kocka - a teljestímény szempontjai

Szia István,

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 15-30 %-os lekérdezési teljesítménynövekedésről számoltak be. Ők a vágással, illetve a kisebb MDX scripttel magyarázták a teljesítménynövekedést.

Chris Webb ugyanakkor már óvatosabban fogalmaz 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.

Ami érdekes, és ami sok mindent megmagyaráz, az Akshai Mirchandani egyik fórum hozzászólása. Ő 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.

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.

Üdv, Attila

Kösz szépen az infókat

Kösz szépen az infókat

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára