xVelocity in Deep

xVelocity in Deep
Marco Pozzan
twitter: @marcopozzan
email: info@marcopozzan.it
site: www.marcopozzan.it
#sqlsatParma
#sqlsat355 November 22nd, 2014

Sponsors
#sqlsatParma

Organizers
#sqlsatParma

Speaker info
 MVP SQL Server
 Presidente della community 1nn0va
(www.innovazionefvg.net)
 Project manager del reparto Business
Intelligence presso CGN S.P.A. (www.cgn.it)
 Docente ITS all’Università di Pordenone
 Partecipo agli eventi community
#sqlsatParma

Agenda
 Gestione delle query
 Che cosa è xVelocity in-memory
 Row vs Columnar storage
 RLE e Dictionary Encoding
 Uso memoria: memorizzazione, processing e
query
 Best practice
#sqlsatParma

Gestione delle query
 Direct Query mode
 Trasformazione da DAX a SQL
 Query sul motore SQL Server
 Molte limitazioni (solo connessione SQL, solo DAX no
MDX, limiti DAX, no colonne calcolate, no security)
 In Memory mode
 Engine per elaborare formule DAX (formula engine
DAX)
 Storage Engine Vertipaq (xVelocity in-memory)
 Sfrutta tutte le funzionalità di Tabular
#sqlsatParma

Gestione delle query
DAX/MDX query
Analysis
Services
2012
Tabular
Model
DirectQuery
Mode (Motore di
query)
In-Memory Mode
(Motore di query)
SQL Query
Query
Query
Storage engine query
 PROCESS = Lettura dalla sorgente dati
 Vertipaq contiene il risultato del processing del
database
External
Data
Sources
Process
Vertipaq
Storage
#sqlsatParma

Che cosa è xVelocity in-memory?
 E’ un database in memoria (dati sono in memoria)
 E’ basato su una metodologia relazionale
 Database colonnare
#sqlsatParma

Come lavora un row storage
Alloco spazio su disco
(pagine)
Id FirstName LastName BirthDate
Marital
Status
Children
1 Larry Gill 13/04/1977 00:00 M 1
2 Geoffrey Gonzalez 06/02/1977 00:00 S 2
3 Blake Collins 23/04/1975 00:00 M 0
4 Alexa Watson 25/08/1977 00:00 S 0
5 Jacquelyn Dominguez 27/09/1977 00:00 M 1
6 Casey Gutierrez 17/12/1977 00:00 M 1
7 Colleen Lu 17/07/1973 00:00 M 2
8 Jeremiah Stewart 26/06/1979 00:00 S 1
9 Leah Li 06/10/1976 00:00 S 0
Id FirstName LastName BirthDate
Marital
Status
Children
1 Larry Gill 13/04/1977 00:00 M 1
2 Geoffrey Gonzalez 06/02/1977 00:00 S 2
3 Blake Collins 23/04/1975 00:00 M 0
4 Alexa Watson 25/08/1977 00:00 S 0
Alloco ancora spazio
su disco perchè finito
5 Jacquelyn Dominguez 27/09/1977 00:00 M 1
6 Casey Gutierrez 17/12/1977 00:00 M 1
7 Colleen Lu 17/07/1973 00:00 M 2
8 Jeremiah Stewart 26/06/1979 00:00 S 1
9 Leah Li 06/10/1976 00:00 S 0
#sqlsatParma

Caratteristiche di un row storage
 SELECT * di una tabella
 Legge tutta la tabella dalla prima all’ultima riga
 SELECT SUM(children) della tabella
 Legge tutta la tabella dalla prima all’ultima riga e poi
si legge solo la colonna children per fare la somma
 Prestazioni pessime per un dato piccolo devo fare
tanto I/0 su disco che poi non serve
#sqlsatParma

Caratteristiche di un row storage
 Il risultato della SELECT SUM(children) non cambia
nemmeno se faccio I/O in memoria e non su disco
 Trasferisco i dati dalla memoria alla cache della CPU
