Speichern von Millionen von Protokolldateien - ca. 25 TB pro Jahr

Question

Als Teil meiner Arbeit erhalten wir ca. 25TB wert Protokolldateien pro Jahr, derzeit wurde es über ein NFS-basiertes Dateisystem gespeichert. Einige werden wie in zip/tar.gz archiviert, während andere im reinen Textformat vorliegen.

Ich bin auf der Suche nach Alternativen für die Verwendung eines NFS-basierten Systems. Ich schaute auf MongoDB, CouchDB. Die Tatsache, dass es sich um eine dokumentenorientierte Datenbank handelt, scheint die richtige Lösung zu sein. Der Inhalt der Protokolldateien muss jedoch in JSON geändert werden, damit er in der Datenbank gespeichert werden kann. Etwas, zu dem ich nicht bereit bin. Ich muss den Inhalt der Protokolldateien unverändert lassen.

Wie für die Verwendung beabsichtigen wir, eine kleine REST-API zu setzen und ermöglichen Menschen, Datei-Liste, neueste Dateien und die Fähigkeit, die Datei zu erhalten.

Die vorgeschlagenen Lösungen/Ideen müssen eine Form von verteilter Datenbank oder Dateisystem auf Anwendungsebene sein, wo man Protokolldateien speichern und horizontal durch Hinzufügen weiterer Maschinen skalieren kann.

Ankur

Answer 1

Werfen Sie einen Blick auf Vertica, eine säule Datenbank Parallelverarbeitung und schnelle Abfragen unterstützen. Comcast nutzte es für analyze about 15GB/day of SNMP data, mit einer durchschnittlichen Rate von 46.000 Samples pro Sekunde und fünf HP Proliant-Vierkernservern. Ich habe einige Comcast-Betriebe gehört, die vor ein paar Wochen über Vertica schwärmten; sie mögen es immer noch sehr. Es hat einige nette Datenkompressionstechniken und "K-Sicherheitsredundanz", so dass sie auf ein SAN verzichten konnten.

Update: Einer der Hauptvorteile eines skalierbaren Analyse-Datenbank-Ansatzes besteht darin, dass Sie einige ziemlich anspruchsvolle, quasi-Echtzeit Abfragen des Protokolls durchführen können. Dies könnte für Ihr Einsatzteam wirklich wertvoll sein.

Answer 2

Da keine Funktionen abgefragt werden sollen, können Sie apache hadoop verwenden.

Ich glaube, HDFS und HBase wird gut dafür geeignet sein.

Sie können powered by viele große Speicher Geschichten innerhalb Hadoop Seite

Answer 3

Haben Sie versucht, Blick auf Gluster sehen? Es ist skalierbar, bietet Replikation und viele andere Funktionen. Außerdem erhalten Sie Standard-Dateioperationen, sodass Sie keine weitere API-Schicht implementieren müssen.

http://www.gluster.org/

Answer 4

Ich würde disrecommend nachdrücklich empfohlen, einen Schlüssel/Wert oder dokumentenbasierten Speicher für diese Daten unter Verwendung von (Mongo, cassandra, etc.). Verwenden Sie ein Dateisystem. Dies liegt daran, dass die Dateien so groß sind und das Zugriffsmuster linear gescannt wird. Ein Problem, auf das Sie stoßen werden, ist die Retention. Die meisten "NoSQL" -Speichersysteme verwenden logisches Löschen, was bedeutet, dass Sie Ihre Datenbank komprimieren müssen, um gelöschte Zeilen zu entfernen. Sie haben auch ein Problem, wenn Ihre einzelnen Protokolldatensätze klein sind und Sie jeden einzelnen Index indexieren müssen - Ihr Index wird sehr groß sein.

Setzen Sie Ihre Daten in HDFS mit 2-3-Wege-Replikation in 64 MB Chunks im gleichen Format, in dem es jetzt ist.

Answer 5

Wenn Sie ein Dokument Datenbank wählen:

auf CouchDB Sie den _attachement API verwenden können, um die Datei zu befestigen, wie auf ein Dokument ist, das Dokument selbst nur Metadaten (wie Zeitstempel, Ort und usw.) enthalten könnte für die Indexierung. Dann haben Sie eine REST-API für die Dokumente und Anhänge.

Ein ähnlicher Ansatz ist mit Mongos GridFs möglich, aber Sie würden die API selbst erstellen.

Auch HDFS ist eine sehr gute Wahl.