SQLDatabase: legge molti dati contemporaneamente e processa in memoria o legge i dati quando ne ho bisogno?

Question

SQLDatabase: legge molti dati contemporaneamente e processa in memoria o legge i dati quando ne ho bisogno?

#1 da (3 voti)

-1

Non sono sicuro di come affrontare questo problema. Richiedo una grande quantità di record di dati dal server SQL. Questo blocco è basato su variabili, quindi non so prima di quali record ho bisogno. Ho bisogno di fare una grande serie di calcoli e ogni calcolo richiede uno (o più) record da questo blocco di dati. Ancora: non so quali documenti sono richiesti.

Dovrei:

A. Carica tutti questi dati nella memoria dell'applicazione tutti in una volta

Questo crea una singola connessione al DB, carica TUTTI i dati richiesti da un comando di query (e un solo DataReader in avanti) e quindi non infastidisce più il server SQL.
Il datafetch sembra essere lento, poiché sta leggendo centinaia di migliaia di righe nella memoria

B. Ogni volta che il calcolo richiede dati, recuperalo dal database

Ciò aprirebbe e chiuderebbe una connessione al db SQL più volte al secondo.
Il datafetch iniziale viene ridotto a pochi millisecondi, ma durante il calcolo crea un carico enorme sul server SQL.

c# sql database sql-server

posta Recipe 15.10.2014 - 10:13

fonte

1 risposta

Leggi altre domande sui tag c# sql database sql-server

Come progettare URI RESTful per ottenere tutti i messaggi non letti? Quali sono le linee guida per un albero di sorgenti C ++ Win / Mac / Linux? [chiuso]

score 3 · Accepted Answer

In primo luogo, se è possibile convertire l'intero calcolo in una query SQL (o in una serie di query o in una stored procedure), eseguire tale operazione. I database sono bravi in questa roba e tu o un DBA potresti essere in grado di fare molto per migliorare la query se è ancora troppo lento.

In caso contrario:

Utilizza un pool di connessioni. Non farlo è di solito pazzesco, a meno che tu non stia scrivendo uno script che si connette solo una volta o due.
Se stai provando questo in un ambiente di sviluppo con un DB locale, fai attenzione che ci può essere una grande differenza nelle caratteristiche delle prestazioni rispetto a quelle di produzione e non esagerare con l'ottimizzazione in base a ciò che si misura. I ritardi della rete, in particolare, potrebbero sorprenderti. Il recupero di una riga alla volta può andare bene con una bassa latenza di rete e terribile con una elevata.
Le dimensioni del database di solito sono più grandi in produzione e aumentano nel tempo. Se recuperi tutti i dati in anticipo, potresti rimanere scoperto e esaurire la memoria (a meno che tu non sappia di più sui tuoi dati, allora facciamo ...).
Come suggerisce Pieter B, probabilmente stai migliorando il recupero dei dati in batch se hai davvero bisogno di un numero elevato di righe. Quindi non eliminerai tutto il resto dalla memoria del tuo server, né avrai una latenza di rete e un sovraccarico della query su ogni riga. Aiuterà anche se vuoi segnalare i progressi all'utente.
Se sei veramente serio nel farlo andare il più velocemente possibile e non usare SQL per farlo, allora potresti provare a parallelizzare il tuo codice. Quindi puoi calcolare con un set di dati mentre recuperi il successivo, e se il tuo DB di produzione ha più core e dischi puoi parallelizzare anche nel DB. Puoi anche guardare il caching, se appropriato (memcached e simile, o direttamente nel tuo server se conosci abbastanza bene le dimensioni dei tuoi dati).