Adatindexelés a Vertipaq-ban: sortároló versus oszloptár

Ebben az oktatóanyagban bemutatjuk, hogy miként működik az adatindexelés egy relációs adatbázisban a Vertipaq-hoz képest.

A relációs adatbázisok soronként tárolják az adatokat. Másrészt a Vertipaq ezt oszlopról oszlopra teszi.

Nézzük meg, hogyan befolyásolhatja az adatok tárolásának és indexelésének ez a két módja a jelentéskészítési folyamatot, különösen a lekérdezések futtatásakor.

Tartalomjegyzék

• Adatindexelés soronként
• Adatindexelés oszloponként
• A végrehajtási idő összehasonlítása egyszerű lekérdezésekben
• A végrehajtási idő összehasonlítása bonyolultabb lekérdezésekben
• Következtetés

Adatindexelés soronként

Az adatok soronkénti tárolása az adattárolás hagyományos módja. Ez a folyamat azonban több időt vesz igénybe, ami hatással lesz a lekérdezés teljesítményére.

Tegyük fel, hogy van egy táblázatunk, amely tartalmazza a márkát, a színt, a nemet, a mennyiséget és a nettó árat.

Ha ebben a táblában mindent eltárolunk egy adatbázisban, akkor az adatokat sorban, soronként tárolja. Ezért a hagyományos adattárolási struktúrát sortárnak is nevezik.

Először is ugyanabban a sorban tárolja az első sorban található oszlopfejléceket – márka, szín, nem, mennyiség és nettó ár. Ezután a következő sorra lép, hogy tárolja az első elemeket az egyes oszlopok alatt – A. Datum, Azure, egy üres, 1 és 103.2. Ez sorról sorra folytatódik.

Tehát hogyan fogjuk kiszámítani aa Mennyiség ezzel az adatindexelési módszerrel?

Először is az első sorral kezdődik, amely az oszlopfejléceket tartalmazza. Ezután a következő sorba ugrik, és átugorja a többi adatot, amíg el nem éri az első általa látott mennyiséget, ami 1. Ezután sorról sorra ugrik, végigfut az egyes sorokban található összes adaton, és összegyűjti az összes adatot. mennyiségeket talál.

Ha az összes mennyiséget félretette az egyes sorokból, akkor a számítás csak ekkor fejeződik be.

Valószínűleg el tudja képzelni, milyen fárasztó ez a folyamat, ha olyan LuckyTemplates-jelentést készít, amely DirectQuery-kapcsolatot használ egy SQL-adatforráshoz. Ebben az esetben az elemző szolgáltatások a DAX-kódot SQL nyelvre konvertálják, majd soronként elkezdik végigmenni az adatstruktúrán.

Adatindexelés oszloponként

A hosszadalmas folyamat elkerülése érdekében lehetősége van az adatokat oszloponként tárolni a Vertipaq-on keresztül, amikor az importálási módot választja.

Ha az oszloptárat használja a sortárhely helyett, a márka, szín, nem, mennyiség és nettó ár mindegyike különböző adatstruktúrákban kerül tárolásra.

Tegyük fel, hogy a Mennyiség oszlopban lévő értékek ÖSSZEGÉT akarjuk megkapni. Nem kell átmenni a Márka, Szín és egyéb adatokon a Mennyiség oszlopon kívül. Egyetlen letapogatás során felülről lefelé beolvassa a teljes Mennyiség oszlopot, és összegzi az összes értéket.

Emiatt a lekérdezések gyorsabban végrehajtásra kerülnek, mint a balról jobbra haladva.

A végrehajtási idő összehasonlítása egyszerű lekérdezésekben

Ahhoz, hogy valóban lássuk a sortároló és az oszloptár közötti óriási különbséget, végezzünk néhány tesztlekérdezést mind az SQL-ben, mind a Vertipaq-ban. A végrehajtási időnek meg kell mondania, milyen gyors az egyik folyamat a másikhoz képest.

