Qual è la migliore strategia per la conservazione di set di dati di grandi dimensioni?

Question

Sto conducendo un progetto in cui registreremo i dati metrici.Vorrei conservare i dati per anni.Tuttavia, vorrei anche evitare che la tabella primaria si riempia di dati che, sebbene necessari per i trend a lungo termine, non sono necessari per i report a breve termine.

Qual è la strategia migliore per gestire questa situazione?Archiviare semplicemente i vecchi dati in un'altra tabella?Oppure "arrotolarlo" tramite il consolidamento dei dati stessi (e quindi memorizzarli in una tabella diversa)?O qualcosa di completamente diverso?

Informazioni addizionali:stiamo utilizzando SQL Server 2005.

Answer 1

Usiamo entrambi i metodi nel mio lavoro, ma in modo leggermente diverso, manteniamo tutti i dati di vendita nella tabella primaria per 30 giorni, poi di notte (parte dei lavori notturni) le vendite giornaliere vengono raggruppate in riepiloghi (n quantità di x prodotto venduto oggi ect) in una tabella separata per motivi di reporting, e le vendite superiori a 30 giorni vengono archiviate in un database diverso, poi una volta all'anno (andiamo sugli anni fiscali) viene avviato un nuovo database di archivio.non proprio perfetto ma..

in questo modo otteniamo rapidamente i dati di riepilogo, teniamo a portata di mano tutti i dati di vendita attuali e abbiamo uno spazio illimitato per i dati di archivio dettagliati.abbiamo provato a mantenerlo tutto in un database (in tabelle diverse) ma la dimensione del file del database (interbase) sarebbe cresciuta così tanto da trascinare il sistema verso il basso.

l'unico vero problema che abbiamo è l'accesso a dati dettagliati che si estendono su diversi database, poiché la connessione e la disconnessione sono lente e l'analisi deve essere eseguita in codice anziché in SQL

Answer 2

Se stai utilizzando SQL Server 2005, questo potrebbe essere un buon candidato per l'utilizzo tabelle partizionate.

Answer 3

A seconda dei vincoli come il budget, ecc., sembra un candidato perfetto per un'applicazione di data warehouse.Ciò in genere introduce un nuovo server da utilizzare come data warehouse.SQL Server 2005 supporta molte di queste attività immediatamente, inoltre potresti essere in grado di utilizzare servizi SQL Server aggiuntivi (ad es.Analysis Services, Reporting Services) per fornire valore aggiuntivo ai tuoi utenti.(Vedere http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)

Answer 4

@Jason - Non vedo come mantenere i dati in vecchi file di testo ti consentirà di eseguire facilmente analisi delle tendenze a lungo termine sui dati.

@Jason - Immagino che il punto sia che se qualsiasi tipo di analisi ad hoc (ad es.trend) deve essere eseguita sui dati da parte di uomini d'affari, raggruppare o archiviare i dati in file di testo in realtà non risolve alcun problema.Naturalmente scrivere codice per utilizzare un file di testo è facile in molti linguaggi, ma il problema è stato risolto.Inoltre, direi che gli RDBMS di oggi sono tutti estremamente durevoli se configurati e mantenuti correttamente.Se non lo fossero, perché dovresti gestire un'attività sopra una di esse (per non parlare di archiviarvi i dati)?Semplicemente non vedo il punto di archiviare in un file di testo semplice a causa dell'affermazione che la durabilità dei file di testo è superiore a quella dei database.

Answer 5

Entrambe queste opzioni sono eccellenti, ma dipende in realtà dal dominio problematico.Per cose come saldi di cassa o dati statistici, penso che raggruppare i record e consolidarli sia il modo migliore, puoi quindi spostare i record raggruppati in una tabella di archivio parallela, digitandoli in modo tale da poterli "srotolare" se necessario.Ciò mantiene la tabella dei dati primaria pulita e veloce, ma ti consente di conservare i dati extra per il controllo o altro.La domanda chiave è: come implementare il processo di "roll-up".Automaticamente, tramite un trigger o un processo lato server oppure tramite l'intervento dell'utente a livello di applicazione?