Database Schema Design - Suggerimenti per migliorare la capacità di archiviazione?

Question

Sto progettando una tabella nel database che memorizzerà le voci di registro dell'applicazione. Ci sono alcune cose che mi fanno pensare a questo design più del solito.

• Tuttavia, queste voci di registro verranno utilizzate in fase di esecuzione dal sistema per prendere decisioni, pertanto devono essere relativamente veloci per accedervi.
• Hanno anche il problema è che ce ne saranno molti (12,5 milioni aggiunti al mese è la mia stima).
• Non ho bisogno di più degli ultimi 30-45 giorni al massimo per l'elaborazione delle decisioni.
• Devo tenerli tutti per molto più di 45 giorni per il supporto & amp; questioni legali, probabilmente almeno 2 anni.
• Il design della tabella è abbastanza semplice, tutti i tipi semplici (senza BLOB o altro), dove possibile utilizzerà il motore di database per inserire i dati predefiniti, al massimo una chiave esterna.
• Se fa differenza, il database sarà Microsoft SQL Server 2005.

Quello che stavo pensando è averli scritti su una tabella / database live e quindi usando una soluzione ETL sposta " vecchio " voci in una tabella / database di archivio - che è grande e su hardware più lento.

La mia domanda è: conosci suggerimenti, trucchi o suggerimenti per la progettazione di database / tabelle per assicurarti che funzioni nel miglior modo possibile? Inoltre, se pensi che sia una cattiva idea, fammi sapere, e quale pensi che sarebbe un'idea migliore.

Answer 1

Alcuni database offrono " partizioni " (Oracle, per esempio). Una partizione è come una vista che raccoglie diverse tabelle con una definizione identica in una. Puoi definire i criteri che ordinano i nuovi dati nelle diverse tabelle (ad esempio, il mese o la settimana dell'anno% 6).

Dal punto di vista dell'utente, questa è solo una tabella. Dal database PoV, sono diverse tabelle indipendenti, quindi puoi eseguire comandi di tabella completa (come troncare, rilasciare, eliminare dalla tabella (senza una condizione), caricare / scaricare, ecc.) Su di essi in modo efficiente.

Se non puoi avere una partizione, ottieni un effetto simile con le viste. In questo caso, puoi raccogliere più tabelle in una singola vista e ridefinire questa vista, diciamo, una volta al mese a & Quot; gratis & Quot; una tabella con vecchi dati dal resto. Ora puoi archiviare in modo efficiente questa tabella, cancellarla e ricollegarla alla vista quando il grande lavoro è stato svolto. Ciò dovrebbe aiutare notevolmente a migliorare le prestazioni.

[EDIT] SQL Server 2005 in poi (Enterprise Edition) supporta le partizioni. Grazie a Mitch Wheat

Answer 2

Le tabelle di grandi dimensioni rallentano rapidamente ed è un grande sovraccarico di prestazioni utilizzare ETL per estrarre i dati in base alla data, da una tabella di grandi dimensioni e quindi eliminare le vecchie righe. La risposta a questa è usare più tabelle - probabilmente 1 tabella / mese in base alle tue cifre. Ovviamente avrai bisogno di un po 'di logica per generare i nomi delle tabelle nelle tue query.

Sono d'accordo con l'utilizzo di Trigger per popolare la tabella 'CurrentMonthAudit', alla fine del mese, puoi quindi rinominare quella tabella in MonthAuditYYYYMM. Spostare le vecchie tabelle dal server principale utilizzando ETL sarà quindi facile e ognuna delle tue tabelle sarà gestibile. Fidati di me, è molto meglio che provare a gestire una singola tabella con circa 250 milioni di righe.

Answer 3

La tua prima buona decisione è mantenere tutto il più semplice possibile.

Ho avuto buona fortuna con il tuo modello di semplice file di registro delle transazioni di sola scrittura in cui i record sono appena stabiliti in ordine cronologico. Quindi hai diverse opzioni per cambiare i dati obsoleti. Anche avere tabelle mensili diverse è gestibile in termini di query purché si tenga presente la semplicità. Se si dispone di qualsiasi tipo di replica in funzione, le tabelle replicate possono essere implementate e utilizzate come archivio. Quindi inizia con un nuovo tavolo vuoto il primo di ogni mese.

Normalmente rabbrividisco per le conseguenze del design relazionale di fare qualcosa del genere, ma ho scoperto che le tabelle cronologiche di sola scrittura sono un'eccezione ai soliti schemi di progettazione, per i motivi che trattate qui.

Ma stai lontano dai grilletti. Per quanto possibile. La soluzione più semplice è una tabella principale del tipo di cui stai parlando qui, con un semplice meccanismo di replica affidabile e comprovato.

(A proposito: i tavoli di grandi dimensioni non rallentano rapidamente se sono ben progettati - rallentano lentamente.)

Answer 4

Se non è necessario cercare i record di registro recenti, esiste un'altra opzione: non utilizzare affatto un database. Invece, scrivi le informazioni del registro in un file e ruota il nome del file ogni notte. Dopo aver scritto un file, è possibile avviare un processo in background per importare i dati direttamente nel database di archivio.

I database non sono sempre l'opzione migliore, specialmente per i file di registro :)