MongoDB als Dateispeicher

Question

Ich versuche die beste Lösung zu finden, um skalierbaren Speicher für große Dateien zu erstellen. Die Dateigröße kann zwischen 1 und 2 Megabyte und bis zu 500 bis 600 Gigabyte variieren.

Ich habe ein paar Informationen über Hadoop und sein HDFS gefunden, aber es sieht ein bisschen kompliziert aus, weil ich keine Map/Reduce-Jobs und viele andere Funktionen brauche. Jetzt denke ich, MongoDB und sein GridFS als Dateispeicherlösung zu verwenden.

Und nun die Fragen:

1. Was mit gridfs passieren wird, wenn ich versuche, einige Dateien zu schreiben gleichzeitig. Wird es eine Sperre für Lese-/Schreiboperationen geben? (Ich werde es nur als Dateispeicher verwenden)
2. Werden Dateien aus Gridfs im RAM zwischengespeichert und wie wirkt sich dies auf die Lese-Schreib-Performance aus?
3. Vielleicht gibt es andere Lösungen, die mein Problem effizienter lösen können?

Danke.

Answer 1

Ich kann hier nur für MongoDB antworten, ich werde nicht so tun, als ob ich viel über HDFS und andere solche Technologien weiß.

Die GridFs-Implementierung ist vollständig clientseitig innerhalb des Treibers selbst. Dies bedeutet, dass es keinen speziellen Ladevorgang oder Verständnis für den Kontext der Dateibereitstellung in MongoDB selbst gibt. MongoDB selbst versteht nicht einmal, dass es sich um Dateien handelt (http://docs.mongodb.org/manual/applications/gridfs/).

Dies bedeutet, dass für jeden Teil der files oder chunks Sammlung Abfrage im gleichen Prozess führen wird, wie es wäre für jede andere Abfrage, wobei sie die Daten laden es Ihren Arbeitssatz muss in (http://en.wikipedia.org/wiki/Working_set), die zur Herstellung einen Satz darstellt Daten (oder alle zu diesem Zeitpunkt geladenen Daten), die von MongoDB innerhalb eines bestimmten Zeitrahmens benötigt werden, um eine optimale Leistung zu gewährleisten. Dazu wird es in den Arbeitsspeicher gepuffert (technisch gesehen ist es das Betriebssystem).

Ein weiterer zu berücksichtigender Punkt ist, dass dieser Treiber implementiert ist. Dies bedeutet, dass die Spezifikation variieren kann, ich glaube jedoch nicht. Mit allen Treibern können Sie eine Reihe von Dokumenten aus der files Sammlung abfragen, in der nur die Metadaten der Dateien gespeichert sind, so dass Sie die Datei selbst später aus der Sammlung chunks mit einer einzigen Abfrage bedienen können.

Das ist jedoch nicht das Wichtigste, Sie möchten die Datei selbst einschließlich ihrer Daten bereitstellen; Dies bedeutet, dass Sie die files Sammlung und ihre nachfolgende chunks Sammlung in Ihr Arbeitssatz laden werden.

Vor diesem Hintergrund haben wir treffen bereits die ersten Haken:

Werden Dateien aus gridfs im RAM zwischengespeichert werden und wie es Lese-Schreib-perfomance beeinflussen?

Die Leseleistung von kleinen Dateien könnte super sein, direkt aus dem RAM; die Schreibarbeiten wären genauso gut.

Für größere Dateien, nicht so. Die meisten Computer verfügen nicht über 600 GB RAM, und es ist wahrscheinlich ganz normal, eine 600-GB-Partition einer einzelnen Datei auf einer einzelnen mongod-Instanz unterzubringen. Dies erzeugt ein Problem, da diese Datei, um bedient zu werden, in Ihre Arbeitsumgebung passen muss, jedoch viel größer als Ihr Arbeitsspeicher ist. An dieser Stelle könnten Sie eine Seitenumleitung haben (http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29), wobei der Server nur 24/7 versucht, die Datei zu laden. Die Schreibarbeiten hier sind auch nicht besser.

Der einzige Weg um dies zu starten ist es, eine einzelne Datei über viele Shards :\ zu setzen.

Hinweis: eine weitere Sache zu berücksichtigen ist, dass die Standardgröße von chunks "Chunk" 256KB ist, so dass eine Menge Dokumente für eine 600GB-Datei ist. Diese Einstellung ist in den meisten Treibern manipulierbar.

Was passiert mit gridfs, wenn ich versuche, einige Dateien gleichzeitig zu schreiben. Wird es eine Sperre für Lese-/Schreiboperationen geben? (Ich werde sie verwenden nur als Dateispeicher)

GridFS, wobei nur eine Spezifikation verwendet die gleichen Schlösser wie auf jede andere Sammlung, sowohl Lese- als auch Schreibsperren auf Datenbankebene (2.2+) oder auf globaler Ebene (vor 2.2). Die beiden stören sich auch gegenseitig, d. H. Wie können Sie ein konsistentes Lesen eines Dokuments sicherstellen, in das geschrieben wird?

Das besagt, dass die Möglichkeit für Konflikte besteht auf der Grundlage Ihrer Szenario-Details, Verkehr, Anzahl der gleichzeitigen Schreib/Lese-und viele andere Dinge, über die wir keine Ahnung haben.

Vielleicht gibt es andere Lösungen, die mein Problem effizienter lösen können?

Ich persönlich habe festgestellt, dass S3 (wie @mluggy gesagt) in reduzierter Redundanz-Format eignet sich am besten ein bloßer Teil von Metadaten über die Datei innerhalb von MongoDB speichern, ähnlich wie GridFS verwenden, aber ohne die Sammlung Stücke, lassen S3 Griff all diese Distribution, Backup und andere Sachen für dich.

Hoffentlich war ich klar, hoffe es hilft.

Edit: Im Gegensatz zu dem, was ich versehentlich sagte, hat MongoDB keine Sperre auf Sammelebene, es ist eine Sperre auf Datenbankebene.

Answer 2

Ich werde durch die Beantwortung der ersten beiden starten:

1. Es gibt eine Schreibsperre ist, wenn sie in zu GridFS schreiben, ja. Keine Sperre für Lesevorgänge.
2. Die Dateien werden nicht im Speicher zwischengespeichert, wenn Sie sie abfragen, sondern ihre Metadaten.

GridFS ist möglicherweise nicht die beste Lösung für Ihr Problem. Schreibsperren können bei solchen Situationen zu einer Belastung werden, insbesondere bei großen Dateien. Es gibt andere Datenbanken, die dieses Problem für Sie lösen können. HDFS ist eine gute Wahl, aber wie Sie sagen, ist es sehr kompliziert. Ich würde empfehlen, einen Speichermechanismus wie Riak oder Amazon S3 zu betrachten. Sie sind mehr darauf ausgerichtet, Speicher für Dateien zu sein, und haben keine großen Nachteile. S3 und Riak haben beide ausgezeichnete Administrationsmöglichkeiten und können große Dateien verarbeiten. Aber mit Riak, das letzte Mal, das ich wusste, musste man einige Dateien chunken, um Dateien über 100 MB zu speichern. Trotzdem ist es im Allgemeinen eine bewährte Methode, bei großen Dateigrößen ein gewisses Maß an Chunking durchzuführen. Es gibt eine Menge schlechter Dinge, die passieren können, wenn Dateien in DBs übertragen werden - von Netzwerk-Timeouts zu Pufferüberläufen, etc. In beiden Fällen wird Ihre Lösung eine Menge Tuning für große Dateigrößen erfordern.

Answer 3

Haben Sie überlegt, Metadaten auf MongoDB zu speichern und tatsächliche Dateien in Amazon S3 zu schreiben? Beide haben ausgezeichnete Treiber und letzterer ist hoch redundant, cloud-/cdn-fähiger Dateispeicher. Ich würde es versuchen.