Una tabella con molte colonne mantiene ancora un anti-pattern quando si utilizza l'indice di archiviazione delle colonne in cluster in SQL Server 2014?

Leggendo sull'indice di archivio di colonne in cluster in SQL Server 2014, mi chiedo se avere una tabella con un numero enorme di colonne sia ancora un anti-pattern. Attualmente per alleviare il problema di avere una singola tabella con un sacco di colonne, sto usando vertical partitioning ma avendo a disposizione un indice di archivio di colonne cluster questo non dovrebbe essere necessario. È corretto o mi manca qualcosa?Una tabella con molte colonne mantiene ancora un anti-pattern quando si utilizza l'indice di archiviazione delle colonne in cluster in SQL Server 2014?

Esempio: consente di dare ad esempio il registro dei contatori delle prestazioni, i dati grezzi possono avere la seguente struttura:

 
╔══════════════════╦═══════╦═══════╦═════╦═════╦═════╦══════════╗ 
║  Time  ║ Perf1 ║ Perf2 ║ ... ║ ... ║ ... ║ Perf1000 ║ 
╠══════════════════╬═══════╬═══════╬═════╬═════╬═════╬══════════╣ 
║ 2013-11-05 00:01 ║  1 ║  5 ║  ║  ║  ║  9 ║ 
║ 2013-11-05 00:01 ║  2 ║  9 ║  ║  ║  ║  9 ║ 
║ 2013-11-05 00:01 ║  3 ║  2 ║  ║  ║  ║  9 ║ 
║ 2013-11-05 00:01 ║  4 ║  3 ║  ║  ║  ║  9 ║ 
╚══════════════════╩═══════╩═══════╩═════╩═════╩═════╩══════════╝

Avere un tavolo con 1000 colonne è male, perché una fila sarà più probabilmente più di una pagina, perché di solito è improbabile che uno sia interessato a tutte le misure ma la query incorrerà sempre nel costo di I/O, ecc. ecc. Per risolvere questo partizionamento verticale di solito aiuta, per esempio si potrebbe contatori delle prestazioni delle partizioni in diverse tabelle per categoria (CPU, RAM, ecc.).

Viceversa avendo tale tabella come indice negozio colonna cluster non dovrebbe essere un problema in quanto i dati vengono memorizzati colonna-saggio e IO coinvolti per ogni query saranno circa solo le colonne richieste, nient'altro indipendentemente dal numero totale di colonne nella tabella.

fonte

2013-11-04 marcob

Sì, sembra ragionevole in base a [questo] (http://msdn.microsoft.com/en-us/library/gg492088 (v = sql.120) .aspx), ma è probabilmente una di quelle domande che si può rispondere solo con un esperimento diretto. Sono più preoccupato del fatto che sembriamo perdere tutto ciò che assomiglia a un PK oa un indice univoco poiché l'indice columnstore in cluster '[i] è l'unico indice sulla tabella. Non può essere combinato con altri indici – criticalfix

Uno (forse minore) svantaggio è che la costruzione potrebbe richiedere più memoria [Quanta memoria è necessaria per creare un indice columnstore?] (Http://social.technet.microsoft.com/ wiki/contents/articles/3540.sql-server-columnstore-index-faq.aspx # CreateColumnstore) –

È sicuramente meno "cattivo" di un negozio orizzontale, ma 1000 sta spingendo un po 'troppo il limite. Il nostro data warehouse di solito ha tabelle con 100 - 200 colonne e sono abbastanza veloci con l'indice del negozio di colonne. Supponendo che tu abbia un indice perfetto per l'archivio delle colonne, ogni query dovrebbe esaminare solo l'indice verticale specifico e quindi molto efficiente. Ma se gli indici di archiviazione delle colonne non sono ottimali per la query, SQL Server deve fare un salto tra gli indici e quelli non sono buoni.

Non esiste una regola generale su questo. Dovrai fare un benchmark per rispondere a questa domanda nel tuo ambiente specifico.

fonte

2013-11-04 19:31:01

perché 1000 è troppo rispetto al 100-200? considerando la struttura di archiviazione non dovrebbe importare. In realtà non ho 1000 colonne, la mia domanda riguardava in generale la tecnologia, voglio solo capire se mi manca qualcosa. – marcob

Prima di tutto, la dimensione massima della riga è limitata a 8096 byte per riga per i tipi di dati a lunghezza fissa. Se i tuoi dati sono di lunghezza variabile (varchar, blob, ecc.) Possono essere suddivisi in righe separate (vedi [questo argomento] (http://technet.microsoft.com/en-us/library/ms143432.aspx) su MSDN). Secondo Se si dispone di qualsiasi tipo di indice basato su righe, diventa estremamente dispendioso in termini di tempo per mantenere. Pensa di trovare un bisogno in un pagliaio. In terzo luogo, è necessario riflettere molto attentamente sugli indici del proprio archivio di colonne. Se si interrogano due colonne in due diversi indici, le prestazioni saranno lente. –

Non conosco la configurazione esatta dell'ambiente quindi non posso offrire alcuna specifica qui. Perché non si confronta la tabella 1000 colonne vs 2 tabelle di 500 ciascuno? –

-1

Il tipo di query nel carico di lavoro e il tipo di dati nella tabella sono fattori che determinano se rowstore o columnstore offrono migliori vantaggi. Se le query cercano una piccola serie di righe, rowstore può fornire prestazioni migliori. Se le query sono tipo di query di data warehouse, ad esempio: scansione di grandi quantità di dati, columnstore offre prestazioni migliori. Inoltre, potresti creare un indice columnstore non cluster sul tuo tavolo. Query Optimizer deciderà quando utilizzare l'indice columnstore e quando utilizzare altri indici.

Si consiglia di leggere l'articolo di TechNet contenente l'elenco di domande frequenti per l'indice columnstore here.

fonte

2014-05-21 23:23:09

Una tabella con molte colonne mantiene ancora un anti-pattern quando si utilizza l'indice di archiviazione delle colonne in cluster in SQL Server 2014?

risposta

Problemi correlati