dove si svolge il calcolo
 La cache interna è molto limitata
 Pessimo uso perché carico una grande parte di
memoria per poi usarne un pezzettino
 Ottengo comunque prestazioni peggiori rispetto al
fatto di lavorare su dati più compatti (Problema)
#sqlsatParma

Soluzione con gli indici
 Se devo fare spesso la SUM(children)
 Creo un indice su children
 La query richiede solo il campo children (l’indice
copre la query), leggo solo l’indice e non tutta la
tabella
 L’indice contiene dati più compatti e mi aiuta per I/O
 Gli indici in generale riducono il numero di colonne
di una tabella e ottimizzano l’I/0
Concetto di Column Storage
#sqlsatParma

Caratteristiche di un column storage
 Portiamo il concetto di indice in memoria
 Estremizziamo il concetto di indice
Marital Status
Id Id
FirstName FirstName
LastName
BirthDate BirthDate
Marital Status Children
1 1
Larry Larry
Gill
13/13/04/04/1977 1977 00:00:00 00
M M
1
2 2
Geoffrey Geoffrey
Gonzalez
06/06/02/02/1977 1977 00:00:00 00
S S
2
3 3
Blake Blake
Collins
23/23/04/04/1975 1975 00:00:00 00
M M
0
4 4
Alexa Alexa
Watson
25/25/08/08/1977 1977 00:00:00 00
S S
0
5 5
Jacquelyn Jacquelyn
Dominguez
27/27/09/09/1977 1977 00:00:00 00
M M
1
6 6
Casey Casey
Gutierrez
17/17/12/12/1977 1977 00:00:00 00
M M
1
7 7
Colleen Colleen
Lu
17/17/07/07/1973 1973 00:00:00 00
M M
2
8 8
Jeremiah Jeremiah
Stewart
26/26/06/06/1979 1979 00:00:00 00
S S
1
9 9
Leah Leah
Li
06/06/10/10/1976 1976 00:00:00 00
S S
0
Un file per colonna
#sqlsatParma

 Faccio una SELECT SUM(children) della tabella
 Non devo fare un indice
 La colonna è già l’indice perché contiene solo
children
 Molto veloce
 Faccio SELECT SUM(children) GROUP BY FirstName
 Non è più così bello
 Devo leggere due colonne: Children e FirstName
 Devo poi unire il risultato pagando tempo di CPU
#sqlsatParma

 Rispetto alla row storage
 più velocità se devo leggere una colonna
 più velocità se leggo poche colonne
 più lento se faccio SELECT *
#sqlsatParma

Column vs Row
 Memorizzazione su colonna
 Accesso veloce ad una singola colonna
 Ho la necessità di materializzare le righe
 Spendiamo CPU per ridurre I/0 (le CPU le possono
fare più veloci o metterne tante )
 Memorizzazione per riga
 Accesso veloce alla singola riga
 Non necessita di materializzazione
 Spendiamo l’I/O per ridurre la CPU (i dischi o la
memoria non si possono fare più veloci )
#sqlsatParma

Cambiare il modo di pensare (colonnare)
 Siamo in un mondo in cui lo storage è fatto da una sola
colonna .
 Ci sono cose che si possono fare memorizzando i dati
in colonna che sono più efficienti rispetto ai dati
memorizzati su riga
Sapete come funziona la compressione di SQL Server?
 per riga (non fa grandi cose… pulizie spazi bianchi, ridurre
caratteri unicode, ridurre i decimali …..)
 per pagina (identifica all’interno della pagina parti uguali e
le indicizza per poi comprimere la pagina creando un indice
all’inizio)
#sqlsatParma

Compressione in Vertipaq
 Vertipaq (simile compressione di pagina in SQL Server)
 Identifica parti uguali nell’aria di memoria
 Crea una struttura per rappresentare le parti uguali
e ottiene la struttura compressa della colonna
 Più efficiente di SQL perché si ragiona solo su una
