Gegevensindexering in Vertipaq: rijopslag versus kolomopslag

In deze zelfstudie gaan we het verschil bespreken tussen hoe gegevensindexering werkt in een relationele database versus in Vertipaq.

Relationele databases slaan de gegevens rij voor rij op. Aan de andere kant doet Vertipaq het kolom voor kolom.

Laten we eens kijken hoe deze twee manieren om gegevens op te slaan en te indexeren van invloed kunnen zijn op uw rapportontwikkelingsproces, met name bij het uitvoeren van uw query's.

Inhoudsopgave

• Gegevensindexering per rij
• Gegevensindexering per kolom
• Uitvoeringstijd vergelijken in eenvoudige query's
• Vergelijking van uitvoeringstijd in meer gecompliceerde query's
• Conclusie

Gegevensindexering per rij

Het rij voor rij opslaan van de gegevens is de traditionele manier om gegevens op te slaan. Dit proces kost echter meer tijd, wat invloed heeft op de prestaties van uw zoekopdracht.

Laten we zeggen dat we een tabel hebben met het merk, de kleur, het geslacht, de hoeveelheid en de nettoprijs.

Als we alles in deze tabel in een database opslaan, worden de gegevens rij voor rij opgeslagen. Daarom wordt de traditionele gegevensopslagstructuur ook wel rijopslag genoemd.

Ten eerste worden in dezelfde regel de kolomkoppen opgeslagen die op de eerste rij zijn gevonden: merk, kleur, geslacht, hoeveelheid en nettoprijs. Daarna gaat het verder naar de volgende regel om de eerste items onder elke kolom op te slaan: A. Datum, Azure, een spatie, 1 en 103.2. Dit gaat rij voor rij door.

van de hoeveelheid berekenen met behulp van deze gegevensindexeringsmethode?

Ten eerste begint het met de eerste rij, die de kolomkoppen bevat. Vervolgens springt het naar de volgende regel en springt het door de andere gegevens totdat het bij de eerste hoeveelheid komt die het ziet, namelijk 1. Vervolgens springt het van regel naar regel, doorloopt alle gegevens die elke rij bevat en verzamelt alle hoeveelheden zijn vondsten.

Zodra het alle hoeveelheden van elke rij opzij heeft gezet, is dat de enige keer dat de berekening is voltooid.

U kunt zich waarschijnlijk voorstellen hoe vervelend het proces is als u een LuckyTemplates-rapport voorbereidt dat gebruikmaakt van een DirectQuery-verbinding met een SQL-gegevensbron. In dit geval gaan analyseservices de DAX-code converteren naar de SQL-taal en vervolgens rij voor rij door de datastructuur gaan.

Gegevensindexering per kolom

Om het langdurige proces te voorkomen, heeft u de mogelijkheid om de gegevens kolom voor kolom op te slaan via Vertipaq wanneer u de importmodus kiest.

Wanneer u een kolomopslag gebruikt in plaats van een rijopslag, worden het merk, de kleur, het geslacht, de hoeveelheid en de nettoprijs elk opgeslagen in verschillende gegevensstructuren.

Laten we zeggen dat we de SOM van de waarden in de kolom Hoeveelheid willen hebben. Het is niet nodig om het merk, de kleur en andere gegevens buiten de kolom Aantal door te geven. In een enkele scan leest het de volledige kolom Hoeveelheid van boven naar beneden en somt alle waarden op.

Hierdoor worden de query's sneller uitgevoerd in vergelijking met het doen van links naar rechts.

Uitvoeringstijd vergelijken in eenvoudige query's

Om het enorme verschil tussen rijopslag en kolomopslag echt te zien, laten we enkele testquery's uitvoeren in zowel SQL als Vertipaq. De uitvoeringstijd zou ons moeten vertellen hoe snel het ene proces is in vergelijking met het andere.

Laten we beginnen met een eenvoudige query in SQL. We gaan berekenen voor de SOM van de kolom Hoeveelheid in de tabel Verkoop.

Zoals u kunt zien, is de totale uitvoeringstijd 2,2 seconden.

Laten we nu naar DAX Studio gaan en de functie EVALUATE gebruiken om dezelfde query uit te voeren. We moeten de servertiming inschakelen en wachten tot de tracering is voltooid.

We moeten er ook voor zorgen dat de optie "Cache wissen en uitvoeren" is geselecteerd wanneer we de query uitvoeren.

Zodra de query is uitgevoerd, ziet u dat het slechts 3 milliseconden duurt om dezelfde query uit te voeren als eerder in SQL.

De resultatenset moet ook overeenkomen voor zowel SQL als DAX Studio. Als we ze naast elkaar leggen, kunt u zien dat we dezelfde waarde retourneren.

U kunt proberen de query nog een paar keer uit te voeren om te zien hoe consistent de uitvoeringstijd is.

Vergelijking van uitvoeringstijd in meer gecompliceerde query's

Laten we deze keer de uitvoeringstijd vergelijken wanneer we ingewikkeldere query's uitvoeren.

Laten we zeggen dat we de SOM van de verkoophoeveelheid voor elk merk willen identificeren . Om dit te doen, kunnen we gebruiken boven de van het merk van elk product. In de lage context maken we ook een nieuwe tabel met de naam Totale hoeveelheid, waarin we de SOM van de verkoophoeveelheid gaan

Als we deze code uitvoeren, kunt u zien dat de totale uitvoeringstijd 7 milliseconden is.

Op de achtergrond voert deze code eigenlijk twee query's uit. De eerste neemt de kolom Merk uit de tabel Producten en voert vervolgens een OUTER JOIN uit op de productsleutelkolommen van zowel de kolom Verkoop als de kolom Producten.

De tweede query haalt eenvoudigweg de kolom Merk op uit de tabel Producten.

Als ik naar het resultatenscherm ga, kun je zien dat de totale hoeveelheid is opgesplitst op basis van elk merk.

Laten we nu naar de SQL-server gaan en dezelfde query schrijven.

We pushen de DaxStudio Sales-tabel naar de volgende regel, verwijzend naar de Sales-tabel AS S. Vervolgens gaan we ook een LEFT JOIN uitvoeren in de DaxStudio Products-tabel waarnaar wordt verwezen ASP, met de S.Product Key gelijk aan de P.Productcode. We gaan ook P.Brand gebruiken met de SOM van de hoeveelheid en de totale hoeveelheid in de SELECT- instructie. Ten slotte gaan we gebruiken voor P.brand.

Zodra we deze code uitvoeren, krijgen we een tabel met de totale hoeveelheid, gescheiden door elk merk, wat hetzelfde is als wat we eerder in Vertipaq kregen.

Wat de totale uitvoeringstijd betreft, deze blijft met 2,5 seconden veel langzamer.

DAX voor LuckyTemplates: optimaliseren met behulp van formule-engines in DAX Studio
Technieken en lessen voor het optimaliseren van DAX-query's
Queryprestaties en DAX Studio-instellingen

Conclusie

Het is duidelijk hoe snel de kolomopslag via Vertipaq werkelijk is in vergelijking met de rijopslag in een SQL-database. Dit toont aan hoe belangrijk het is om echt te leren hoe data-indexering werkt via verschillende platforms.

Het lijkt in eerste instantie misschien een kleine opoffering als je er toch voor kiest om voor de 2,5 seconden te gaan dat de rijopslag je query uitvoert in vergelijking met 7 milliseconden. Maar we voeren allemaal verschillende query's uit wanneer we onze rapporten maken en al die uitvoeringstijden zullen optellen, wat op de lange termijn invloed heeft op de productiviteit en gebruikerservaring.