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
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.
Ebből a blogból megtudhatja, hogyan mentheti automatikusan az e-mail mellékleteket a SharePointba, majd törölheti az e-maileket a Power Automate segítségével.
A Microsoft LuckyTemplates irányítópult 18 legjobb példája 2023
Ismerje meg, hogyan hozhat létre <strong>Power Automate</strong> folyamatokat a semmiből. Sablon használata helyett mi magunk hozzuk létre a kiváltó okokat és a műveleteket.
4 módszer a Pi használatára a Pythonban példákkal
Ebben az útmutatóban bemutatom, hogyan lehet Pénzügyi információk mátrixát létrehozni a Profit és veszteség (P&L) kimutatással a LuckyTemplates alkalmazásban.
Fedezze fel, hogyan lehet dinamikusan egyesíteni oszlopokat a Power Query Table.CombineColumns függvény segítségével.
Ismerje meg, hogyan adhatjuk hozzá és szinkronizálhatjuk SharePoint-fájljainkat az asztalon és a OneDrive-on.
Tudja meg, miért fontos egy dedikált dátumtáblázat a LuckyTemplatesben, és ismerje meg ennek leggyorsabb és leghatékonyabb módját.
Ez a rövid oktatóanyag kiemeli a LuckyTemplates mobil jelentési funkcióját. Megmutatom, hogyan készíthet hatékony jelentéseket mobileszközökön.
Ebben a LuckyTemplates bemutatóban olyan jelentéseket tekintünk át, amelyek professzionális szolgáltatáselemzést mutatnak be egy olyan cégtől, amely több szerződéssel és ügyfél-elkötelezettséggel rendelkezik.
