Tárolómotor – szerepe a LuckyTemplates DAX-lekérdezések optimalizálásában

Ebben az oktatóanyagban az elemzési szolgáltatásokon belüli második motort – a tárolómotort – tekintjük át.

Megbeszéltük a legfelső szintű motort, a, egy korábbi oktatóanyagban. Ha a felhasználók megértik, hogyan működik mindkét motor, könnyebb optimalizálni és javítani a DAX-lekérdezések teljesítményét.

A tárolómotor fő célja, hogy közvetlenül működjön együtt az adatbázissal.

A képletmotornak nincs közvetlen hozzáférése az adatbázishoz, ezért általában a tárolómotoron megy keresztül erre a célra.

A tárolómotornak két típusa van: importálási mód és DirectQuery . Kompozit modell létrehozásához ugyanabban az adatmodellben mindkét típust keverheti és egyeztetheti.

Tartalomjegyzék

• Az importálási mód használata a tárolómotorban
• A DirectQuery használata a tárolómotorban
• Kompozit modellekkel való munka
• Egyéb kritikus pontok a tárolómotorral kapcsolatban
• Bonyolult lekérdezések kezelése
• Következtetés

Az importálási mód használata a tárolómotorban

Először beszéljünk az importálási módról. Ezt közismertebb nevén Vertipaq is, de xVelocity-nek vagy In Memory Columnar Database-nek is nevezik.

Négy fontos dolgot kell megérteni az importálási mód működésével kapcsolatban.

Először a Vertipaq másolatot készít az adatokról közvetlenül az adatforrásból, és tömörített formátumban tárolja a RAM-ban .

Másodszor, az importálási módban feldolgozott adatok az utolsó frissítési műveleten alapulnak . Ez azt jelenti, hogy ha legutóbb a múlt héten frissítette adatait, akkor az Ön által kezelt adatok továbbra is ugyanazok a múlt heti adatok. Ez különösen fontos, ha összetett beállítást használ, ahol az egyik tábla importálási módban, a másik pedig DirectQuery módban van.

Tegyük fel, hogy a múlt héten frissített Termékek táblázat importálási módban van. Ami az Értékesítési táblát illeti, a mérete miatt úgy döntött, hogy a DirectQuery-n keresztül vezeti be. Tételezzük fel azt is, hogy a jelentést mindkét olyan táblázat alapján hozza létre, amelyekbe beviszi a Márka oszlopot, és létrehozza a Teljes értékesítés mértékét ugyanabban az értékesítési táblázatban. Az értékesítési összeget is szeretné megjeleníteni a márka alapján.

Először frissítenie kell az importálási módból származó adatokat, mert előfordulhat, hogy friss és frissített adatokat kaphat a DirectQuery-ből, illetve elavult adatokat a Vertipaq-ból. Ez néhány üres sort hagy a mátrixon és a vizualizáción.

A következő dolog, amit tudnia kell a Vertipaq-ról, hogy csak az alapvető műveletek, például a , , vagy natív módon érhetők el . Ez azt jelenti, hogy ha a lekérdezési terv más bonyolultabb műveleteket is tartalmaz, a tárolómotornak meg kell hívnia a képletmotort a kód ezen részének feloldásához.

Végül, a tárolómotor a Vertipaq oszlopos szerkezete miatt rendkívül optimalizált adatbázis . Ez azt jelenti, hogy az összes adatot oszloponként tárolja, nem pedig soronként. Ennek a szerkezetnek köszönhetően a Vertipaq mindig gyorsabb lesz, mint egy DirectQuery kapcsolat, még akkor is, ha indexeket hoz létre a relációs adatmodellben.

A DirectQuery használata a tárolómotorban

A következő lehetőség a LuckyTemplates elemzési szolgáltatásokon belül a DirectQuery. Ha a DirectQuery kapcsolatot használja, az elemzési szolgáltatások csak a képletmotor által küldött lekérdezések átadásaként működnek.

Tehát tegyük fel, hogy ír egy lekérdezést. A képletmotor lekérdezési tervet generál. Ezután továbbítja a lekérdezést a tárolómotornak, amely már le van fordítva az adatbázis anyanyelvére. Ezek a lekérdezések legtöbbször SQL-ben érkeznek.

Ha a lekérdezés DirectQuery-t használ, számítson arra, hogy mindig naprakész legyen. Nem kell aggódnia amiatt, hogy mikor frissítette utoljára az adatokat.

A DAX kód és az adatmodell optimalizálásának folyamata a relációs adatbázis létrehozásának módjától is függ. Ha az oszlopaiban indexek vannak, akkor a lekérdezések mindig optimalizálva lesznek. De ha az adatbázis nincs optimalizálva a jelentések elemzési szolgáltatások vagy LuckyTemplates használatával történő létrehozásához, akkor néhány teljesítménybeli kihívással kell szembenéznie. Legyen tehát tudatos az adatbázisok jelentéskészítésre való készítésénél.

Kompozit modellekkel való munka

A harmadik lehetőség egy összetett modell létrehozása, hogy egy tábla legyen importálási módban és egy másik tábla a DirectQueryben.

