Memorizzazione di milioni di file di registro - Circa 25 TB all'anno

Question

Come parte del mio lavoro otteniamo circa 25 TB di file di registro all'anno, attualmente è stato salvato su un file system basato su NFS. Alcuni sono archiviati come in zip/tar.gz mentre altri risiedono in formato di puro testo.

Sto cercando alternative all'utilizzo di un sistema basato su NFS. Ho guardato MongoDB, CouchDB. Il fatto che si tratti di un database orientato ai documenti sembra adattarlo correttamente. Tuttavia, il contenuto dei file di registro deve essere modificato in JSON per essere memorizzato nel DB. Qualcosa che non sono disposto a fare. Ho bisogno di mantenere il contenuto dei file di registro così com'è.

Per quanto riguarda l'utilizzo, intendiamo inserire una piccola API REST e consentire alle persone di ottenere l'elenco dei file, i file più recenti e la possibilità di ottenere il file.

Le soluzioni/idee proposte devono essere una forma di database distribuito o di file system a livello di applicazione in cui è possibile memorizzare file di registro e scalare in modo efficace in orizzontale aggiungendo più macchine.

Ankur

Answer 1

Date un'occhiata a Vertica, un database a colonne di supporto di elaborazione parallela e le query veloci. Comcast lo ha utilizzato su analyze about 15GB/day of SNMP data, con una frequenza media di 46.000 campioni al secondo, utilizzando cinque server HP Proliant quad core. Ho sentito alcune operazioni di Comcast persone entusiaste di Vertica poche settimane fa; a loro piace davvero. Ha alcune buone tecniche di compressione dei dati e "k-safety ridondanza", quindi potrebbero fare a meno di una SAN.

Aggiornamento: uno dei principali vantaggi di un approccio di database analitico scalabile è che è possibile eseguire query di registro piuttosto sofisticate e quasi in tempo reale. Questo potrebbe essere davvero prezioso per il tuo team operativo.

Answer 2

Poiché non si desidera eseguire le funzioni di interrogazione, è possibile utilizzare apache hadoop.

I belive HDFS e HBase saranno adatti per questo.

Potete vedere molte storie di storage enormi all'interno Hadoop powered by pagina

Answer 3

Hai provato guardando Gluster? È scalabile, fornisce la replica e molte altre funzionalità. Offre anche operazioni di file standard, quindi non è necessario implementare un altro livello API.

http://www.gluster.org/

Answer 4

caldamente disrecommend utilizzando una chiave/valore o negozio basato documento per questi dati (mongo, Cassandra, etc.). Usa un file system. Questo perché i file sono così grandi, e il modello di accesso sta per essere scansione lineare. Una delle problematiche che incontrerai è la conservazione. La maggior parte dei sistemi di archiviazione "NoSQL" utilizza l'eliminazione logica, il che significa che è necessario compattare il database per rimuovere le righe eliminate. Avrai anche un problema se i tuoi singoli record di log sono piccoli e devi indicizzarne ognuno di essi - il tuo indice sarà molto grande.

Inserisci i dati in HDFS con replica a 2-3 vie in blocchi da 64 MB nello stesso formato in cui si trova ora.

Answer 5

Se si è di scegliere un database di documenti:

Su CouchDB è possibile utilizzare l'API _attachement di allegare il file come è quello di un documento, il documento stesso poteva contenere solo i metadati (come timestamp, località e ecc) per l'indicizzazione. Quindi avrai un'API REST per i documenti e gli allegati.

Un approccio simile è possibile con i GridF di Mongo, ma è possibile creare l'API autonomamente.

Anche HDFS è una scelta molto bella.