Welche NoSQL-Lösung ist am besten, um Apache error_log und access_log zu speichern? Kassandra oder MongoDB?

Question

Wir haben PaaS-Lösung für PHP entwickelt. Als Teil davon bieten wir Entwicklern an Apache error_log und access_log Dateien über unsere API zu sehen.

Momentan schreiben wir die Protokolle in Dateien auf der Platte, die pro Deployment getrennt sind (vhost).

Da dies mit einer höheren Anzahl von Knoten und Bereitstellungen nicht so gut skaliert wird, obwohl Dateien auf einem verteilten Dateisystem (GlusterFS) liegen, würden wir gerne zu etwas Besserem wechseln.

Insbesondere aus Abrechnungsgründen und aus statistischen Gründen würden wir es vorziehen, die Protokolldateien nicht jedes Mal zu analysieren.

Da die kopierten Sammlungen von MongoDB hervorragend für die Protokollierung sind, wollten wir damit fortfahren. Aber es stellt sich heraus, dass sie nicht mit Auto-Sharding funktionieren, was den Punkt für uns verdirbt, da wir viel mehr Schreibvorgänge erwarten als gelesen.

Die andere Option war Cassandra, die ich mag für jeden Knoten ist gleich Ansatz, aber sie haben nicht so etwas wie capped Sammlungen.

Es stellt sich heraus, dass keine der beiden Lösungen ein bestimmtes Merkmal bietet, das mir hilft, eine Entscheidung zu treffen, oder ich sehe es nicht.

Also was ich wissen möchte ist, hat jemand eines der beiden Systeme für die Protokollierung verwendet, bevor? Was sind deine Erfahrungen, kannst du mir ein paar Tipps geben? Oder gibt es andere Lösungen, die unseren Bedürfnissen besser entsprechen?

Answer 1

Sie können diesen Artikel von Cloudkick überprüfen, wenn Sie in Betracht ziehen, Cassandra: 4 Months with Cassandra, a love story zu verwenden.

Sie verwenden Cassandra, um verschiedene Metriken für ihr System zu speichern, das dem Speichern von Protokolldateien ähnelt.

EDIT:

Wenn Sie noch nicht entschieden haben, was zu verwenden, hier ist eine große Lösung MongoDB als Backend verwendet:

Graylog2 ist eine Open-Source-syslog-Implementierung, die speichert Ihre meldet MongoDB an. Es besteht aus einem in Java geschriebenen Server, der Ihre Syslog-Nachrichten über TCP oder UDP akzeptiert und in der Datenbank speichert. Der zweite Teil ist eine Weboberfläche von Ruby on Rails, mit der Sie die Protokollnachrichten anzeigen können.

Answer 2

Stellt sich keine der beiden Lösungen aus bietet ein besonderes Merkmal, das mir eine Entscheidung treffen hilft, oder ich sehe es nicht.

Ehrlich gesagt, wir gehen gerade durch diesen Test mit einigen ernsthaften Protokolldaten. (Und im Moment, ich meine, einige von uns waren letzte Nacht spät dran, als sie diese Tests durchführten).

Für mich, hier sind die beiden Unterscheidungsmerkmale: einfache Bedienung und bewährten Skalierung.

Einfache Bedienung

• MongoDB war einfach. In ein paar Stunden ging ich von einem leeren Computer zu einer aktiven Mongo-Instanz mit importierten Daten aus MySQL und ein paar fertige Map-Reduces.
• Im gleichen Zeitraum saß das Team Cassandra um das erneute Kompilieren von Java-Dateien, um Hadoop für die Ausführung über eine vorhandene Cassandra-Implementierung zu konfigurieren, sodass sie sogar Kartenreduzierungen ausführen konnten.

Bewährte

• MongoDB sharding Skalierung ist noch in der Beta. Es ist für den Start in den nächsten Wochen geplant. Das ist ziemlich eng.
• Cassandra sharding hat sich in einigen sehr großen Fällen bewährt.

Also ich denke, die Antwort wird wirklich auf Ihren persönlichen Geschmack spezifisch sein. Ich glaube wirklich, dass Cassandra ein stabileres Produkt ist, aber ich weiß auch aus Erfahrung, dass die Lern- und Setup-Kurve viel steiler ist. Also könnte es sich lohnen, ein bisschen von beidem zu versuchen.