I.E. se abbiamo un tavolo con 4 milioni di righe.Qual è una buona dimensione (numero di righe) per partizionare una tabella per trarne un vantaggio reale?
Quale ha un campo STATUS che può assumere il seguente valore: TO_WORK, BLOCKED o WORKED_CORRECTLY.
Vuoi partizionare su un campo che cambierà solo una volta (la maggior parte delle volte da to_work a working_correctly)? Quante partizioni creeresti?
Il numero di righe in una tabella non è generalmente una grande metrica da utilizzare per determinare se e come partizionare la tabella.
Che problema stai cercando di risolvere? Stai cercando di migliorare le prestazioni della query? Prestazioni dei carichi di dati? Prestazioni di eliminazione dei dati?
Supponendo che si stia tentando di migliorare le prestazioni della query? Tutte le tue query hanno predicati sulla colonna STATUS? Stanno facendo ricerche su righe singole? O vuoi che le tue query eseguano la scansione di un'intera partizione?
Il numero assoluto di righe in una partizione non è la metrica più utile. Ciò che realmente si desidera è una colonna stabile al crescere della tabella e che offra i potenziali benefici del partizionamento. Questi sono: disponibilità, gestione del tablespace e prestazioni.
Ad esempio, la colonna di esempio ha tre valori. Ciò significa che puoi avere tre partizioni, il che significa che puoi avere tre spazi tabella. Quindi, se un tablespace diventa corrotto, perdi un terzo dei tuoi dati. Il partizionamento ha reso il tuo tavolo più disponibile? Non proprio.
L'aggiunta o la rimozione di una partizione semplifica la gestione di grandi volumi di dati. Ma potresti mai perdere tutte le righe con lo stato WORKED_CORRECTLY? Altamente improbabile. Il partizionamento ha reso la tua tabella più gestibile? Non proprio.
I vantaggi delle prestazioni del partizionamento derivano dall'eliminazione delle query, in cui l'ottimizzatore può scartare immediatamente i blocchi della tabella. Ora ogni partizione ha 1,3 milioni di righe. Pertanto, anche se esegui una query su STATUS='WORKED_CORRECTLY', hai ancora un numero enorme di record da analizzare. E le probabilità sono, qualsiasi query che non coinvolge STATUS avrà un rendimento peggiore rispetto a quella della tabella non partizionata. Il partizionamento ha reso il tuo tavolo più performante? Probabilmente no.
Finora, ho assunto che le partizioni siano equamente distribuite. Ma la tua domanda finale indica che non è questo il caso. La maggior parte delle righe, se non tutte le righe, finisce nello WORKED_CORRECTLY. In questo modo la partizione diventerà enorme rispetto alle altre e le possibilità di trarre vantaggio dal partizionamento diventeranno ancora più remote.
Infine, lo schema proposto non è elastico. Come il volume corrente ogni partizione avrebbe 1,3 milioni di righe. Quando il tuo tavolo raggiunge un totale di quaranta milioni di file, ciascuna partizione contiene 13,3 milioni di righe. Questo non va bene.
Quindi, cosa rende un buon candidato per una chiave di partizione? Uno che produce molte partizioni, una in cui le partizioni hanno dimensioni approssimativamente uguali, una in cui il valore della chiave è improbabile che cambi e una in cui il valore ha un significato nel ciclo di vita dell'oggetto sottostante, e infine una che è utile nella maggior parte delle query eseguite contro la tabella.
Ecco perché qualcosa come DATE_CREATED è una scelta molto popolare per il partizionamento delle tabelle dei fatti nei data warehouse.Genera un numero ragionevole di partizioni su un intervallo di granularità (giorno, mese o anno sono le solite scelte). Otteniamo approssimativamente lo stesso numero di record creati in un dato intervallo di tempo. Il caricamento dei dati e l'archiviazione dei dati vengono di solito effettuati in base all'età (cioè la data di creazione). Le query BI includono quasi invariabilmente la dimensione TIME.
Sì, mi piacerebbe migliorare le prestazioni delle query. Il tavolo ha circa 5.000 inserti ogni giorno. Sono solo interessato a non deteriorare queste prestazioni, migliorando al contempo l'enorme errore di estrazione (questo tipo di query è correlato al campo STATUS e TYPE). Viene letto più volte al giorno cercando sempre per stato (ogni record con un determinato stato deve essere elaborato e quindi lo stato viene aggiornato. Il 99% delle volte va allo stato finale.) Le altre volte, c'era un errore, e dobbiamo capire come risolverlo). Mi piacerebbe migliorare le prestazioni nella massiccia ricerca di file. – Revious