colonna con pochi valori distinti rispetto alla pagina
di SQL in cui ho righe con più colonne e con meno
valori distinti .
Vediamo come Vertipaq esegue la compressione
#sqlsatParma

Run Length Encoding (RLE) - 1 livello
Children
1
1
1
1
1
...
2
2
2
2
2
2
2
2
....
Children Inizio Lunghezza
1 1 200
2 201 400
FirstName
Larry
Larry
Larry
...
Geoffrey
Geoffrey
Geoffrey
...
Alexa
Alexa
Alexa
...
Colleen
Colleen
...
Potrei anche decidere di
togliere la colonna inizio
e tenere solo la fine
FirstName Lunghezza
Larry 400
Geoffrey 400
Alexa 100
Colleen 100
BirthDate
13/04/1977
13/05/1977
13/06/1977
....
15/04/1980
16/04/1947
13/04/1976
...
13/04/1976
13/04/1976
13/04/1976
...
13/04/1990
13/04/1934
...
BirthDate lunghezza
13/04/1977 1
13/05/1977 1
13/06/1977 1
....
15/04/1980 1
16/04/1947 1
13/04/1976 1
...
13/04/1976 1
13/04/1976 1
13/04/1976 1
...
13/04/1990 1
13/04/1934 1
...
Le date cambiano così di frequente che se
provassi a comprimerla avrei su lunghezza
tutti 1 e otterrei una tabella più grande
dell’originale Vertipaq lascia l’originale.
#sqlsatParma

Run Length Encoding (RLE) - 1 livello
 Vertipaq non usa mai più memoria rispetto alla colonna
sorgente…se non riesce a comprimerla la lascia come è
 Vertipaq durante il processing di un tabella
 Divide la tabella in colonne
 Comprime ogni colonna con RLE
 Attenzione!!! L’ordinamento delle colonne deve
essere lo stesso per ogni colonna perchè devo
materializzare i dati delle varie colonne (se ne
occupa vertipaq ) buon ordinamento = buona
compressione
#sqlsatParma

Dictionary encoding - 2 livello
 Più importante di RLE
 Vediamo i passi per creare il Dictionary
1. Vertipaq legge una colonna di tipo stringa
2. Effettua il distinct della colonna
3. Ogni valore stringa è associato ad un numero in un
Dictionary
4. Sostituisco i valori stringa nella colonna con i numeri
del Dictionary
#sqlsatParma

Dictionary encoding - 2 livello
Creo il
dizionario
DISTINCT
Indice Quarter
1 Q1
2 Q2
3 Q3
4 Q4
SOSTITUISCI
Conoscendo i possibili valori della
stringa utilizzo il numero minimo di
bit per rappresentarla. In questo
caso 4 possibili valori bastano 2 bit.
Quarter
Q1
Q4
Q1
...
Q2
Q3
Q1
...
Q3
Q3
Q2
...
Q1
Q1
....
Quarter
1
1
1
...
2
2
2
...
3
3
3
...
4
4
....
RLE
xVelocity storage
Quarter Count Lunghezza
1 1 400
2 400 400
3 800 100
4 900 100
Con il dictionary encoding Vertipaq è data typing
independent. Non ha nessuna importanza il tipo dei campi
che si utilizzano nelle viste per popolare il modello
#sqlsatParma
Versione compressa
Dizionario

Conclusioni su RLE e Dictionary encoding
 Una stringa nella tabella (osceno) dei fatti non ha
più nessun prezzo grazie al dictionary encoding
 DOVETE vivere  pensando che Vertipaq memorizza i
dati in questo modo. E’ fondamentale quando andrete a
costruire un modello con Vertipaq
 Importa solo il numero di valori distinti delle colonne
 Tanti valori distinti occupano più spazio (+ RAM)
ed più lungo fare analisi
 Pochi valori distinti occupano poco spazio (- RAM)
e tutte operazioni ridotte
#sqlsatParma

