Rapidamente grandi dati pivoting

3

Stiamo sviluppando un prodotto che può essere utilizzato per lo sviluppo di modelli predittivi e l'affettamento e il cubettatura dei dati per fornire la BI.

Abbiamo due tipi di requisiti per l'accesso ai dati.

Per la modellazione predittiva, abbiamo bisogno di leggere i dati su base giornaliera e farlo riga per riga. In questo il normale database di SQL Server è sufficiente e non riscontriamo alcun problema.

In caso di affettare e tagliare a cubetti dati di dimensioni enormi come 1 GB di dati con diciamo 300 righe M. Vogliamo modificare facilmente questi dati con un tempo di risposta minimo.

Il database SQL corrente sta avendo problemi di tempo di risposta in questo.

Ci piace che il nostro prodotto funzioni su qualsiasi normale macchina client con 2 GB di RAM con processore Core 2 Duo.

Vorrei sapere come memorizzare questi dati e come posso creare un'esperienza di rotazione per ciascuna dimensione.

Idealmente avremo dati di dirci vendite giornaliere per persona di vendita per regione per prodotto per una grande azienda. Quindi vorremmo suddividerlo e tagliarlo in base a qualsiasi dimensione e anche essere in grado di eseguire aggregazioni, valori univoci, valori massimi, minimi, medi e alcune altre funzioni statistiche.

    
posta Kuntal Shah 29.06.2011 - 13:26
fonte

3 risposte

2

Questo prodotto ha un server database dedicato o il database è ospitato sulla workstation limitata che hai descritto?

Per ruotare i dati per analisi come questa è necessario prima appiattire la struttura dei dati, e non è possibile appiattire la struttura dei dati senza fare un sacco di join. Il successo in termini di prestazioni diventa più evidente quando si uniscono tabelle con milioni di record.

Una volta appiattiti i dati, la rotazione effettiva dei dati è meno intensa.

Ci sono molti modi per farlo, ma provare a farlo direttamente da un RDBMS transazionale normalizzato non va bene. Questo sovraccaricherà il server del database e ridurrà le normali transazioni quotidiane delle applicazioni (CRUD).

Un modo per farlo è creare un database denormalizzato separato per la reportistica analitica e il flusso di dati di routine per aggiornare questo repository. Un DataMart è un buon esempio di questo.

Inoltre, i fornitori di database come Oracle hanno Stream che consentono aggiornamenti costanti programmati del data mart dal database transazionale .

I vantaggi sono chiari, il carico generato da report e analisi in esecuzione sta offloadando il miglioramento delle prestazioni delle applicazioni, i flussi possono essere eseguiti anche durante le ore non di punta.

I contro sono che il Data Mart non avrà mai dati in tempo reale.

    
risposta data 29.06.2011 - 13:41
fonte
1

Sembra un caso solido per l'utilizzo di MongoDB invece di un archivio DB relazionale.

    
risposta data 29.06.2011 - 14:14
fonte
0

Non dovresti semplicemente usare SQL Server Datamart / Data Warehousing? Forse i clienti non vogliono pagare per questo solo per usare il tuo prodotto.

    
risposta data 29.06.2011 - 13:31
fonte

Leggi altre domande sui tag