Kezdjük egy egyszerű lekérdezéssel SQL-ben. Ki fogjuk számolni az Értékesítési tábla Mennyiség oszlopának SUM értékét.

Mint látható, a teljes végrehajtási idő 2,2 másodperc.

Most menjünk a DAX Studio-ba, és használjuk az EVALUATE függvényt ugyanazon lekérdezés végrehajtására. Be kell kapcsolnunk a szerver időzítését, és meg kell várnunk a nyomkövetés befejezését.

Gondoskodnunk kell arról is, hogy a „Gyorsítótár törlése, majd futtatás” lehetőség legyen kiválasztva a lekérdezés futtatásakor.

A lekérdezés végrehajtása után látni fogja, hogy mindössze 3 ezredmásodperc kell ahhoz, hogy végrehajtsuk ugyanazt a lekérdezést, mint korábban SQL-ben.

Az eredménykészletnek meg kell egyeznie az SQL és a DAX Studio esetében is. Ha egymás mellé tesszük őket, láthatjuk, hogy ugyanazt az értéket adjuk vissza.

Megpróbálhatja még néhányszor futtatni a lekérdezést, hogy lássa, mennyire konzisztens a végrehajtási idő.

A végrehajtási idő összehasonlítása bonyolultabb lekérdezésekben

Ezúttal hasonlítsuk össze a végrehajtási időt, amikor bonyolultabb lekérdezéseket futtatunk.

Tegyük fel, hogy meg akarjuk határozni az értékesítési mennyiség ÖSSZEGét minden márka esetében. Ehhez használhatjukát aminden termék márkája. Alacsonyabb kontextusban létrehozunk egy új táblát Teljes mennyiség néven, ahová megyünkaz értékesítési mennyiség ÖSSZEGÉRE .

Ha ezt a kódot lefuttatjuk, láthatja, hogy a teljes végrehajtási idő 7 ezredmásodperc.

A háttérben ez a kód valójában két lekérdezést futtat. Az első átveszi a Termékek táblából a Brand oszlopot, majd végrehajtja a KÜLSŐ CSATLAKOZÁS a Termékkulcs oszlopokban mind az Értékesítés, mind a Termékek oszlopban.

A második lekérdezés egyszerűen lekéri a Márka oszlopot a Termékek táblából.

Ha az eredmények képernyőre lépek, láthatja, hogy a Teljes mennyiség mértékét az egyes márkák alapján felosztották.

Most menjünk az SQL szerverre, és írjuk be ugyanazt a lekérdezést.

A DaxStudio Értékesítési tábláját a következő sorba toljuk, az értékesítési táblára AS S-ként hivatkozva. Ezután egy LEFT JOIN-t is végrehajtunk a DaxStudio Products táblájában AS P-vel, és az S.Product Key megegyezik a P.Termékkulcs. A P.Brand-ot a SELECT utasításban a Mennyiség és a Teljes mennyiség SUM- jával is fogjuk használni . Végül használni fogjuka P.brand számára.

Miután futtattuk ezt a kódot, kapunk egy táblázatot, amely tartalmazza a teljes mennyiséget az egyes márkák szerint elkülönítve, ami ugyanaz, mint amit korábban a Vertipaq-ban kaptunk.

Ami a teljes végrehajtási időt illeti, sokkal lassabb marad, 2,5 másodperc.

Következtetés

Nyilvánvaló, hogy a Vertipaq-on keresztüli oszloptár valójában milyen gyors az SQL-adatbázis sortárához képest. Ez mutatja annak fontosságát, hogy valóban megismerjük az adatindexelés működését a különböző platformokon.

Elsőre kis áldozatnak tűnhet, ha továbbra is azt a 2,5 másodpercet választja, ameddig a sortároló futtatja a lekérdezést, szemben a 7 ezredmásodperccel. De mindannyian számos lekérdezést futtatunk a jelentések létrehozásakor, és ezek a végrehajtási idők összeadódnak, ami hosszú távon befolyásolja a termelékenységet és a felhasználói élményt.