Conclusioni sulla compressione
 Dictionary Encoding
 Avviene quando è necessario: per una colonna con valori
interi e con valori distinti molto alti conviene memorizzare il
numero perché il dizionario sarebbe troppo grande
 Rende le tabelle data type independent
 RLE Encoding
 Solo se i dati compressi sono più piccoli dell’originale
 Dipende fortemente dall’ordine dei dati
 SSAS sceglie il sorting migliore durante il process (10 s/milione di
righe). Trovare stesso ordinamento per le colonne è difficile.
Thomas Kejser: + 25% compressione con ordinamento sorgente
#sqlsatParma

Conclusioni sulla compressione
 La compressione deriva dal fatto che abbiamo:
 Column Store
 Dictionary Encoding
 RLE Encoding
 Compressione: uso meno RAM e quindi più velocità e il
modello riesce a stare nel server . Scansioni delle
colonne sono più veloci
 Il valore di compressione che ci possiamo aspettare è….
 Non lo sa nessuno ma la risposta commerciale è 10x
anche si può arrivare a 50x o a 2x
#sqlsatParma

Segmentation
 Fino ad ora abbiamo visto come Vertipaq processa e
comprime una colonna
 Cosa succede con la tabella intera?
 In realtà Vertipaq non processa tutta la tabella prima di
fare la compressione perché non avrebbe abbastanza
memoria
 Si usa la tecnica della segmentation
#sqlsatParma

Segmentation
 Ogni tabella è divisa in segmenti (dimensione variabile)
 8 milioni di righe per ogni segmento in SSAS
 1 milione di righe in PowerPivot
 C’è un dizionario globale per la tabella
 Bit-sizing (forma compatta del dizionario) è locale ad
ogni segmento
 Ci sono delle DMV per avere informazione sui segmenti
#sqlsatParma

Segmentation cycle
Legge il segmento
Genera o aggiorna il dizionario
globale
Genera un dizionario locale al
segmento bit-sizing
Comprime tutto e memorizza e
passa al secondo segmento
#sqlsatParma

Importanza della Segmentation
 Viene usata per lavorare su un insieme ridotto di dati per la
compressione ( 1 o 8 millioni di righe)
 Viene usata come base per il parallelismo all’interno delle
query
 Quando Vertipaq risolve una query usa un thread per
ogni segmento della tabella (per fare la scansione)
 Se ho meno di 8 milioni userà un solo thread perché è
antipoduttivo usarne di più
 Se ho 80 milioni di righe userà 10 thread su 10 core
separati (ideale ma impensabile per conflitto sul bus)
#sqlsatParma

Segmentation
 Fasi della segmentazione durante il processing
Legge e crea i
dizionari del segmento
N
Legge e crea i
N + 1
Comprime
segmento N
Comprime
segmento N+1
Crea colonne calcolate,
gerarchie, relazioni e
tutte le strutture dati
Fine lettura dati del
modello
#sqlsatParma

Segmentation: caso speciale del 3 segmento
 Vertipaq cerca di ridurre il numero di segmenti da caricare
 fa un tentativo di leggere i primi due segmenti assieme (come
fosse unico). Se ci sono 12 milioni di righe è inutile leggerli in due
passi e legge direttamente 16 milioni di righe (primo segmento)
altrimenti segmenta normalmente
Legge e crea i
dizionari del
segmento 1 e 2
Legge e crea i
3
Comprime
segmento 1
Comprime
segmento 2
Crea colonne calcolate,
gerarchie, relazioni e
tutte le strutture dati
Comprime
segmento 3
Fine lettura dati del
modello
#sqlsatParma

Configurazione della segmentazione
 La configurazione e a livello di istanza
 DefaultSegmentRowCount (0 = default)
 ProcessingTimeboxSecPerMRow per decidere il tempo entro al
quale deve ordinare
#sqlsatParma