Ha két különböző forrásból származó táblát használ, a képletmotor egy kérést küld a Vertipaqnak és egy másik kérést a DirectQuery adatforrásnak. Az elemzési szolgáltatások mindkét esetben lekérik az adatgyorsítótárat a Vertipaq és a DirectQuery rendszerből is. A képletmotor ezután a JOIN parancsot fogja használni,, vagy bármely iteráció mindkét adatgyorsítótárban, mielőtt az eredményeket a végfelhasználónak szolgáltatná.

Tegyük fel, hogy a jelentésben a termék márkája szerint próbálja megjeleníteni az eladási összeget. A képletmotor kérést küld a Vertipaq-nak, ahol lekéri a terméket, a márkát és a termékkulcsot. Ezután a DirectQueryből megpróbálja lekérni az eladásokat, a nettó árat, az értékesítési mennyiséget és az értékesítési termékkulcsot.

Miután a termékkulcson alapuló két adatgyorsítótárral rendelkezik, egyesíti a két adatgyorsítótárat, és kiszámítja a teljes értékesítési összeget. Ezután bemutatja az eredményeket a végfelhasználónak.

Egyéb kritikus pontok a tárolómotorral kapcsolatban

Most, hogy bemutattuk a különböző típusait, van néhány további kritikus tényező, amelyet tudnia kell a tárolómotorról, hogy segítsen optimalizálni a DAX-lekérdezéseket.

Ahogy korábban említettem, a tárolómotor tömörítetlen adatgyorsítótár formájában biztosítja vissza az adatgyorsítótárat a képletmotornak. Amikor importálási módban van, a folyamat során a Vertipaqnak visszaküldött kérés xmSQL nyelven kerül végrehajtásra.

Az xmSQL nyelv némileg hasonlít az SQL-hez, de nem teljesen ugyanaz. Az xmSWL-ről akkor fogunk részletesen beszélni, amikor egy másik oktatóanyagban a lekérdezési tervekről beszélünk.

Azt is fontos megjegyezni, hogy a tárolómotor a CPU-ban elérhető összes magot használja. A több mag használatának lehetősége akkor előnyös, ha több szegmense van az adatmodellben.

Tegyük fel, hogy van egy táblája a LuckyTemplatesben 12 millió sorral. Ez a táblázat ezután 12 szegmensre lesz felosztva, mivel a Power Pivotban és a LuckyTemplatesben is mindegyik szegmens 1 millió sorba fér. Ez eltér az általános elemzési szolgáltatásoktól, ahol egy szegmens 8 millió sort tartalmaz.

Tehát ha hat mag van a CPU-mban, akkor mind a hat mag egyszerre vizsgálja az első hatot a 12 szegmensből. Ha elkészültek, továbblépnek a következő hat szegmensre.

De ha olyan elemzési szolgáltatásokkal dolgozom, ahol az alapértelmezett szegmens 8 millió sort tartalmaz, akkor a hat magomból csak kettő lesz felhasználva – az egyik szegmens 8 millió sort, míg a másik 4 milliót dolgoz fel.

Bonyolult lekérdezések kezelése

Korábban már említettem, hogy az importálási mód csak olyan alapműveleteket támogat, mint a MIN, MAX, SUM, COUNT és GROUPBY. Tehát mi történik, ha bonyolultabb lekérdezéseken dolgozik?

Tegyük fel, hogy úgy dönt, hogy egy IF utasítást használ a sorkontextusban, vagy egy beágyazott iterációt, például a SUMX-et a Termékek és Értékesítések táblákon.

Ebben az esetben a tárolómotor nem tudja önállóan megoldani a lekérdezést. Ezután meghívja a képletmotort, amely soronként elkezdi megoldani a komplex számítást a tárolómotoron belül. Egyesek azt gondolhatják, hogy ez egy kedvező forgatókönyv, mivel mindkét motor együtt működik – de ez messze van az igazságtól.

Láthatja, amikor ez megtörténik, a tárolómotor által előállított adatgyorsítótárat nem lehet gyorsítótárba helyezni, ha az adott lekérdezésben van egy callbackdataID. Tehát ha frissíti a vizualitást, ugyanazt a számítást kell elvégeznie mind a képletmotornak, mind a tárolómotornak, annak ellenére, hogy néhány másodperccel ezelőtt végrehajtotta ugyanazt a lekérdezést. Ez teljesítménybeli késésekhez és rossz felhasználói élményhez vezet.

Vegye figyelembe azt is, hogy a tárolómotor nem tudja, hogy a lekérdezéseket DAX vagy MDX segítségével hajtották-e végre. Ahogy korábban említettük, a képletmotor feladata, hogy a lekérdezéseket a megfelelő nyelvre konvertálja, mielőtt továbbadná a lekérdezési tervet.

Végül a képletmotor egyenként küldi el a lekérdezéseket a tárolómotorba. Ez azt jelenti, hogy a több szegmens használata valóban jobb, így a Vertipaq-on belüli teljes szkennelési idő lerövidíthető, és egyszerre több szegmens kerül beolvasásra.

Következtetés

A tárolómotor csínját-bínját ismerve valóban segít optimalizálni a DAX-lekérdezéseket, különösen, ha a DAX Studiot használja. Ha a képletmotort magyarázó oktatóanyagot is végignézte, jobb döntéseket hozhat a jobban teljesítő lekérdezések létrehozásával kapcsolatban.

Bár a formulamotor a legfelső szintű motorként szolgál, kétségtelen, hogy nem tud olyan jól teljesíteni, mint tud, ha nem maximalizáljuk mindkét motort.

Minden jót,