Come devo conservare grandi quantità di dati di traffico per un facile recupero?

Question

per un sistema di contabilità del traffico Ho bisogno di memorizzare grandi quantità di set di dati circa i pacchetti inviati su internet tramite il nostro router gateway (timestamp contenente, user id, destinazione o IP sorgente, il numero di byte, ecc.).

Questi dati devono essere conservati per un certo tempo, almeno un paio di giorni. Facile recupero dovrebbe essere possibile pure.

Che cosa è un buon modo per fare questo? Ho già alcune idee:

• Crea un file per ogni utente e giorno e aggiungere ogni set di dati ad esso.

  • Vantaggio: Probabilmente è molto veloce, ed i dati è facile da trovare dato un layout di file coerente
  .
  • Svantaggi: Non è facilmente possibile vedere per esempio tutto il traffico UDP di tutti gli utenti.

• Utilizzare un database

  • Vantaggio: E 'molto facile trovare i dati specifici con la query SQL destra.
  • Svantaggi:. Non sono sicuro se c'è un motore di database che può efficacemente gestire un tavolo con forse centinaia di milioni di set di dati

• Forse è possibile combinare i due approcci: L'utilizzo di un file di database SQLite per ogni utente.

  • Vantaggio: Sarebbe facile per ottenere informazioni per un utente utilizzando query SQL nel suo fascicolo.
  • Svantaggi:. Ottenere informazioni complessivo sarebbe comunque difficile

Ma forse qualcun altro ha una buona idea?

Grazie mille in anticipo.

Answer 1

In primo luogo, ottenere Il Data Warehouse Toolkit prima di fare qualsiasi cosa.

Si sta facendo un lavoro di data warehousing, è necessario affrontare il problema come un lavoro di data warehousing. Avrete bisogno di leggere sui modelli di progettazione adeguate per questo genere di cose.

[Nota Data Warehouse non significa grande pazzo o costose o complesse. Significa schema a stella e modi intelligenti per gestire grandi volumi di dati che non è mai aggiornato.]

1. database SQL sono lenti, ma che lento è un bene per il recupero flessibile.

2. Il file system è veloce. E 'una cosa terribile per l'aggiornamento, ma non sei l'aggiornamento, si sta solo accumulando.

Un tipico approccio DW per questo è di fare questo.

1. Definire il "Star Schema" per i dati. I fatti misurabili e gli attributi ( "dimensioni") di quei fatti. La vostra realtà sembrano essere # di byte. Tutto il resto (indirizzo, data e ora, id utente, ecc) è una dimensione di questo fatto.

2. Crea i dati dimensionali in un database dimensione principale. E 'relativamente piccolo (indirizzi IP, gli utenti, una dimensione data, ecc) Ogni dimensione avrà tutti gli attributi si potrebbe desiderare di sapere. Questo cresce, le persone sono sempre aggiungendo attributi alle dimensioni.

3. Crea un processo di "carico" che prende il vostro log, risolve le dimensioni (tempi, indirizzi, utenti, ecc) e si fonde le chiavi della dimensione con le misure (numero di byte). Questo può aggiornare la dimensione per aggiungere un nuovo utente o un nuovo indirizzo. In generale, stai leggendo fatto le righe, fare ricerche e scrivere file fatto che hanno tutte le funzionalità del FK adeguata ad essi associati.

4. Salva questi caricare file sul disco. Questi file non vengono aggiornati. Hanno appena si accumulano. Utilizzare una semplice notazione, come CSV, in modo da poter facilmente irrobustirsi caricarli.

Quando qualcuno vuole fare analisi, costruire loro un datamart.

Per l'indirizzo IP selezionato o periodo di tempo o qualsiasi altra cosa, ottenere tutti i fatti rilevanti, più i dati di dimensione maestro associati e alla rinfusa caricare un datamart.

Si può fare tutte le query SQL che si desidera in questo mart. La maggior parte delle domande rivolte devolverà al SELECT COUNT(*) e SELECT SUM(*) con vari GROUP BY e clausole HAVING e WHERE.

Answer 2

Credo che la risposta corretta in realtà dipende la definizione di un "set di dati". Come si parla nella domanda si sta archiviando set individuali di informazioni per ogni record; timestamp, ID utente, IP di destinazione, IP di origine, il numero di byte, ecc ..

SQL Server è perfettamente in grado di consegnare questo tipo di memorizzazione dei dati con centinaia di milioni di record senza una reale difficoltà. Certo questo tipo di registrazione c'è bisogno di un po 'di buon hardware per gestire la cosa, ma non dovrebbe essere troppo complesso.

Qualsiasi altra soluzione, a mio parere sta andando a fare la segnalazione molto duro, e dai suoni di esso che è un requisito importante.

Answer 3

Quindi, ci si trova in uno dei casi in cui si dispone di molto di più attività di scrittura di leggere, si desidera che le scrive non bloccare voi, e volete che il vostro letture di essere "abbastanza veloce" no, ma critica. E 'un tipico caso d'uso di business intelligence.

Probabilmente si dovrebbe utilizzare un database e memorizzare i dati in uno schema come "denormalizzato" per evitare unisce complessa e inserti multipli per ogni record. Pensate al vostro tavolo come un file di log enorme.

In questo caso, alcuni dei database NoSQL "nuovi e fantasia" sono probabilmente quello che stai cercando: essi forniscono vincoli ACID rilassata, che non si dovrebbe terribilmente dispiacerebbe qui (in caso di crash, si può perdere l'ultima linee di registro), ma che svolgono molto meglio per l'inserimento, perché non c'è bisogno di sincronizzare riviste sul disco in ogni transazione.