MongoDB, Cassandra und HBase - die drei zu beobachtenden NoSQL-Datenbanken

Hadoop erhält einen Großteil des Big-Data-Guthabens, aber die Realität ist, dass NoSQL-Datenbanken viel breiter eingesetzt - und viel breiter entwickelt werden. Während das Einkaufen für einen Hadoop-Anbieter relativ einfach ist, ist die Auswahl einer NoSQL-Datenbank alles andere als einfach. Immerhin gibt es mehr als 100 NoSQL-Datenbanken, wie das Beliebtheitsranking der DB-Engines-Datenbank zeigt.

Welches solltest du wählen?

Die Qual der Wahl

Weil du wählen musst. So schön es auch sein mag, in einer glücklichen Utopie der sogenannten polyglotten Persistenz zu leben, „in der jedes Unternehmen mit angemessener Größe über eine Vielzahl unterschiedlicher Datenspeichertechnologien für verschiedene Arten von Daten verfügt“, wie Martin Fowler argumentiert, ist die Realität Sie können es sich nicht leisten, mehr als nur ein paar in das Lernen zu investieren.

Glücklicherweise wird die Auswahl immer einfacher, da sich der Markt um drei dominante NoSQL-Datenbanken zusammenschließt: MongoDB (unterstützt von meinem früheren Arbeitgeber), Cassandra (hauptsächlich von DataStax entwickelt, obwohl bei Facebook ausgebrütet) und HBase (eng mit Hadoop abgestimmt und von der gleiche Gemeinschaft).

Beachten Sie, dass ich Redis absichtlich von dieser Liste ausschließe. Obwohl es sich um einen großartigen Datenspeicher handelt, wird er hauptsächlich zum Zwischenspeichern von Daten verwendet und eignet sich nicht für eine Vielzahl von Workloads.

LinkedIn-Daten von 451 Research zeigen, wie sich der Markt für MongoDB, Cassandra und HBase interessiert:

Das sind LinkedIn-Profildaten. Eine vollständigere Ansicht ist die von DB-Engines, in der Jobs, Suchanfragen und andere Daten zusammengefasst werden, um die Popularität der Datenbank zu verstehen. Während Oracle, SQL Server und MySQL an oberster Stelle stehen, geben MongoDB (Nr. 5), Cassandra (Nr. 9) und HBase (Nr. 15) ihnen einen Lauf um ihr Geld.

Obwohl es noch zu früh ist, jede andere NoSQL-Datenbank als Rundungsfehler zu bezeichnen, erreichen wir diesen Punkt schnell, genau wie dies auf dem Markt für relationale Datenbanken geschehen ist.

Um besser zu verstehen, warum diese drei Datenbanken glänzen, bat ich Vertreter von jedem, Schlüsselattribute für ihren Erfolg zu identifizieren: Kelly Stirman, Produktdirektorin bei MongoDB; Patrick McFadin, Chef-Evangelist von Cassandra bei DataStax; und Justin Kestelyn, Senior Director für Entwicklerbeziehungen bei Cloudera.

Aber zuerst müssen wir verstehen, warum NoSQL wichtig ist.

Eine Welt mit unstrukturierten Daten

Wir leben zunehmend in einer Welt, in der Daten nicht gut in die ordentlichen Zeilen und Spalten eines RDBMS passen. Mobile, Social und Cloud Computing haben eine massive Datenflut ausgelöst. Nach verschiedenen Schätzungen wurden in den letzten zwei Jahren 90 Prozent der weltweiten Daten erstellt, wobei Gartner 80 Prozent aller Unternehmensdaten als unstrukturiert ansah. Darüber hinaus wachsen unstrukturierte Daten doppelt so schnell wie strukturierte Daten.

Da sich die Welt verändert, gehen die Anforderungen an das Datenmanagement über den effektiven Umfang herkömmlicher relationaler Datenbanken hinaus. Die ersten Organisationen, die den Bedarf an alternativen Lösungen erkannten, waren Webpioniere, Regierungsbehörden und Unternehmen, die sich auf Informationsdienste spezialisiert haben.

Unternehmen aller Art versuchen zunehmend, den Vorteil von Alternativen wie NoSQL und Hadoop zu nutzen: NoSQL, um betriebliche Anwendungen zu erstellen, die ihr Geschäft durch Engagement-Systeme steuern, und Hadoop, um Anwendungen zu erstellen, die ihre Daten nachträglich analysieren und leistungsstarke Erkenntnisse liefern .