Uso memoria durante il processing
 Ogni tabella è processata sequenzialmente (anche se
partizionata)
 Non ci sono parallelismi sulla partizione come SSAS
 Ogni tabella è divisa in segmenti
 Per ogni segmento
 Caricamento
 Compressione (un thread per colonna: parallelismo)
 Memorizzazione
 Più tabelle possono essere caricate in parallelo
#sqlsatParma

Uso memoria durante memorizzazione
 L’uso della memoria nella memorizzazione dipende da:
 Numero di colonne
 Cardinalità di ogni colonna (valori distinct)
 Tipo di dato (varia il dizionario)
 Numero di righe
 Non ci sono formule per calcolare lo spazio occupato da
una tabella. L’unico modo è creare un prototipo!!!
 Attenzione ad avere un prototipo con dati veri  i dati
nascosti sfalsano la distribuzione dei dati.
#sqlsatParma

Uso memoria durante le query
 La cache richiede memoria
 Le query semplici richiedono un po’ di memoria
 Le query complesse richiedono molta memoria
 Fare spooling per valori temporanei
 Materializzare un dataset ( se faccio una query su più
colonne alla fine devo unire i risultati )
 Problema: in quanto molte volte può capitare che
la versione materializzata sia più grande della
tabella originale
#sqlsatParma

Materialization
 Se vogliamo eseguire su un database colonnare la
seguente query:
SELECT SUM(num730) AS N730,[COD_Ufficio]
FROM [dbo].[Dichiarazioni730]
WHERE [COD_Utente] = 345 AND [Tipo730] = 1
GROUP BY [COD_Ufficio]
Tipo730
1
2
1
1
Cod_Ufficio
4555
2345
6545
444
COD_Utente
345
1678
345
100
 Ci sono diverse tecniche ma agli estremi ci sono:
 Early Materialization
 Late Materializzation
num730
234
100
400
3
#sqlsatParma

Early materialization
Tipo730
1
2
1
1
Cod_Ufficio
4555
2345
4555
444
num730
234
100
400
3
COD_Utente
345
1678
345
100
Ricomponiamo il row store
(Materializzo)
345 1 4555 234
1678 2 2345 100
345 1 4555 400
100 1 444 3
La fregatura è che faccio tanto
lavoro per comprimere in
colonne separate e poi devo
riunire tutto. Uso tanta
memoria se faccio select *
Applico la where
345 1 4555 234
345 1 4555 400
Proiezione per num730 e cod_ufficio
4555 234
4555 400
Sommo
4555 634
#sqlsatParma

Late materializzation
Tipo730
Tipo730
1
2
1
1
Cod_Ufficio
4555
2345
4555
444
num730
234
100
400
3
COD_COD_Utente
345
1678
345
100
Bitmap
1
0
1
0
Applico la clausola
where sulle due
colonne separate
Materializzo
4555 234
4555 400
Sommo
4555 634
Bitmap
1
0
1
1
And
Bitmap
1
0
1
0
Cod_Ufficio
4555
2345
6545
444
num730
234
100
400
3
Applico la bitmap
Cod_Ufficio
4555
4555
num730
234
400
#sqlsatParma

Quando avviene la materializzazione
 La materializzazione avviene per Join complessi
 La materializzazione avviene per iterazioni complesse
 Durante il salvataggio di dati temporanei
Praticamente devo sempre materializzare
#sqlsatParma

Quanto spazio uso per il mio modello?
 Nella directory dei dati, c’è un folder per ogni database
 ..Microsoft SQL ServerMSAS11.MSSQLSERVEROLAPData
 AdventureWorks Tabular Model SQL 2012.......
 Tipo di file ed estensioni
 Dictionary: .DICTIONARY
 Data: .IDF
 Index: .IDF (POS_TO_ID, ID_TO_POS)
 Relationship: GUID + .HDX
 Hierachies: .JDF
#sqlsatParma

 Ci sono anche delle DMV per estrarre le informazioni sullo
