Come devo memorizzare quantità estremamente elevate di dati sul traffico per un facile recupero?

Question

per un sistema di contabilità del traffico Ho bisogno di memorizzare grandi quantità di set di dati sui pacchetti internet inviati attraverso il nostro router gateway (contenente timestamp, ID utente, destinazione o IP sorgente, numero di byte, ecc.).

Questi dati devono essere memorizzati per qualche tempo, almeno alcuni giorni. Anche il recupero facile dovrebbe essere possibile.

Qual è un buon modo per farlo? Ho già alcune idee:

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

  • Vantaggio: Probabilmente è molto veloce e i dati sono facili da trovare dato un layout di file coerente.
  • Svantaggio: non è facilmente possibile vedere ad es. tutto il traffico UDP di tutti gli utenti.

• utilizzare un database

  • Vantaggio: E 'molto facile trovare i dati specifici con la query SQL destra.
  • Svantaggio: non sono sicuro che esista un motore di database in grado di gestire in modo efficiente una tabella con possibilmente centinaia di milioni di dataset.

• Forse è possibile combinare i due approcci: Utilizzo di un file di database SQLite per ciascun utente.

  • Vantaggio: sarebbe facile ottenere informazioni per un utente utilizzando query SQL sul suo file.
  • Svantaggio: ottenere informazioni generali sarebbe ancora difficile.

Ma forse qualcuno ha una buona idea?

Grazie mille in anticipo.

Answer 1

Penso che la risposta corretta dipenda realmente dalla definizione di un "set di dati". Come hai detto nella tua domanda, stai memorizzando i singoli set di informazioni per ogni record; timestamp, userid, destinazione ip, ip origine, numero di byte ecc.

SQL Server è perfettamente in grado di gestire questo tipo di archiviazione di dati con centinaia di milioni di record senza alcuna reale difficoltà. Garantito che questo tipo di registrazione richiederà un buon hardware per gestirlo, ma non dovrebbe essere troppo complesso.

Qualsiasi altra soluzione, a mio avviso, renderà molto difficile la segnalazione e dal suo punto di vista è un requisito importante.

Answer 2

Prima di ottenere The Data Warehouse Toolkit prima di fare qualsiasi cosa.

Stai facendo un lavoro di data warehousing, devi affrontarlo come un lavoro di data warehousing. Avrai bisogno di leggere gli schemi di progettazione corretti per questo genere di cose.

[Nota Data Warehouse non significa pazzo grande o costoso o complesso. 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. È una cosa terribile per l'aggiornamento, ma non stai aggiornando, stai solo accumulando.

Un approccio DW tipico per questo è quello di fare questo.

1. Definire lo "Schema a stella" per i dati. I fatti misurabili e gli attributi ("dimensioni") di questi fatti. Il tuo fatto sembra essere # di byte. Tutto il resto (indirizzo, timestamp, ID utente, ecc.) È una dimensione di questo fatto.

2. Costruire i dati dimensionali in un database di dimensione principale. È relativamente piccolo (indirizzi IP, utenti, una dimensione data, ecc.) Ogni dimensione avrà tutti gli attributi che potresti voler sapere. Questo cresce, le persone aggiungono sempre attributi alle dimensioni.

3. Creare un processo di "caricamento" che prende i registri, risolve le dimensioni (tempi, indirizzi, utenti, ecc.) E unisce le chiavi di dimensione con le misure (# di byte). Questo può aggiornare la dimensione per aggiungere un nuovo utente o un nuovo indirizzo. In generale, stai leggendo righe di fatti, facendo ricerche e scrivendo righe di fatto che hanno tutte le FK corrette associate a loro.

4. Salvare questi file di caricamento sul disco. Questi file non sono aggiornati. Si accumulano. Utilizza una notazione semplice, come CSV, in modo da poterli caricare facilmente in blocco.

Quando qualcuno vuole fare analisi, costruiscile un datamart.

Per l'indirizzo IP o l'intervallo di tempo selezionato o qualsiasi altra cosa, ottenere tutti i fatti rilevanti, oltre ai dati della dimensione master associati e il caricamento di massa di un datamart.

È possibile eseguire tutte le query SQL desiderate su questo mart. La maggior parte delle domande verrà devoluta a SELECT COUNT(*) e SELECT SUM(*) con varie clausole GROUP BY e HAVING e WHERE.

Answer 3

Quindi sei in uno dei casi in cui hai molto più attività di lettura che leggere, vuoi che le tue scritture non ti blocchino e vuoi che le tue letture siano "ragionevolmente veloci" ma non critiche. È un tipico caso d'uso della business intelligence.

È consigliabile utilizzare un database e archiviare i dati come schema "denormalizzato" per evitare join complessi e inserimenti multipli per ciascun record. Pensa al tuo tavolo come a un enorme file di registro.

In questo caso, alcuni dei "nuovi e fantasiosi" database NoSQL sono probabilmente quello che stai cercando: forniscono vincoli ACID rilassati, che non dovresti preoccuparti di nulla (in caso di crash, puoi perdere ultime righe del tuo log), ma funzionano molto meglio per l'inserimento, perché non devono sincronizzare i periodici su disco in ogni transazione.