MongoDB: Von den Entwicklern für die Entwickler

Unter den NoSQL-Optionen hat MongoDB laut Stirman von MongoDB einen ausgewogenen Ansatz angestrebt, der für eine Vielzahl von Anwendungen geeignet ist. Während die Funktionalität der einer herkömmlichen relationalen Datenbank nahe kommt, können Benutzer mit MongoDB die Vorteile der Cloud-Infrastruktur mit ihrer horizontalen Skalierbarkeit nutzen und dank ihres flexiblen Datenmodells problemlos mit den verschiedenen heute verwendeten Datensätzen arbeiten.

MongoDB ist oft das erste Mal, dass NoSQL-Datenbankentwickler es versuchen, weil es so einfach zu erlernen ist. Will Shulman, CEO von MongoLab (einem MongoDB-as-a-Service-Anbieter), sagt dies folgendermaßen:

Der unverhältnismäßige Erfolg von MongoDB beruht größtenteils auf seiner Innovation als Datenstrukturspeicher, mit dem wir die "Dinge", die das Herzstück unserer Anwendungen bilden, einfacher und ausdrucksvoller modellieren können.

Das gleiche grundlegende Datenmodell in unserem Code und in der Datenbank zu haben, ist für die meisten Anwendungsfälle die überlegene Methode, da es die Aufgabe der Anwendungsentwicklung erheblich vereinfacht und die Schichten komplexen Mapping-Codes eliminiert, die ansonsten erforderlich sind.

Insbesondere ist MongoDB wie die anderen Datenbanken auf dieser Liste kein One-Trick-Pony. Unternehmen, die MongoDB kennenlernen, "können ihre Investitionen in MongoDB über viele, viele Projekte hinweg amortisieren, was es zu einer kurzen Liste von Standards macht, auf die sie sich für das gesamte Datenmanagement verlassen", wie Stirman mir sagte.

Natürlich hat MongoDB wie jede Technologie seine Stärken und Schwächen. MongoDB wurde für OLTP-Workloads entwickelt. Es kann komplexe Abfragen ausführen, ist jedoch nicht unbedingt die beste Lösung für Workloads im Berichtsstil. Oder wenn Sie komplexe Transaktionen benötigen, ist dies keine gute Wahl. Die Einfachheit von MongoDB macht es jedoch zu einem großartigen Ausgangspunkt.

Cassandra: Sicher im Maßstab laufen

Es gibt mindestens zwei Arten von Datenbank-Einfachheit: Entwicklungs-Einfachheit und Bedienungs-Einfachheit. Während MongoDB zu Recht Anerkennung für ein einfaches Out-of-the-Box-Erlebnis erhält, erhält Cassandra die volle Punktzahl für die einfache Verwaltung in großem Maßstab.

Wie mir McFadin von DataStax sagte, tendieren Benutzer dazu, sich für Cassandra zu interessieren, je mehr sie sich gegen die Schwierigkeit wehren, relationale Datenbanken schneller und zuverlässiger zu machen, insbesondere im Maßstab. McFadin, ein ehemaliger Oracle-DBA, war hocherfreut zu entdecken, dass „Replikation und lineare Skalierung bei Cassandra Grundelemente sind“ und die Funktionen „von Anfang an das primäre Entwurfsziel“ waren.

In der RDBMS-Welt sind Datenbankfunktionen wie Skalierung und Replikation die schwierigen Teile, die dem Benutzer überlassen bleiben. Dies funktionierte im gestrigen Unternehmen gut, als die Skalierung kein großes Problem war. Heute ist es immer schnell das Thema.

Wie ich von McFadin und anderen gehört habe, glänzt Cassandra besonders bei Scale-Out-Bereitstellungen. Cassandra bietet integrierte Unterstützung für mehrere Rechenzentren. Zum Hinzufügen von Kapazität zu einem Cluster: "Sie starten einfach einen neuen Computer und teilen Cassandra mit, wo sich die anderen Knoten befinden", sagte McFadin. "Der Rest wird erledigt."

Diese einfache Skalierung in Verbindung mit einer außergewöhnlichen Schreibleistung („Alles, was Sie tun, ist an das Ende einer Protokolldatei anzuhängen“) und einer vorhersehbaren Abfrageleistung führen zu einem leistungsstarken Arbeitstier in Cassandra.

Ein Artikel des NoSQL-Glaubens, den ich seit langem vertreten habe, ist, dass Cassandra zwar in großem Maßstab mächtig ist, aber für den Einstieg eine Promotion erforderlich ist. Nicht so, bestand McFadin darauf:

