Approccio per l'analisi e l'indicizzazione di file molto grandi

Question

Approccio per l'analisi e l'indicizzazione di file molto grandi

#1 da (2 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (1 voti)

5

Mi è stato affidato lo sviluppo di un visualizzatore Web (cioè eseguito nel browser) per un file di registro proprietario.

Non ho il controllo sul formato dei log, li consumo solo. Il file di registro contiene dati binari aggiunti da un messaggio di testo su ogni riga, quindi la parte di ogni riga deve essere deserializzata in lettura.

Quello che sto proponendo è l'approccio preferito qui per leggere rapidamente il file e renderlo disponibile per la ricerca e la pagina di recupero del testo.

I miei approcci:

Ho un servizio Web che legge il file e ne inserisce il contenuto in massa

Nell'installazione di un server SQL
In un no-SQL senza server come LiteDb
In un'istanza Sqlite senza server con un file sqlite per file di registro.

I dati vengono cancellati dopo che i dati del file di registro non sono stati visualizzati per una settimana.

Il problema è che questi approcci funzionano bene su file con meno di 100 MB ma si rompono rapidamente con file di registro che a volte diventano 2 GB.

Anche su un file da 2 GB, l'analisi è relativamente veloce e apparentemente non è il collo di bottiglia. Sulle opzioni inutili, anche la scrittura dei dati analizzati è relativamente veloce

La query di testo completo non è eccezionale su nessuna opzione, anche se una volta che l'indice ha il tempo di creare sul server Sql, è decente.

Mi chiedo se qualcuno abbia qualche consiglio / esperienza con questo tipo di progetto - in pratica, de-serializzare rapidamente un file di grandi dimensioni e inserirli in massa in una sorta di archivio dati (forse un data-store in memoria sarebbe meglio ) e renderlo disponibile per l'interazione tramite un servizio web.

CHIARIMENTI:

@Basile - Scusa, non volevo sottintendere questo, volevo solo assicurarmi che stavo guardando in basso alla migliore via e avessi la soluzione più adatta

@Basile - I file di registro sono semplici, solo un blob binario da 45 byte che ho letto come byte e copiato in una struct (in .NET), quindi ho letto il resto del testo fino a un nuovo carattere di riga. Ripeti fino a EOF.

@DocBrown Spiacente, ho letto questo, ho pensato che fosse appropriato vedi qui

@Christophe Non ho 3 DB, quelli sono solo i tre approcci che ho provato finora.

data parsing indexing

posta Matt 19.12.2016 - 08:28

fonte

4 risposte

Leggi altre domande sui tag data parsing indexing

Devo creare un (nuovo) progetto per UserControls condivisi? Come integrare le versioni con changelog?

score 2 · Answer 1

Prova il Kibana di Elasticsearch, creato per interrogare / sfogliare i registri di grandi dimensioni. link

Utilizza Elasticsearch sotto il cofano che puoi interfacciare direttamente con se vuoi.

In caso contrario. Se il tuo parser è veramente veloce, prova a vedere se potresti "emettere" le voci durante lo streaming del tuo log. Potresti forse farla franca eseguendo una scansione completa (di testo) senza prima averla buttata tutta in memoria o in un database.

score 2 · Answer 2

Non penso sia una buona idea precaricare 2 GB di dati di log. Ciò renderebbe un'esperienza utente insopportabile, e se si esegue questa cosa su un server di produzione si innescheranno un sacco di allarmi nel NOC.

Mi concentrerei su come mantenere un minimo ingombro di memoria e leggere il meno possibile il file. Ci sono modi per cercare il file senza effettivamente caricarlo. Alcuni casi di utilizzo comuni:

L'utente vuole vedere i dati del registro da una certa parte del file, come indicato trascinando una barra di scorrimento.

Apri un file stream sul file e calcola il target di un'operazione di ricerca moltiplicando [lunghezza file totale] * [percentuale barra di scorrimento].
Cerca la posizione di destinazione
Leggi fino al successivo carattere di nuova riga; scarto
Iniziare a leggere e visualizzare i record finché lo schermo non è pieno

L'utente vuole vedere i dati del registro per un certo periodo di tempo

Apri il flusso di file sul file
Dividi il file a metà; cerca il punto a metà strada
Passa al carattere di nuova riga successivo, quindi leggi il record successivo
Analizza la data / l'ora.
Se la data / ora è giusta, fermati
Se la data / ora è troppo bassa, ripeti le operazioni sopra riportate nella seconda metà del file (quindi nel passaggio 2 trovi effettivamente il 3/4)
Se la data / ora è troppo alta, ripeti le operazioni sopra riportate nel primo tempo (quindi nel passaggio 2 stai effettivamente trovando il 1/4)
Continua a ripetere fino a trovare l'intervallo di tempo desiderato. Questa è conosciuta come ricerca binaria .

score 2 · Answer 3

Un concetto da tenere a mente qui è che "potenza di calcolo e IO sono molto, molto cari al punto di attacco proverbiale ma molto, molto a buon mercato in background."

Quindi, presumendo che non stiamo parlando di operazioni in tempo reale qui, vorrei adottare un approccio diverso. Avrei il servizio web eseguito come un agente che carica costantemente i file di log e lascerei il client interrogarlo su richiesta. Questo dovrebbe alleviare i problemi di caricamento in quanto la maggior parte dei dati è già stata caricata. Per lo spazio su disco, il database o l'app possono facilmente gestire i compiti di troncamento in base alle politiche di conservazione.

score 1 · Answer 4

Distribuisci un processo che consuma il file e si trasforma in una struttura di dati che inserisci in un database. Se i file hanno potenzialmente dimensioni di GB, leggere il file riga per riga ed elaborarli. Questo ridurrà l'impronta della memoria.

Se il tuo database è MSSQL ed è la versione 2008R2 o successiva, utilizza la funzione di indice di testo completo. Lo dico perché è uno con cui ho esperienza di prima mano. La maggior parte delle altre piattaforme DB avrà una funzionalità di indice di testo completo. In caso contrario, rivolgersi a lucene o solr (entrambi da Apache) per gestire l'indicizzazione per la ricerca.

Dovrai elaborare un metodo per eseguire il loop di questo ingest per raccogliere nuovi / incrementali articoli ed evitare di duplicare i record duplicati. Il modo in cui lo fai dipende dalla struttura dei dati del file di registro e da come l'app lo produce.

L'interfaccia utente web dovrebbe essere un altro processo che funge da livello di presentazione per l'interazione con i dati pre-ingaggiati e indicizzati.