Hadoop als Dokumentspeicher-Datenbank

Hadoop ist mehr für die Batch-Verarbeitung als für den hohen Datenzugriff. Sie sollten sich einige NoSQL-Systeme wie dokumentenorientierte Datenbanken ansehen. Schwer zu beantworten, ohne zu wissen, wie Ihre Daten sind.

Die wichtigste Regel für das NoSQL-Design besteht darin, zuerst Ihre Abfrageszenarien zu definieren. Sobald Sie wirklich verstanden haben, wie Sie die Daten abfragen wollen, können Sie sich die verschiedenen NoSQL-Lösungen ansehen. Die Standardeinheit der Verteilung ist der Schlüssel. Daher müssen Sie daran denken, dass Sie in der Lage sein müssen, Ihre Daten effektiv zwischen Ihren Knotenmaschinen aufzuteilen, ansonsten erhalten Sie ein horizontal skalierbares System mit allen Arbeiten, die noch an einem Knoten erledigt werden (wenn auch bessere Abfragen je nach Fall).

Sie müssen auch an das CAP-Theorem denken, die meisten NoSQL-Datenbanken sind schließlich konsistent (CP oder AP), während traditionelle relationale DBMS CA sind. Dies wirkt sich auf die Art und Weise aus, wie Sie mit Daten umgehen und bestimmte Dinge erstellen, zum Beispiel kann die Schlüsselgenerierung Trickserei sein. Offensichtlich sind Dateien in einem Ordner ein bisschen anders.

Denken Sie auch daran, dass es in einigen Systemen wie HBase kein Indizierungskonzept gibt (ich bin sicher, dass Sie in diesem Windows FS-Dokumentspeicher ein Setup für die Dateiindizierung haben). Alle Ihre Indizes müssen von Ihrer Anwendungslogik erstellt werden, und alle Aktualisierungen und Löschungen müssen als solche verwaltet werden. Mit Mongo können Sie Indizes für Felder erstellen und diese relativ schnell abfragen. Es besteht auch die Möglichkeit, Solr mit Mongo zu integrieren. Sie müssen nicht nur in Mongo nach ID suchen, wie in HBase, einer Spaltenfamilie (auch Google BigTable-Stil-Datenbank genannt), in der Sie im Wesentlichen verschachtelte Schlüssel / Wert-Paare haben.

Es kommt also wieder einmal zu Ihren Daten, was Sie speichern möchten, wie Sie es speichern und vor allem wie Sie darauf zugreifen wollen. Das Lily-Projekt sieht sehr vielversprechend aus. Die Arbeit, an der ich beteiligt bin, nehmen wir eine große Menge von Daten aus dem Web und wir speichern es, analysieren es, strippen es aus, parsen es, analysieren es, streamen es, aktualisieren es usw. usw. Wir benutzen nicht nur ein System, sondern viele welche für die jeweilige Aufgabe am besten geeignet sind. Für diesen Prozess verwenden wir verschiedene Systeme in verschiedenen Phasen, da wir dort schnell zugreifen können, wo wir sie brauchen. Wir können Daten in Echtzeit streamen und analysieren und dabei alles im Blick behalten (als Datenverlust in einem Produkt) System ist eine große Sache). Ich benutze Hadoop, HBase, Hive, MongoDB, Solr, MySQL und sogar gute alte Textdateien. Denken Sie daran, dass es ein bisschen schwieriger ist, ein System mit diesen Technologien zu erstellen, als Oracle auf einem Server zu installieren, einige Versionen sind nicht so stabil und Sie müssen Ihre Tests wirklich erst durchführen. Am Ende des Tages hängt es wirklich vom Niveau der Geschäftsresistenz und der Missionskritischen Natur Ihres Systems ab.

Ein anderer Weg, den niemand bisher erwähnt hat, ist NewSQL - dh horizontal skalierbare RDBMS ... Es gibt ein paar da draußen, wie MySQL Cluster (glaube ich) und VoltDB, die für Ihre Sache geeignet sind. Aber wieder abhängig von Ihren Daten ( sind die Dateien Word Docs oder Textdokumente mit Informationen über Produkte, Rechnungen oder Instrumente oder etwas) ...

Wiederum kommt es zum Verständnis Ihrer Daten und der Zugriffsmuster, NoSQL-Systeme sind auch Non-Rel, d. h. nicht relational und sind für eine bessere Anpassung an nicht-relationale Datensätze. Wenn Ihre Daten inhärent relational sind und Sie einige SQL-Abfrage-Features benötigen, die wirklich Dinge wie kartesische Produkte (auch bekannt als Joins) tun müssen, dann sollten Sie lieber bei Oracle bleiben und etwas Zeit in Indizierung, Sharding und Performance-Tuning investieren. p>

Mein Rat wäre, tatsächlich mit ein paar verschiedenen Systemen herumzuspielen. Schau dir an;

MongoDB - Dokument - CP

CouchDB - Dokument - AP

Cassandra - Spaltenfamilie - Verfügbar & amp; Partitionstolerant (AP)

VoltDB - Ein wirklich gut aussehendes Produkt, eine relationale Datenbank, die verteilt wird und für Ihren Fall funktionieren könnte (ist vielleicht einfacher). Sie scheinen auch die Unterstützung von Unternehmen zu bieten, die für ein Produkt besser geeignet ist (d. H. Geschäftsanwendern ein Gefühl der Sicherheit geben).

Irgendwie ist das mein 2c. Das Herumspielen mit den Systemen ist wirklich die einzige Möglichkeit, herauszufinden, was wirklich für Ihren Fall funktioniert.

HDFS klingt nicht nach der richtigen Lösung. Es ist optimiert für eine massive paralelle Verarbeitung der Daten und nicht als Dateisystem für allgemeine Zwecke. Insbesondere hat es folgende Einschränkungen, die es wahrscheinlich schlechte Wahl machen:
a) Es ist empfindlich für die Anzahl der Dateien. Die praktische Grenze sollte bei Dutzenden von Millionen Dateien liegen.
b) Die Dateien sind schreibgeschützt und können nur angehängt, aber nicht bearbeitet werden. Es ist in Ordnung für analytische Datenverarbeitung, aber möglicherweise nicht Ihren Bedarf.
c) Es hat Single Point of Failure - Namenknoten. Daher ist seine Zuverlässigkeit begrenzt.

Wenn Sie ein System mit vergleichbarer Skalierbarkeit benötigen, aber nicht empfindlich auf die Anzahl der Dateien reagieren, würde ich Ihnen OpenStack's Swift empfehlen. Es hat auch kein SPOF.

Mein Vorschlag ist, dass Sie einen NAS-Speicher kaufen können. Kann EMS isilon Art des Produktes sein, das Sie betrachten können.

Hadoop HDFS ist nicht zum Speichern von Dateien vorgesehen. Es ist Speicher für die Verarbeitung der Daten (für Berichte, Analysen ..)

NAS ist für die Dateifreigabe

SAN ist mehr für eine Datenbank

Ссылка

Erklärung: Ich bin keine EMC-Person, daher können Sie jedes Produkt in Betracht ziehen. Ich habe nur EMC als Referenz verwendet.