Die Replikations- und Lese- und Schreibpfade sind absichtlich einfach. Sie können die wichtigsten Interna von Cassandra in wenigen Stunden lernen. Dies kann beim Einsatz neuer Technologien viel Vertrauen schaffen, da weniger „Black-Box“ -Details komplexe Fehlermodi einführen.

Dies bedeutet, dass der Preis für die Zulassung zur effektiven Cassandra-Entwicklung darin besteht, das Datenmodell und dessen Funktionsweise mit Ihrer Anwendung zu verstehen. Angesichts der Vertrautheit mit Cassandras CQL-Abfragesprache (die genau wie SQL sein soll, außer wenn dies nicht der Fall ist), ist es laut McFadin keine steile Lernkurve.

Wichtiger noch, sagte er zu mir: „Cassandra belohnt Sie mit dem, was Sie von einer Datenbank erwarten: kein Drama. Aus diesem Grund verwenden Benutzer Cassandra gerne. “

HBase: Busenfreunde mit Hadoop

HBase wird wie Cassandra, ein spaltenorientierter Schlüsselwertspeicher, zum großen Teil aufgrund seiner gemeinsamen Abstammung mit Hadoop häufig verwendet. In der Tat, wie Kestelyn von Cloudera es ausdrückte, "bietet HBase eine auf Datensätzen basierende Speicherschicht, die schnelle, zufällige Lese- und Schreibvorgänge in Daten ermöglicht und Hadoop ergänzt, indem ein hoher Durchsatz auf Kosten von E / A mit geringer Latenz betont wird."

Kestelyn fährt fort:

Änderungen werden effizient im Speicher katalogisiert, um maximalen Zugriff zu erzielen, während die Daten in HDFS gespeichert bleiben. Dieses Design ermöglicht es einem Hadoop-basierten EDH (Enterprise Data Hub), zufällige Lese- und Schreibvorgänge in Echtzeit an Benutzer und Anwendungen zu senden und dennoch die Fehlertoleranz und Haltbarkeit von HDFS zu genießen.

Die Affinität zu Hadoop ist nicht der einzige Grund, warum HBase in der Datenbank immer beliebter wird, obwohl dies möglicherweise ausreicht. Ähnlich wie bei Cassandra führen die Wurzeln von HBase als Open-Source-Implementierung von Googles Bigtable dazu, dass die Datenbank vom Design her hoch skalierbar ist.

HBase kann die Speicher-, Speicher- und CPU-Ressourcen einer beliebigen Anzahl von Servern nutzen und verfügt über Scale-Out-Funktionen wie automatisches Sharding. Es kann unbegrenzt skaliert werden, da die Last- und Leistungsanforderungen einfach durch Hinzufügen von Serverknoten steigen. HBase wurde von Grund auf so konzipiert, dass bei optimaler Konsistenz eine optimale Leistung erzielt wird.

Aber Skalierung ist nicht nur ein Nutzen. Kestelyn bemerkte: „Dank der engen Integration mit dem Rest des Hadoop-Ökosystems stehen Benutzern und Anwendungen Daten über SQL-Abfragen (mit Cloudera Impala, Apache Phoenix oder Apache Hive) oder sogar über die facettierte Freitextsuche (mit) zur Verfügung Cloudera-Suche). ” Auf diese Weise bietet HBase Entwicklern die Möglichkeit, vorhandenes SQL-Know-how zu nutzen und gleichzeitig auf einer moderneren, verteilten Datenbank aufzubauen.

Jede Datenbank hat ihre eigenen Stärken und Mängel, aber jedes der drei hier vorgestellten Daten hat eine große Lücke in der Big-Data-Landschaft geschlossen. Während es möglich ist, dass eine neue Datenbank einen Platz in den NoSQL-Top 3 (DynamoDB?) Einnimmt, ist die Realität, dass Entwickler und die Unternehmen, denen sie dienen, bereits einige starke Optionen standardisieren: MongoDB, Cassandra und HBase.

Matt Asay, jetzt Vice President of Mobile bei Adobe, war zuvor Vice President of Community bei MongoDB, Inc. Er ist emeritiertes Vorstandsmitglied der Open Source Initiative (OSI) und promovierte in Stanford, wo er sich auf Open Source und andere Themen konzentrierte Fragen der Lizenzierung von geistigem Eigentum sowie seinen Master an der University of Kent in Canterbury und seinen Bachelor an der Brigham Young University. Asay war einer der ersten Blogger.

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]