Importare grossi file di testo dentro a DataTable
Marcolino
devo scrivere un'applicazione per analizzare dei syslog generati da
degli apparati.
Ho realizzato un DataGrid appoggiato a un DataTable in cui carico i
dati presi dal file di testo del Syslog.
I campi nel file di testo sono delimitati dal carattere : e per
splittare i file ho usato una regular expression, poi con un ciclo
while carico i dati nel DataTable.
Il problema è che il file di testo potrebbe anche raggiungere le
150.000 righe e il caricamento del file rallenta man mano fino a
caricare un record alla volta mettendoci anche 1 ora a caricare il
file.
Io cercavo un modo per dumpare il file di testo nel datatable +
velocemente.
Uso VB.Net 2005
Grazie per ogni consiglio.
M.
VincePik
>Io cercavo un modo per dumpare il file di testo nel datatable +
>velocemente.
>Uso VB.Net 2005
>
>Grazie per ogni consiglio.
Butta via i Datatable!
Potresti crearti una classe ElementoLog e una collection (listof, hashtable
vedi tu quale pu� essere meglio per il tuo caso) e gestire tutto a mano.
Se puoi passare a vb2008 (o meglio al FW 3.5) e conosci LINQ sei a cavallo!
Ciao, Vincenzo
Luca D
> Ciao a tutti,
> devo scrivere un'applicazione per analizzare dei syslog generati da
> degli apparati.
> Ho realizzato un DataGrid appoggiato a un DataTable in cui carico i
> dati presi dal file di testo del Syslog.
> I campi nel file di testo sono delimitati dal carattere : e per
> splittare i file ho usato una regular expression, poi con un ciclo
> while carico i dati nel DataTable.
> Il problema è che il file di testo potrebbe anche raggiungere le
> 150.000 righe e il caricamento del file rallenta man mano fino a
> caricare un record alla volta mettendoci anche 1 ora a caricare il
> file.
Stai transitando da oggetti troppo complessi per quello che devi fare;
in più coinvolgi l'interfaccia utente, che ti rallenta ulteriormente
la faccenda.
Spezza la logica del tutto in due parti distinte: import dei dati e
visualizzazione.
Per l'import, fai tutto senza aggiornare la UI, al massimo una
progress bar; fatto il parsing della riga, butta direttamente in
tabella tramite DataAdapter o anche direttamente via comando SQL.
A quel punto, la griglia la popoli alla fine, non con un DataTable o
altro, ma con un DataReader (da come lasci intendere, non devono
essere editati ma solo consultati), di gran lunga più veloce.
Anche se stai facendo fare il lavoro due volte al DB (prima scrivi la
tabella, poi la rileggi) il risultato finale vedrai che sarà
nettamente più rapido... Anche non conoscendo bene come sono fatti i
dati, a spanne 150.000 record in 1 ora è proprio tanto, pure su un PC
a carbonella; 150.000 INSERT INTO e poi la query alla fine via
DataReader devono stare nell'ordine dei pochi minuti.
VincePik
>nettamente pi� rapido... Anche non conoscendo bene come sono fatti i
>dati, a spanne 150.000 record in 1 ora � proprio tanto, pure su un PC
>a carbonella; 150.000 INSERT INTO e poi la query alla fine via
>DataReader devono stare nell'ordine dei pochi minuti.
Al momento stiamo lavorando su un progetto che rileva in tempo reale le
persone presenti in determinate aree controllate.
Si parla di circa 600.000 record che crescono di continuo man mano che le
persone attraversano i varchi in ingresso o uscita.
I dati sono su SQL Server e vengono mostrati a video gli ultimi 50 record
(personalizzabile)... ti posso dire che la SP che tira fuori i dati ci
impiega meno di un secondo!
Pochi altri secondi e i record sono mostrati su una griglia... naturalmente
tutto sensa usare Dataset, datatable e porcherie varie
Ciao, Vincenzo
Luca D
wrote:
> >Anche se stai facendo fare il lavoro due volte al DB (prima scrivi la
> >tabella, poi la rileggi) il risultato finale vedrai che sar
> >nettamente pi rapido... Anche non conoscendo bene come sono fatti i
> >dati, a spanne 150.000 record in 1 ora proprio tanto, pure su un PC
> >a carbonella; 150.000 INSERT INTO e poi la query alla fine via
> >DataReader devono stare nell'ordine dei pochi minuti.
>
> Al momento stiamo lavorando su un progetto che rileva in tempo reale le
> persone presenti in determinate aree controllate.
> Si parla di circa 600.000 record che crescono di continuo man mano che le
> persone attraversano i varchi in ingresso o uscita.
> I dati sono su SQL Server e vengono mostrati a video gli ultimi 50 record
> (personalizzabile)... ti posso dire che la SP che tira fuori i dati ci
> impiega meno di un secondo!
Non ho dubbi... lui però mi sembra voglia fare una cosa un po'
diversa, ovvero caricare tutte le volte questi 150k record *in
blocco*, e mostrarli tutti e 150k
Mostrarli, con un reader data bound o quello che ti pare, è un attimo;
a caricarli tutti sul DB però, se 1 ora è senz'altro impensabile,
"mezzo secondo" mi pare ottimistico.
Un conto è una SELECT su una tabella grossa, un conto è popolarla da
zero...
VincePik
>diversa, ovvero caricare tutte le volte questi 150k record *in
>blocco*, e mostrarli tutti e 150k
IMHO E' sbagliato l'approccio... nessun occhio umano potr� tenere sotto
controllo una tale quantit� di dati.
Quindi dovrebbe caricare un certo numero di record e lavorare di
paginazione.
>Mostrarli, con un reader data bound o quello che ti pare, � un attimo;
>a caricarli tutti sul DB per�, se 1 ora � senz'altro impensabile,
>"mezzo secondo" mi pare ottimistico.
>Un conto � una SELECT su una tabella grossa, un conto � popolarla da
>zero...
Ma infatti non dovrebbe caricarli su un DB solo per visualizzarli... come ho
detto nel primo post, dovrebbe lavorare con qualche tipo di collection
Poi usando l'objectdatasource mostra i dati con uno degli oggetti che lo
supportano.
Ciao, Vincenzo
Luca D
wrote:
> IMHO E' sbagliato l'approccio... nessun occhio umano potrà tenere sotto
> controllo una tale quantità di dati.
> Quindi dovrebbe caricare un certo numero di record e lavorare di
> paginazione.
Posso anche essere d'accordo, comunque un DataGrid con un databinding
qualunque, fa già paginazione già di suo, non carica tutto...
La sua lentezza è nel come carica il DataTable, non la griglia
> >Mostrarli, con un reader data bound o quello che ti pare, è un attimo;
> >a caricarli tutti sul DB però, se 1 ora è senz'altro impensabile,
> >"mezzo secondo" mi pare ottimistico.
> >Un conto è una SELECT su una tabella grossa, un conto è popolarla da
> >zero...
>
> Ma infatti non dovrebbe caricarli su un DB solo per visualizzarli... come ho
> detto nel primo post, dovrebbe lavorare con qualche tipo di collection
> Poi usando l'objectdatasource mostra i dati con uno degli oggetti che lo
> supportano.
Eh, ma se a lui servono nel DB, saranno anche fatti suoi... non credo
li metta per visualizzarli in griglia e poi buttarli via