Partizionamento di SQL Server: cosa utilizzare per la chiave di partizione?

Non ho mai lavorato con il partizionamento di SQL Server, ma attualmente mi trovo ad affrontare la progettazione di un database per il quale probabilmente i volumi lo giustificano. Il sistema è per coupon. I coupon devono essere emessi periodicamente, di solito ogni sei settimane anche se ci sarà anche un'emissione ad hoc, ad esempio per un evento speciale. Ci sono 15 milioni di clienti e per ogni evento di emissione, ogni cliente riceverà 6 diversi tipi di coupon, per un totale di 90 milioni di istanze di coupon. Dobbiamo tenere traccia dei dati di riscatto dell'istanza del coupon e mantenerli per 6 mesi, sebbene in genere un coupon sia valido solo per sei settimane. Qualsiasi richiesta di rimborso per un coupon non valido non raggiungerà il database poiché sarà convalidato dal POS fino al.

Per un periodo di sei mesi dovremo archiviare fino a 360 milioni di righe nella tabella Istanza coupon e fino a 72 milioni (presupponendo un tasso di rimborso massimo del 20%) nella tabella di rimborso. Ho la sensazione che questi numeri siano troppo grandi per una singola partizione?

La mia domanda è: cosa usare come chiave di partizione? Un candidato ovvio sarebbe per evento di emissione, dando circa 6 partizioni. Ma poi penso che forse anche questo darebbe una dimensione della partizione troppo grande per consentire prestazioni ottimali? Sarebbe possibile partizionare con due chiavi, ad es. Per evento di emissione + ultima cifra dell'ID cliente? Quindi la logica sarebbe:

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

Inoltre, non sono sicuro delle specifiche del server di database di cui avremo bisogno. Saranno sufficienti 16 GB e 8 PC? Il db deve essere in grado di restituire un risultato dalla tabella dell'istanza del coupon, digitata su un valore di codice a barre numerico in meno di mezzo secondo. La richiesta di transazione prevista per convalidare (selezionare) e riscattare (inserire) dovrebbe raggiungere il picco a circa 3.500 al minuto.

Il server db a 64 bit di SQL Server 2008r2 verrà eseguito il provisioning come VM da un host molto potente con accesso a una SAN ad alte prestazioni e di grande capacità.

Sarei molto grato per qualsiasi consiglio da parte di coloro che hanno implementato una soluzione SQL Server per gestire volumi simili.

Saluti

Rapinare.

Le domande sulle specifiche del server devono essere indirizzate a Serverfault o DBA.SE.

Per la domanda sul partizionamento, non penso che sia necessario partizionare per questo.

Le file a 360m sono molte ma non troppo ingombranti.

Non NON in nessun caso cercare di partizione di base l'ultima cifra di un campo. Non sono sicuro che funzionerebbe, ma non è SARGable che non sarebbe sostenibile.

Se devi solo cercare una singola riga in base a un tasto numerico, probabilmente il partizionamento non sarà di aiuto.

Se decidi di seguire il percorso della partizione, tieni presente che per essere efficace tutte le tue query devono includere le chiavi della partizione in modo che il motore sappia quale partizione controllare. Altrimenti li controllerà tutti e in realtà danneggierai le prestazioni.

È possibile partizionare su più chiavi se si utilizza una colonna calcolata persistente; come altri hanno detto, tuttavia, il partizionamento non funziona per ogni situazione. Non sono sicuro di aver capito abbastanza il tuo scenario per darti consigli specifici, ma ecco alcune linee guida generali:

• Il partizionamento è utile nella lettura dei dati quando la chiave di partizionamento fa parte dell'istruzione SQL, che consente all'ottimizzatore di invocare l'esclusione delle partizioni. Devi essere sicuro che la chiave scelta sia utile per la maggior parte delle query.

• Uno dei vantaggi di una buona strategia di partizionamento è l'invecchiamento dei dati; ad esempio, se la chiave di partizione è basata sulla data (ad esempio, il giorno dell'anno) e si desidera rimuovere tutti i dati più vecchi di una determinata data, è molto facile COMMUTARE quelle partizioni su una tabella vuota e troncarle.

Devi davvero definire le tue esigenze in modo un po 'più chiaro. Dici che avrai circa 360 milioni di file in 6 mesi. Che ne dici di 2 anni? Crescerai ancora solo al ritmo che stai attualmente crescendo. O c'è la possibilità che tu possa sperimentare una crescita esponenziale. Vuoi conservare i dati in questa tabella per sempre; o vorresti archiviare i dati su base regolare.

Il partizionamento può essere utilizzato per l'archiviazione dei dati. Vedi lo scenario della finestra scorrevole. Vedi questo white paper e questo .

Il partizionamento può anche essere usato per gestire la frammentazione dell'indice. È possibile ricostruire / riorganizzare partizioni particolari.

È inoltre necessario considerare le viste partizionate anziché le tabelle partizionate. Le viste partizionate non richiedono la licenza di SQL Server Enterprise. Le viste partizionate consentono inoltre di eseguire ricostruzioni di indici online su una particolare "partizione".

Il partizionamento può essere preso in considerazione anche durante la pianificazione del ripristino di emergenza. Può essere utilizzato per il recupero parziale del database. Ad esempio: puoi avere le tue vecchie partizioni in un filegroup diverso rispetto alle partizioni principali / correnti. E poi quando si esegue il ripristino, si ripristina il filegroup primario, quindi il filegroup su cui risiedono le partizioni correnti e infine è possibile ripristinare i filegroup su cui risiedono le partizioni precedenti. Ciò può ridurre il tempo di inattività dell'applicazione.

Guarda questo fantastico video di Kimberly Tripp sul partizionamento .

A meno che non si esegua il partizionamento a causa dell'archiviazione di vecchi dati, lo si sta facendo per la ragione sbagliata e non si dovrebbe farlo.