Progettazione di tabelle di grandi dimensioni SQL

Ho una domanda generale sulla progettazione delle tabelle di SQL Server 2008. Al momento disponiamo di un tavolo che supera i 600 GB e cresce a circa 3 GB al giorno. Questa tabella ha le indecie appropriate ma sta diventando un grosso problema durante l'esecuzione di query e solo per le sue dimensioni. La domanda è se dovrei dividere la tabella in più tabelle per anno e mese (questo si adatterebbe al modo in cui altri dipartimenti dividono i loro grandi set di dati) o dovremmo sfruttare il partizionamento incorporato in SQL Server. Sembra che l'utilizzo del partizionamento richiederebbe meno modifiche al codice. Da quello che ho letto durante il partizionamento è ancora solo una query di una tabella e il server gestisce come ottenere i dati. Se seguissimo il percorso di più tabelle, dovremmo gestire il pull dei dati da più tabelle.

"Questa tabella ha le indecie appropriate ma sta diventando un grosso problema durante l'esecuzione di query"

Il partizionamento da solo non aiuta le prestazioni delle query a meno che SQL Server non sia in grado di eliminare le partizioni durante l'esecuzione di una query. La tua clausola WHERE deve allinearsi con il modo in cui esegui la partizione. Abbiamo solo un campo da usare come campo di partizionamento, quindi se quel campo non è incluso nella tua clausola WHERE, è comunque probabile che scansionerai l'intera tabella nonostante abbia partizioni.

"e solo per le sue dimensioni."

Il partizionamento può facilitare alcune operazioni di manutenzione, ma ci sono ancora cose che non possiamo fare partizione per partizione. Se la manutenzione dell'indice e gli aggiornamenti delle statistiche causano problemi, è meglio suddividere il progetto in una tabella di archivio e una tabella aggiornata in tempo reale. Quando è necessario spostare periodicamente i dati dalla tabella live alla tabella di archivio, farlo, ricostruire gli indici con il fattore di riempimento del 100%, aggiornare le statistiche con la scansione completa e quindi impostare il suo filegroup in sola lettura. Il partizionamento può aiutare con i carichi della tabella di archivio, ma il partizionamento della tabella live potrebbe non esserlo. (Sto lanciando qui diversi concetti avanzati come se fosse rapido e semplice, ma sto solo disegnando alcuni sfondi qui.)

"Sembra che l'utilizzo del partizionamento richiederebbe meno modifiche al codice."

Sorta in un certo senso - sembra così a prima vista, ma più ci entri, hai opzioni come viste partizionate. Puoi rinominare la tabella esistente, metterne una vista al suo posto e quindi puoi apportare le tue modifiche alle tabelle sottostanti (e aggiungere più tabelle) senza cambiare l'app.

Ho scritto di più sulle insidie ​​del partizionamento qui:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

Il partizionamento in isolamento può essere sufficiente ma è possibile ottenere risultati migliori combinando con viste partizionate e più tabelle. Dipende molto dal modello di query e crescita.

L'attuale limitazione con il partizionamento è che le statistiche delle colonne sono mantenute solo a una tabella, piuttosto che a livello di partizione. Se si dispone di un modello di query che trarrebbe vantaggio da statistiche più accurate, la combinazione del partizionamento delle tabelle con le viste partizionate potrebbe comportare vantaggi significativi in ​​termini di prestazioni.

Laddove la natura dei dati varia di mese in mese, di anno in anno, possono essere utili anche le viste partizionate. Immagina un rivenditore che ha cambiato continuamente le sue linee di prodotto, in modo che vi sia poca coerenza nelle gamme Product.ProductId in uso da un anno all'altro. Con una singola tabella order / orderdetail e quindi un singolo istogramma delle statistiche, le statistiche offriranno poco all'ottimizzatore delle query. Una tabella all'anno (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011) partizionata per mese e combinata con viste partizionate (Order, OrderLine) fornirà all'ottimizzatore statistiche più dettagliate e potenzialmente utili.

È possibile introdurre il partizionamento delle tabelle con uno sforzo relativamente ridotto, quindi iniziare da lì, misurare l'impatto e in seguito valutare se le viste partizionate valgono lo sforzo aggiuntivo.

Kimberly Tripp ha pubblicato molte guide e white paper sul partizionamento che sono generalmente considerati letture obbligatorie sull'argomento. Kendra Little ha anche del buon materiale e un utile elenco di riferimento di altri articoli

Le prestazioni sono in genere la ragione numero 1 per cui le persone cercano il partizionamento. Personalmente, considero i miglioramenti nei tempi di recupero come un vantaggio uguale o maggiore con un VLDB. Prenditi un po 'di tempo per capire la disponibilità parziale e il ripristino frammentario prima di iniziare in quanto ciò potrebbe influenzare l'approccio adottato.

Se hai il processo non ideale ma non insolito di invio di backup attraverso la rete, potresti vedere un tempo di ripristino di 3 ore per i tuoi attuali 600 GB. In un anno in cui hai violato 1,5 TB, hai un problema.

Come hai detto, hai due opzioni qui:

1. Utilizza più tabelle
2. Utilizza il partizionamento

Con 1, puoi creare una VISTA che unisce tutte queste tabelle insieme e aggiornarla per includere le tabelle appena create. Ritengo che questo sia davvero un modo per emulare il partizionamento. I vantaggi di questo metodo includono la non richiesta Enterprise Edition di SQL Server.

Con 2, puoi allineare i tuoi indici alle tue partizioni e allineare le tue partizioni a diversi archivi. Dopo aver impostato la funzione di partizione e lo schema di partizione, questo viene fatto per te quando dividi o unisci le partizioni. I vantaggi di questo metodo includono la non necessità di spostare manualmente i record in una nuova tabella. Poiché la funzione di partizione e lo schema di partizione gestiscono questo per te. Inoltre, come hai detto, non è necessario modificare il codice per accedere ai dati.

Se hai Enterprise Edition, darei sicuramente uno sguardo al partizionamento. Nonostante quanto sia complesso, non è poi così male. In caso contrario, il partizionamento non è nemmeno un'opzione per te.

Creazione di tabelle partizionate

Modifica delle tabelle partizionate

Progettazione di partizioni per gestire sottoinsiemi di dati

Spero che sia di aiuto,

opaco

Dalla tua domanda, sembra che tu stia archiviando dati storici (registri) e la tua limitazione sembra provenire dalla velocità della query, non da problemi di spazio di archiviazione. Per me la partizione non aiuterà.

Quando dici di avere indici adeguati, include un indice nel campo della data? Ho ottenuto buoni risultati usando l'indice su trunc (data e ora, giorno) con Postgres. È quindi necessario assicurarsi che tutte le query vengano selezionate il giorno prima di qualsiasi altra manipolazione. Fai attenzione, un timestamp con campo fuso orario non è indicizzabile (perché "si sposta" in base al fuso orario), quindi è necessario un timestamp "fisso" per essere indicizzato.