Suddivisione / unione SQL delle partizioni di tabella: qual è l'approccio migliore da implementare?

Question

Microsoft nel suo MSDN entry modifica delle partizioni SQL 2005, elencato alcuni possibili approcci:

• Crea una nuova tabella partizionata con la funzione di partizione desiderata, quindi inserisci i dati dalla vecchia tabella nella nuova tabella usando un'istruzione INSERT INTO ... SELECT FROM.
• Crea un indice cluster partizionato su un heap
• Rilascia e ricostruisci un indice partizionato esistente utilizzando l'istruzione CREATE INDEX Transact-SQL con la clausola DROP EXISTING = ON.
• Esegue una sequenza di istruzioni ALTER PARTITION FUNCTION.

Qualche idea su quale sarà il modo più efficiente per un DB su larga scala (milioni di record) con partizioni basate sulle date dei record (qualcosa come le partizioni mensili), dove i dati si diffondono nell'arco di 1-2 anni?

Inoltre, se accedo principalmente (per leggere) informazioni recenti, avrà senso mantenere una partizione per gli ultimi X giorni e tutto il resto dei dati sarà un'altra partizione? Oppure è meglio partizionare anche il resto dei dati (per qualsiasi accesso casuale basato sull'intervallo di date)?

Answer 1

Consiglierei il primo approccio: creare una nuova tabella partizionata e inserirla in essa, perché ti dà il lusso di confrontare le tue vecchie e nuove tabelle. Puoi testare i piani di query su entrambi gli stili di tabelle e vedere se le tue query sono effettivamente più veloci prima di passare al nuovo design della tabella. Potresti scoprire che non ci sono miglioramenti o potresti voler provare diverse funzioni / schemi di partizionamento prima di accontentarti del risultato finale. Potresti voler partizionare su qualcosa di diverso dall'intervallo di date - la data non è sempre efficace.

Ho fatto il partizionamento con tabelle di 300-500m con dati distribuiti in 6-7 anni e quell'approccio di inserimento delle tabelle è stato quello che ho trovato più utile.

Hai chiesto informazioni su come partizionare: la risposta migliore è provare a progettare le tue partizioni in modo che le tue query colpiscano una singola partizione. Se tendi a concentrare le query sui dati recenti, E se filtri su quel campo data nelle clausole where, allora sì, hai una partizione separata per gli X giorni più recenti.

Tieni presente che devi specificare il campo partizionato nella tua clausola where. Se non stai specificando quel campo, probabilmente la query colpirà tutte le partizioni per ottenere i dati e a quel punto non avrai alcun miglioramento delle prestazioni.

Spero che ti aiuti! Ho fatto un sacco di partizionamento e se vuoi pubblicare alcuni esempi di strutture di tabelle e amp; domande, che ti aiuteranno a ottenere una risposta migliore per il tuo ambiente.