Progettare un grande database con più fonti

Naviga le tue risposte
2

Mi è stato assegnato il compito di ridisegnare o, nel peggiore dei casi, di ottimizzare la struttura di un database per un data warehouse.

Attualmente, il database ha 4 altri database sorgente (che è dovuto espandere a X numero di altri), ognuno dei quali ha le proprie strutture dati, convenzioni di denominazione ecc. Al momento un pacchetto SSIS notturno estrae i dati dal varie fonti e quindi per ogni fonte coprono i dati in un formato standardizzato e utilizzabile. Queste tabelle vengono poi aggiunte tra loro creando una fila di 60 m, una bestia da 40 colonne !.

Questa tabella viene quindi utilizzata in vari modi da un cubo OLAP a un front-end Web.

La struttura è in vigore da molto tempo e il lavoro che ho potuto dimostrare i vantaggi della normalizzazione, e questo è il modo in cui mi piacerebbe andare. Il problema per me è che il processo durante la notte richiede così tanto tempo che non voglio passare più tempo a normalizzare l'ultimo tavolo in qualcosa di utile.

Qualcuno può offrire spunti o idee nel modo migliore per ristrutturare o ottimizzare il database in modo efficiente?

Modifica:

Tutti i database sono MS SQL Server 2008 R2

Grazie in anticipo

CM

    
posta CatchingMonkey 28.03.2012 - 17:19
fonte

3 risposte

4

Per i database OLAP, la normalizzazione è spesso non l'approccio migliore - questo è completamente diverso dai classici database OLTP. La struttura delle tue tabelle dovrebbe essere ottimizzata per le query che stai per eseguire. Raccomando gli articoli di Wikipedia su schema a stella o schema a fiocco di neve , sono schemi per una buona progettazione di database OLAP.

Ecco un libro sull'argomento che posso consigliare:

link

Qualcosa che non hai scritto (ma ti chiedi davvero) è perché vuoi veramente ristrutturare il sistema. Solo perché è denormalizzato e pensi che questa non sia la "migliore pratica"? O soffri di problemi di prestazioni o di archiviazione reali? Se è solo la prima ragione, dovresti prima leggere qualcosa di più sulla buona progettazione del db OLAP prima di cambiare il sistema.

    
risposta data 28.03.2012 - 18:32
fonte
2

Difficile da dire senza conoscere ulteriori dettagli, quindi ecco alcuni suggerimenti:

  • L'estratto da altre fonti deve avvenire durante la notte? È possibile che almeno alcuni dati siano abbastanza coerenti in vari punti nell'arco della giornata? Ciò potrebbe consentire di eseguire diversi ritocchi di dati più piccoli 3 o 4 volte al giorno secondo un programma, lasciando più tempo libero nella notte per normalizzarsi. Oppure, potresti anche iniziare il processo di costruzione del cubo OLAP in piccoli bit, assumendo che sia possibile con questi dati. O vai ancora oltre e rendilo un processo quasi continuo per tutto il giorno.

  • La grande tabella è sovradimensionata? Forse troppi indici stanno rallentando gli inserimenti.

  • La normalizzazione parziale andrebbe bene? Forse normalizza solo una o due colonne importanti.

  • Sarebbe OK se il cubo OLAP non fosse disponibile fino a tardi rispetto a quello attuale?

  • Puoi ottenere un budget per acquistare l'hardware migliore (per questo lavoro), supponendo che ci sia un collo di bottiglia che può essere risolto dagli aggiornamenti hardware?

risposta data 28.03.2012 - 17:33
fonte
0

Poiché il limite di tempo è legato solo al collegamento con i database di produzione, estrarre i dati da essi in una sorta di area di gestione con la minore quantità di elaborazione possibile.

Quindi puoi iniziare il processo di normalizzazione dei dati secondo necessità.

Qui ci sono alcuni svantaggi:

  1. Spazio di archiviazione richiesto per l'area di staging (ovviamente è possibile scaricarlo al termine).
  2. Questo potrebbe richiedere più tempo, quindi i consumatori di questo database devono attendere più a lungo.
risposta data 28.03.2012 - 19:23
fonte

Leggi altre domande sui tag

Evoluzione di un'applicazione: come gestire e migliorare il core engine? come creare archivi zip java con un limite massimo di dimensioni del file