Qual è l'anatomia di un indice columnstore?

Una delle nuove funzionalità di SQL Server 2012 con nome in codice Denaliè l' indice Columnstore.

Conosco un sacco di vecchi indici di archivio righe regolari, come la struttura b-tree, le differenze di archiviazione tra il livello foglia e le pagine b-tree, gli effetti dei campi inclusi, l'ottimizzazione per usarli, l'ordine delle chiavi, ecc.

Sto riscontrando difficoltà a ottenere informazioni utili sugli interni di un indice columnstore.

• Com'è strutturato?
• C'è un b-tree? Qualche altra struttura in atto?
• Come sono organizzati i dati?
• Quali tipi di operatori specifici sono più adatti per usarlo?
• Altri anti-pattern da evitare quando li si utilizza?

Molto di ciò che posso scoprire su di essi è sostanzialmente l'esatto opposto di un indice "normale", ovvero nessun ordine di chiavi, nessun campo incluso, SOLO non cluster.

Eventuali approfondimenti sono apprezzati.

Columnstore Structure

I dati del columnstore vengono archiviati fisicamente in uno o più segmenti (unità di allocazione LOB regolari) per colonna e possono anche essere partizionati nel solito modo. Ogni segmento contiene circa un milione di righe di valori altamente compressi o riferimenti di valore (sono disponibili diverse tecniche di compressione). Un riferimento valore si collega a una voce in uno di un massimo di due dizionari hash .

I dizionari sono bloccati in memoria durante l'esecuzione della query, con gli ID dei valori dei dati del segmento visualizzati nel dizionario ogni volta che l'esecuzione richiede il valore dei dati effettivo (questa ricerca viene rinviata il più a lungo possibile per motivi di prestazioni).

I segmenti hanno anche un record di intestazione contenente metadati come i valori minimo e massimo memorizzati nel segmento. Le informazioni dall'intestazione possono spesso essere utilizzate per eliminare partizioni complete dall'elaborazione al momento dell'esecuzione. Le informazioni sui record di intestazione vengono archiviate nella consueta struttura radice dei dati LOB, quindi l'eliminazione di un segmento significa che il motore di archiviazione può saltare la lettura completa delle pagine dei dati LOB dalla memoria fisica. Massimizzare il potenziale di eliminazione può richiedere un'attenta progettazione , inclusa una dipendenza dall'ordine dell'indice cluster al momento della creazione dell'indice Columnstore.

Operatori specifici del piano

SQL Server 2012 introduce una nuova modalità di esecuzione denominata Modalità batch. In questa modalità, i pacchetti di circa 1000 righe vengono passati tra gli operatori, migliorando in modo significativo l'efficienza di utilizzo del processore. All'interno di ciascun pacchetto, i dati colonnari sono rappresentati come un vettore. Non tutti gli operatori del piano supportano il funzionamento in modalità batch, ma esempi di quelli che includono Scansione indice Columnstore, Join interno hash, Build tabella batch hash, Filtro bitmap, Aggregato hash (non aggregati scalari ), Filtro e Scalare calcolo (per proiezione ed espressione valutazione). I piani di esecuzione delle query sono stati migliorati per mostrare la modalità di esecuzione stimata ed effettiva.

Anti-pattern

Esistono numerose restrizioni nella prima versione, inclusi i vincoli sui tipi di dati consentiti . Sono supportati i tipi più comuni; tipi di dati non supportati includono DECIMALcon una maggiore precisione di 18 cifre, (N)VARCHAR(MAX), UNIQUEIDENTIFIER, tipi CLR, e (VAR)BINARY.

Uso di tipi di stringa , OUTER JOIN, IN,EXISTS , NOT IN, OR, UNION ALLpuò causare prestazioni significativamente ridotto (Row esecuzione Mode), salvo soluzioni sono impiegati che tipicamente coinvolgono insoliti riscrive sintassi come indicato negli articoli collegati in questa sezione.

Maggiori informazioni

Remus Rusanu ha scritto qui un blog con un'ottima panoramica .