stato del database di Tabular (ma sono complicate)
 Ritorna tutte le possibili DMV
 SELECT * FROM $SYSTEM.DISCOVER_SCHEMA_ROWSETS
 Ritorna la memoria utilizzata da tutti gli oggetti
 SELECT * FROM $SYSTEM.DISCOVER_OBJECT_MEMORY_USAGE
 Dettagli delle singole colonne
 SELECT * FROM $SYSTEM.DISCOVER_STORAGE_TABLE_COLUMNS
 Dettagli sui segmenti
 SELECT * FROM
$SYSTEM.DISCOVER_STORAGE_TABLE_COLUMN_SEGMENT
#sqlsatParma

 In alternativa alle DMV usate il PowerPivot di Kasper De
Jonge.
 Si apre un foglio excel in cui da powerpivot interrogo le
DMV su un istanza di analisys services
http://www.powerpivotblog.nl/what-is-using-all-that-memory-on-
my-analysis-server-instance/
#sqlsatParma

Best Practice (ridurre il dictionary)
 Ridurre la lunghezza delle stringhe
 Ridurre il numero di valori distinti
 Dividere DateTime in due colonne (troppi valori distinti)
 Date
 Time
 Deve essere fissata una precisione per i valori floating point
 76.201 diventa 76.2
 Cercate di risolvere tutto a livello di sorgente dati e non in
colonne calcolate (esempio con le viste)
#sqlsatParma

Best Practice (ridurre dimensioni tabelle)
 Attenzione alle Junk Dimensions. Faccio la cross join
della distinct di questi valori junk e li metto nella tabella
junk e poi ci punto dentro con un intero
 Meglio + campi con pochi valori distinti sulla tabella
dei fatti che uno che è il cross join dei valori distinti
 Se poi ho dimensioni con solo Id e descrizione è
meglio memorizzare la descrizione nei fatti
 Descrizione occupa come l’Id nei fatti
 Non pago un join a query time
 Ho un tabella in meno da memorizzare che è inutile
#sqlsatParma

Best Practice (ridurre dimensioni tabelle)
 Evitare risultati parziali in colonne calcolate
 essi tendono ad avere molti valori distinti
 aumentano il numero di colonne
 Rimuovere le colonne non utilizzate
#sqlsatParma

Best Practice dimensioni degeneri
 Problema -> Memorizzare un ID per il DrillThrought nei
report è costoso (sacco di valori distinti)
 Un solo valore per ogni riga
 un grande dizionario per grandi tabelle
 Soluzione -> Splittare in più colonne
 Tabella di 100 milioni di righe. N° di fattura che è
dato da anno + progressivo. Lo divido in due o più
colonne. Le colonne hanno un dizionario più piccolo.
 Se poi lo devo visualizzare sul report rimaterializzare
lo faccio su un sottoinsieme di righe .
#sqlsatParma

Workbook Optimizer
 esamina la composizione del modello di dati
all'interno della vostra cartella di lavoro di
PowerPivot
http://www.microsoft.com/en-us/download/details.aspx?id=38793
 vede se i dati in essa contenuti possono
occupare meno spazio
 vede se possibile fare una migliore
compressione
 Non è il massimo deve migliorare molto
#sqlsatParma

Conclusioni su xVelocity
 Ha degli algoritmi di compressione molto efficienti
 Molto veloce sulle colonne singole
 L’accesso a più colonne richiede la materializzazione
 Metodo di memorizzazione diverso dai classici
database
 Richiede un cambiamento di mentalità
 Tentate di pensare a colonne singole
 Tutte queste caratteristiche si riflettono in DAX.
#sqlsatParma

DEMO
 Testiamo tutto quello fino a qui imparato su un
caso reale di foglio excel bello grande.
#sqlsatParma

THANKS!
#sqlsatParma
#sqlsat355
#sqlsatParma

xVelocity in Deep

Recommended

Recommended

More Related Content

Similar to xVelocity in Deep

Similar to xVelocity in Deep (8)

More from Marco Pozzan

More from Marco Pozzan (20)

xVelocity in Deep