Generazione di report da set di dati di grandi dimensioni

Question

Generazione di report da set di dati di grandi dimensioni

#1 da (1 voti)

1

Sto lavorando a un'applicazione di tipo CRM (.NET, SQL Server) che deve generare report da set di dati di grandi dimensioni, milioni di righe di database in una dozzina di tabelle diverse con un sacco di aggregazione e logica. I report sono attualmente generati da lunghe e complicate stored procedure con molti join, tabelle temporanee e logica. Questi report devono seguire una specifica di terze parti e il modo in cui sono attualmente scritti spesso produce dati non corretti. Ci sono anche problemi di prestazioni in quanto i rapporti richiedono circa 10 volte più tempo di quanto dovrebbero. Mi trovo a dover riscrivere le stored procedure o trovare un altro modo di generare i report. Ho due requisiti principali, velocità e precisione.

SQL sembra la scelta migliore per la velocità. I dati sono relazionali e già esistono in un database. Lo svantaggio di SQL è che i report sono molto complessi e avere tutto in una o più query giganti rende difficile testare diversi pezzi della logica.

Effettuare i calcoli in C # sembra una scelta migliore per testabilità / accuratezza, ma non credo che funzionerebbe molto bene a causa dei requisiti di memoria e della natura lenta del codice procedurale.

Ciò che mi rende incline a una soluzione non SQL è che a volte i nostri clienti ritengono che i rapporti siano sbagliati quando si tratta davvero di dati personali sbagliati. I clienti spesso si aspettano che un record personale venga visualizzato in un report, ma in base alle regole del report il record non deve essere incluso in base ai valori di determinate colonne. Poiché la logica è così complessa e i nostri rapporti sono scritti in modo così grave, di solito non possiamo dire ai clienti che i loro dati sono negativi e perché fino a quando non trascorriamo un giorno o due per tracciare quel record attraverso la logica della query del report. Sarebbe bello se avessimo un motore di regole che potremmo eseguire su qualsiasi dato record per vedere esattamente quali colonne di dati stanno causando che vengano filtrate dal rapporto. Preferirei non implementare la logica del rapporto due volte, una volta nella query del report e di nuovo in un motore di convalida.

Qual è la scelta migliore qui? Esistono dei motori di regole che possono operare su dataset di grandi dimensioni? Non so molto dei big data, ma ho sentito parlare di map / reduce e Hadoop. Qualcosa del genere sarebbe d'aiuto? Che dire di un linguaggio funzionale come F #? Altre opzioni?

c# database sql-server stored-procedures reporting

posta Dave A 14.07.2016 - 08:04

fonte

1 risposta

Leggi altre domande sui tag c# database sql-server stored-procedures reporting

Mappatura dei valori enum in regex Implementazione forzata di un'interfaccia per utilizzare una funzione, per abilitare funzionalità trasparenti per l'utente

score 1 · Answer 1

Mi occupo di una situazione molto simile in cui raccogliamo una grande quantità di dati relazionali, li filtriamo e li riduciamo a un sottoinsieme più piccolo, e quindi creiamo gli aggregati di massimo livello che possiamo produrre dati veloci e "accurati" . Essere precisi è solo buono come quello che succede. A meno che non si filtri e si identificano i dati cattivi in entrata, le probabilità che i dati cattivi vengano fuori sono piuttosto alte.

Usiamo anche SQL come sollevatore pesante e qui è dove eseguiamo build di dati / aggrgate di grandi dimensioni con stored procedure settimanali o notturne. Ciò semplifica la restituzione di report veloci tramite il nostro portale web o il servizio di iscrizione via email.

C'è un sacco di cose che puoi fare mentre usi ancora SQL e non del tutto il rooting di tutto.

Suggerimenti durante l'utilizzo di SQL:

Identifica i sottoinsiemi di dati che possono essere estratti per un determinato cliente (Filtra i dati bene)
Assicurati che gli indici siano ottimizzati e configurati correttamente (un indice non valido può rovinare tutto)
Approfitta della tua versione di SQL e dell'hardware della macchina (assicurati di usare il parallelismo di sql e prova a eseguire più moduli contemporaneamente per aumentare il throughput)
Se tutto il resto fallisce, assicurati che qualsiasi query che colpisce una tabella che viene scritta usi anche una (con nolo)
Se è necessario ripetere il processo, modularizzare ogni calcolo richiesto per il più alto aggregato richiesto e archiviare queste informazioni separatamente in modo da poter inserire tutti gli aggregati richiesti per produrre i risultati finali
Pensa nei passaggi e prova a creare un aggregato di basso livello che può essere utilizzato per creare il livello successivo e così via.

Il server SQL è veloce e al giorno d'oggi può svolgere molte delle funzioni che normalmente si proverebbero in un'applicazione standalone. Quindi, a meno che tu non abbia un hardware molto piccolo che esegue SQL e non c'è spazio per l'espansione, utilizzerei semplicemente SQL per i calcoli. Il più grande beneficio per un'applicazione autonoma che fa i calcoli è che sarà meglio mantenere il codice saggio ed è possibile eseguire processi multithread su uno o più computer. Inoltre, non è necessario ottenere più licenze SQL.

Posso sicuramente dire che se i tuoi dati sono già relazionali, metterli in una struttura di database non relazionale renderà le cose ancora più difficili. Un'altra opzione oltre a ridimensionare le istanze SQL è ridimensionare con un altro database relazionale. Postgres è estremamente potente e può competere con MSSQL quando si tratta di velocità di elaborazione. La mia azienda ha iniziato la conversione da SQL e abbiamo diffuso parte della potenza di elaborazione su diversi nodi di calcolo utilizzando Postgres-XL .