Suche

HBase: NoSQL-Lösung mit großer Zukunft

Lars George

© Shutterstock.com/Raywoo

Mit seinen Wurzeln in der Bigtable-Technologie hat sich HBase über die Jahre zur Grundlage vieler Google-Produkte und -Dienste entwickelt. Welche Ideen, Architektur und welches Datenmodell stecken hinter HBase? Wir nehmen die NoSQL-Lösung unter die Lupe.

Bevor wir uns HBase im Detail anschauen, ist es interessant, auch etwas über dessen Vergangenheit und damit Herkunft zu wissen. Anfang des 21. Jahrhunderts, also vor mehr als zehn Jahren, boomte das Internet und Information in Form von Dokumenten und Webseiten wuchsen unaufhörlich. Google, ein aufstrebendes Unternehmen mit Ziel, all diese Daten mithilfe einer Suchfunktion zur Verfügung zu stellen, stand vor dem Problem, diese Dokumente kosteneffektiv und zukunftssicher zu speichern und zu bearbeiten. Daraus entstand die erste Version des Google File Systems (kurz GFS) und MapReduce. Damit war es möglich, alle Webseiten im Internet zu archivieren und parallel im Batchbetrieb auszuwerten. Jeder neue Lauf über alle Daten erzeugte einen neuen Suchindex. Sehr schnell wurde aber klar, dass ein Dateisystem nicht ideal ist, um sich ständig ändernde Datensätze zu speichern. Es brauchte ein skalierbares, aber dennoch datenbankähnliches System, das eben diese Datensätze leicht zugänglich und aktualisierter macht. Daraus entstand dann Mitte der 2000er Jahre Bigtable, das als Grundlage für HBase diente. Google veröffentlichte nicht nur die Funktionsweise von GFS und MapReduce, sondern auch Bigtable. Dieses war 2006, als dessen technische Veröffentlichung herausgegeben wurde, schon mehrere Jahre erfolgreich im Einsatz. Über die weiteren Jahre wurde Bigtable Grundlage für viele Google-Produkte und -Dienste, und bestätigte damit dessen Idee und Implementierung.

Einige Jahre nach den technischen Veröffentlichungen von Google wurden im Rahmen des Apache-Nutch-Projekts diese Ideen aufgegriffen, denn zu dieser Zeit arbeitete Doug Cutting – zusammen mit Mike Cafarella – an einer quelloffenen Implementierung eines Web-Crawlers und Indexers. Nutch brauchte dieselben Funktionen, wie GFS und MapReduce sie für Google boten, und deshalb wurden genau deren Funktionen in Nutch integriert. Doug ahnte aber vom allgemeinen Nutzen und startete ein neues Apache-Projekt namens Hadoop. In Listing 1 sind die ersten Commit-Einträge zu sehen.

JM_12_13_george_listing1

Kurz nach der Gründung von Hadoop begann Mike Cafarella auch Bigtable in dem quelloffenen Projekt zu implementieren. Daraus wurde dann die Hadoop Database, oder HBase in abgekürzter Form. Hier wiederum der erste Commit-Eintrag für HBase:

r525267 | cutting | 2007-04-03 22:34:28 +0200 (Tue, 03 Apr 2007) | 1 line

HADOOP-1045.  Add contrib/hbase, a Bigtable-like online database.

Über die Jahre wuchs HBase aus den Kinderschuhen heraus und wurde von einem Contrib-Modul in Hadoop zu einem Unterprojekt und dann endgültig zu einem Apache-Hauptprojekt. Dies spiegelt sich auch in den Versionsnummern wieder, die zuerst Hadoop folgen, aber dann von 0.20 auf 0.89 springen – nur aus dem Grund, um die Trennung des Projekts und die Änderung der Frequenz der Veröffentlichungen deutlich zu machen.

Datenmodell

Bigtable, und damit HBase, speichert seine Datensätze in einem logischen Modell, das man von relationalen Datenbanken her kennt. Es gibt also Tabellen, Zeilen und Spalten. Damit hören aber die Ähnlichkeiten auch auf: HBase hat keine Abfragesprache wie SQL, referenzielle Integrität, Transaktionen oder beliebige Indexe. Der Zugriff auf die Daten erfolgt mit einem relativ einfachen API, das nativ in Java zur Verfügung steht, aber auch über andere Protokolle wie REST oder Thrift angesprochen werden kann. Dieses API kennt grundsätzlich nur vier Befehle: Put, Get, Scan und Delete. Dazu gesellen sich noch einige speziellere Befehle für atomare, serverseitige Funktionen, wie Increment und checkAndPut oder checkAndDelete.

Daten werden wie erwähnt in Tabellen und darin in Zeilen und Spalten abgelegt. Die Zeilen haben einen eindeutigen Schlüssel, der so genannte Zeilenschlüssel (Row Key). Damit kann der Anwender auf die eigentlichen Spalten zugreifen, wiederum über einen Schlüssel, den Spaltenschlüssel (Column Key oder Column Qualifier). Ein weiteres Merkmal von HBase ist, dass es die eigentlichen Werte in den Spalten versioniert, und – so die systemweite Vorgabe – drei Versionen der Werte aufhebt, in den Zellen (Cells). Hat man einen Zeilen- und Spaltenschlüssel, kann man sich den aktuellsten Wert – die zuletzt gespeicherte Zelle – geben lassen. Hat man aber auch noch einen Zeitstempel (Timestamp), kann man auch auf einen historischen Wert zugreifen. Die Vorgabe ist immer der letzte gespeicherte Werte, und damit kann der Anwender eine ganze Zeile lesen, wie er es aus einer Datenbank gewöhnt ist, als wären nur die aktuellen Werte gegeben. Abbildung 1 zeigt dies in Form einer Tabellenkalkulation.

JM_12_13_george_abb1

Abb. 1: Zeilen mit versionierten Werten

Das API hat aber Funktionen, die dem Anwender erlauben, auch historische Werte auszulesen zusammen mit den aktuellen oder für einen gegebenen Versionsbereich (Time Range) – ganz wie es die Anwendung benötigt. Im kanonischen Anwendungsfall von Bigtable, dem Web-Crawl, d. h. dem Speichern aller Internetseiten, werden zum Beispiel die drei letzten Versionen einer HTML-Seite aufbewahrt, denn damit kann Google feststellen, wie oft eine Seite aktualisiert, wie sie verändert wird (man denke an autogenerierte Inhalte) und damit den PageRank der Seite dementsprechend kalkulieren.

Schauen wir uns weiter die Architektur des Datenmodells von HBase an, dann finden wir einen Hinweis, wie dessen Skalierbarkeit erreicht wird. Anstatt dass der Anwender selbst Daten in Teilbereiche zerlegen muss, um diese von mehreren Servern bereitstellen zu lassen, ist bei HBase dies bereits eingebaut. Die Tabellen werden in Regionen (Regions) aufgeteilt, die von genau einem Region Server zur Verfügung gestellt werden. Ein solcher Server bietet seine Dienste im Auftrag von einer oder mehreren Regionen an. Damit kann eine Anwendung die Daten genau beim richtigen Server finden. Dazu gibt es ein Nachschlageregelwerk, das auf internen Spezialtabellen beruht: -ROOT- und .META. (in 0.96 von HBase wurde -ROOT- entfernt, da nicht wirklich benötigt). Mithilfe dieser Tabellen kann der Server, der eine bestimmte Zeile (oder eine Anzahl von Zeilen innerhalb einer Region) bedient, gefunden werden. Die von HBase mitgelieferte, clientseitige Bibliothek in der Anwendung merkt sich diese Information für weitere Zugriffe. Damit wird recht schnell eine Karte aller Regionen und deren Server erstellt. Weitere Zugriffe sind dann direkt auf die Daten möglich, ohne weitere Nachschlageoperationen.

An dieser Stelle sollten zwei entscheidende Merkmale von HBase gegenüber anderen NoSQL-Datenbanken im Vergleich genannt werden: strikte Konsistenz und atomare Zeilenoperationen. Ersteres gründet sich auf der gerade genannten Zuordnung einer Region zu genau einem Server. Dieser kann dann alle Modifikationen (wie Put und Delete) so behandeln, dass immer eine strikte Konsistenz gewahrt bleibt. Dazu kommt, dass eine Zeile immer atomar verändert wird, also ganz oder gar nicht. Damit kann eine lesende Anwendung entweder die alten Werte oder aber die neuen Werte über alle Spalten und Familien lesen. Es kann nicht vorkommen, dass Modifikationen einer schreibenden Anwendung teilweise sichtbar sind (Read Committed nach ANSI/ISO).

Eine weitere Eigenheit des Datenmodells sind die Spaltenfamilien (Column Famlies), welche die Spalten innerhalb einer Zeile gruppieren. Dies ist an die Funktion von spaltenorientierten Datenbanken angelehnt, die speziell für analytische Abfragen geeignet sind, denn dort werden bei einer sehr selektiven Abfrage nur die benötigten Daten der enthaltenen Spalten durchlesen. In HBase dienen die Spaltenfamilien der Gruppierung von zusammengehörigen Spalten, aber auf einer gröberen Ebene, d. h. viele Spalten in wenigen Gruppen. Zurück zum Web-Crawl-Beispiel von vorhin: Dort werden die echten Daten, also HTML-Seiten, in einer Familie abgelegt, und Metadaten in einer anderen. Auch die eingehenden und ausgehenden Links, die für die Berechnung des PageRanks nötig sind, werden in separaten Spaltenfamilien abgelegt, da diese auch separat durchlesen werden. Abbildung 2 zeigt eine Zusammenfassung des Datenmodells.

Abb. 2: Architektur der Datenspeicherung in HBase

Abb. 2: Architektur der Datenspeicherung in HBase

Ein weiterer wichtiger Teil der Architektur in HBase ist die implizite Sortierung aller Schlüssel, d. h. die Zeilen und auch Spalten werden lexikographisch geordnet, im Falle der Spalten sogar innerhalb deren Familie getrennt. Diese Art der Sortierung beruht auf einer weiteren Eigenschaft des Datenmodells: Alle Schlüssel sind binär. In Abbildung 2 kann man sehen, wie die Zeilen eher untypisch für Menschen sortiert werden, denn row-18 kommt noch vor row-2. Lexikographisch sortiert bedeutet, dass ein Schlüssel Zeichen für Zeichen, genauer gesagt Byte für Byte, verglichen wird. Und da die 2 an Position 5 größer ist als 1 im vorherigen Schlüssel, werden alle Zeilen, die mit row-1 anfangen vorneweg sortiert. Im Übrigen ist in diesem Beispiel wenigstens ein lesbarer Schlüsselwert gewählt worden, es hätte auch ein komplett binärer, nicht druckbarer Wert sein können – die Anwendung ist frei, irgendeinen Wert zu setzen.

Letztlich stellt die clientseitige Bibliothek von HBase auch noch zahlreiche Funktionen zur Verfügung, welche die Anwendung nach Bedarf nutzen kann. Dazu gehören Hilfsklassen für die Umwandlung von nativen Java-Typen in deren binärer Darstellung, wie int, long und String. Es gibt auch einen ganzen Satz an Filterkassen, die es erlauben, die Daten bereits auf der Serverseite zu begrenzen, damit diese nicht unnötigerweise über das Netzwerk an die Anwendung geschickt wird, nur um dort fallengelassen zu werden. Diese Filter erlauben nach beliebigen Schlüsseln oder Werten zu selektieren, und wenn nötig, kann der Anwender sogar seinen eigenen Filter schreiben und benutzen.

Implementierung

HBase verlässt sich auf das darunterliegende Dateisystem, um alle Daten sicher aufzubewahren. Dazu gehört auch die notwendige Replikation von Datenblöcken. Wie GFS dies für Bigtable macht, so ist das Hadoop Distributed File System (HDFS) dafür in Kombination mit HBase zuständig. Damit kann sich HBase selbst auf dessen eigene Dateien konzentrieren, denn HDFS übernimmt die Herstellung und Kontrolle der Prüfsummen, die Verteilung der Dateien in Blöcken über die verfügbaren Server, sowie die Sicherstellung, dass ein Ausfall eines Servers nicht bemerkbar ist.

Google selbst hat das Rad bei Bigtable nicht neu erfunden, sondern sich auf existierende Technologien gestützt, unter anderem die so genannten Log-Structured Merge Trees (LSM-Trees), die Daten immer sequenziell schreiben und damit nicht dem unter Last merkbaren Problem der auf B-Tree basierenden relationalen Datenbanken ausgesetzt sind. Hier geht es um die IOPS moderner Hardware: Festplatten können sequenziell schneller arbeiten als bei zufälligen Zugriffen. Grund hierfür ist, dass auch heutige Festplatten im Vergleich zu den Durchsatzraten immer noch eine um mehrere Faktoren größere Zeit für die Positionierung (Seek) der Schreib-/Leseköpfe benötigt. Ziel eines Speichersystems ist es deshalb, möglichst wenige Kopfpositionierungen zu verursachen und möglichst viel sequenziell zu lesen.

Dies ist genau das Ziel der LSM-Trees, die neue oder geänderte Daten zuerst in ein binäres Log schreiben, und dann sortiert im Speicher vorhalten. Sind genügend Daten vorhanden (also wird der Speicher voll, oder ein vorbestimmter Schwellenwert wird erreicht), dann werden die Daten als neue Datei gespeichert. Über eine gewisse Zeit werden damit also immer wieder neue Dateien mit Daten im Dateisystem abgelegt. Diese können weiterhin von Anwendungsseite parametrisiert werden, indem dort im Datenschema festgelegt wird, ob eine Datei komprimiert werden soll, oder spezielle Zugriffshilfen (z. B. Bloom-Filter) mit erzeugt werden sollen. Die binären Logdateien werden solange vorgehalten, bis alle Veränderungen aus dem Speicher herausgeschrieben wurden. Damit kann HBase im Falle eines Serverfehlers den aktuellen Stand wiederherstellen.

Im Hintergrund laufen noch weitere Prozesse, die aus dem LSM-Trees-Modell stammen. Einer davon sind die Compactions, welche die obigen Datendateien in regelmäßigen Abständen prüfen und gegebenenfalls kombinieren. Dies ist vonnöten, um die Anzahl der Dateien gering zu halten (nicht jedes Dateisystem kann unendlich viele Dateien effizient verwalten), aber auch, um die Suche der Daten für eine Zeile möglichst schnell ablaufen zu lassen. Es ist einfacher, ein paar wenige Dateien zu prüfen, als viele hunderte.

Eine weitere asynchrone Operation ist die automatische Aufteilung (Splits) der Zeilen auf Regionen. Dies passiert, sobald die Größe aller Datendateien einer Region eine bestimmte voreingestellte Größe erreicht. Dann wird jener Hintergrundprozess angestoßen, der die Daten auf zwei neue Regionen aufteilt und die originale Region abschließend löscht. Davon bemerkt der Anwender im Normalfall nichts. Es kann aber zusätzliche I/O-Last auf einem HBase-Cluster erzeugen.

Für die Betrachtung von HBase in diesem Artikel sind nun alle entscheidenden Merkmale genannt. Damit können wir uns nun anschauen, wo HBase gut oder weniger gut funktioniert – und warum.

Stärken und Schwächen

Wie eingangs erwähnt, fehlen HBase einige aus der relationalen Datenbankwelt bekannten Leistungen. Allem voran hat HBase keine Transaktionen, und das aus gutem Grund: Diese machen eine Skalierung einer Datenbank über Rechnergrenzen hinweg schwierig. Aber HBase bietet Ersatz in Form von serverseitigen, atomaren Operationen an, wie zum Beispiel increment oder compare-and-set-(CAS-)Befehle wie checkAndDelete. Mit deren Hilfe kann der Anwender sehr effizient Zähler verändern, oder vorher gelesene Daten nach einer Prüfung neu setzen. Dies machte sich Facebook in dessen Insights-Service zunutze, in dem es einen (M)OLAP-Würfel für die spätere Reporterstellung immer aktuell hält. Der Reportgenerator braucht dann nur eine einzige Zeile aus HBase zu lesen, der Rest ist die Aufbereitung mithilfe von Diagrammen und Tabellen. Tests innerhalb Facebook haben gezeigt, dass ein Cluster aus 100 Rechnern bis zu eine Million Zähleroperation durchführen kann, also 10 K pro Server. Obwohl Transaktionen in HBase fehlen, kann eine Anwendung eine Zeile atomar aktualisieren, egal wie viele Spalten verändert werden und über wie viele Spaltenfamilien hinweg.

Neuere Versionen von HBase, also 0.94 und danach, unterstützen auch weitere interessante Erweiterungen, zum Beispiel die regionslokalen Transaktionen. Diese ermöglichen es, zusammengehörige Zeilen nicht über mehrere Regionen aufzuteilen, und damit eine atomare Veränderung über Zeilengrenzen hinweg durchzuführen. Im Prinzip entspricht das den Entitätsgruppen (Entity Groups) aus dem Google-Megastore-Projekt. Dort werden nur kleine Teilbereiche atomar aktualisiert, so wie auch in HBase das der Fall ist. Kaum eine andere NoSQL-Lösung hat etwas Vergleichbares zu bieten.

HBase hat außerdem keine eigene deskriptive Abfragesprache, wie zum Beispiel SQL. Das kann zwar mithilfe von Tools wie Hive, Impala oder Drill umgangen werden, denn diese „übersetzen“ SQL-Abfragen in solche, die HBase unterstützt, aber dennoch sollte sich der Anwender im Klaren sein, dass dies keine umgangssprachliche eierlegende Wollmilchsau ist. Der Grund hierfür ist das Datenmodell und das API, das HBase zur Verfügung stellt. Sollte eine SQL-Abfrage in eine direkte Leseoperation einer Zeile, oder wenige zusammenhängende Zeilen transformiert werden können, dann ist dies ideal. Ist aber die Abfrage so freizügig, dass das Tool keine Zeilen- oder Spaltenschlüssel benutzen kann, und damit die ganze Tabelle durchsuchen muss, dann kann es vorkommen, dass eine Abfrage, die erwartungsgemäß sehr schnell sein sollte, auf einmal Minuten braucht (natürlich abhängig von der Tabellengröße).

Ein zusätzliches Problem ist, dass HBase eben nur zwei Indexe unterstützt, d. h. den globalen primären Index der Zeilenschlüssel, und dann innerhalb der Zeile den Index der Spaltenschlüssel – und beide nur lexikographisch sortiert in einer Richtung. Will die Anwendung aber weitere Indexe haben, um beispielsweise einen Anwender über ID, aber auch über Namen zu finden, oder einen Suchindex pro Zeile speichern, dann muss die Anwendung um diese Einschränkung herum arbeiten. Dies geht über Nachschlagetabellen (Lookup Tables), oder der Speicherung der Indexe in einer anderen Spaltenfamilie innerhalb der gleichen Zeile. Problematisch ist immer, diese Indexe mit dem Hauptdatensatz synchron zu halten. Verschiedene Ansätze wurden innerhalb der HBase-Gemeinde über die Jahre diskutiert. Facebook Messages benutzt den letztgenannten Ansatz, wobei es den Suchindex des Benutzerkontos in einer eigenen Spaltenfamilie ablegt. Damit macht Facebook Gebrauch von den atomaren Modifikationen innerhalb einer Zeile: der Hauptdatensatz und der Index sind damit immer im Einklang.

Ein interessanter Seiteneffekt der Speicherung der Daten in HBase liegt darin, dass es nur echte Daten speichert, also keine Platzhalter braucht wie das aus Datenbanken mit festen Schemata bekannte NULL. Abbildung 3 veranschaulicht, was damit gemeint ist, denn jede Zeile ist wirklich in sich selbst geschlossen. Weitere Zeilen können die gleichen, aber auch beliebig andere Spalten enthalten.

Abb. 3: Spalten pro Zeile können beliebig und völlig verschieden sein

Abb. 3: Spalten pro Zeile können beliebig und völlig verschieden sein

Die Anwendung muss auch nichts weiter als die Spaltenfamilien definieren, danach kann sie während des Schreibvorgangs beliebige Spalten anlegen. Eine Tabelle hat initial keine einzige Spalte, aber wenn die Anwendung etwas in col-A schreibt, dann existiert die Spalte von nun an mit dem gegebenen Wert. Ein Rückschluss daraus ist, dass es keine Spalten ohne Wert geben kann. Dies kann sich zunutze gemacht werden, zum Beispiel als eingebettete Datensätze oder Indexe. Generell ist also eine der Stärken von HBase die Behandlung von dünn besetzten Tabellen.

HBase hat neben dem Put, um Daten zu speichern, dem Get, um Daten einer Zeile zu lesen, und dem Delete, um Daten zu löschen, auch einen Scan-Befehl. Interessant ist, dass dieser sehr genau eingeschränkt werden kann, über Start- und Stoppschlüssel, sowie Zeitstempel. Wenn nun eine Anwendung nicht weiß, welche Schlüssel in einer Tabelle genau gespeichert sind, weil die Schlüssel beispielsweise aus Benutzerdaten generiert werden (MD5 Hash des Namens oder der Name im Klartext), dann können die Start und Stoppschlüssel der Abfrage so gesetzt werden, dass sie automatisch einen bestimmten Bereich erfassen. Tabelle 1 listet einige Beispiele für den Startschlüssel auf und beschreibt das Ergebnis.

Tabelle 1: Beispiele für mögliche Werte des Startschlüssels

Tabelle 1: Beispiele für mögliche Werte des Startschlüssels

Die weitere Variante der Abfrage mit Zeitstempel funktioniert grundsätzlich, weil jede Zelle wie oben beschrieben einen Zeitstempel für die Versionierung der Werte mitspeichert. So kann die Anwendung zum Beispiel alle Werte, die nach einem bestimmten Datum verändert wurden, sehr effizient abfragen – was sehr nützlich ist für schrittweise, zeitgesteuerte Datenverarbeitung. Aber diese Variante hat noch einen weiteren Vorteil, denn sie kann ganze Datendateien innerhalb des Speichersystems in HBase ausschließen. Wie oben erwähnt werden Dateien regelmäßig auf das Dateisystem geschrieben und diese Dateien haben unter anderem auch die Information, was der aktuellste und älteste Eintrag darin ist. Wenn nun für Daten aus dem letzten Tag gefragt werden, können Dateien, die älter sind, einfach übersprungen werden. Ein Datenschema, das sich dies zunutze machen kann, hat den enormen Vorteil, eine ganze Tabelle augenscheinlich in sehr schneller Zeit durchsuchen zu können – der Trick ist aber, dass nur wenige Daten wirklich gelesen werden müssen.

Zukunft

HBase hat eine große Zukunft vor sich. Die Konkurrenz aus dem NoSQL- und dem relationalen Datenbanklager ist Ansporn und Hinweis zugleich. In den letzten Jahren hat sich immer wieder gezeigt, wie Ansätze anderer Systeme sich nach kurzer Zeit auch in HBase wiederfanden. Apache und quelloffene Projekte generell erlauben es, solche Verbesserungen übernehmen zu können. Auch auf HDFS-Ebene findet dies statt: Kommerzielle Anbieter hatten vor einiger Zeit bestimmte Anforderungen erhoben, die innerhalb weniger Monate zu entsprechenden Änderungen in HDFS geführt und das Gleichgewicht wieder hergestellt haben.

Die letzten Versionen von HBase brachten interessante Neuerungen, zum Beispiel Coprocessors in 0.92 – diese fügen serverseitige Erweiterungen hinzu, die durch den Anwender selbst in Java geschrieben werden können, also ähnlich den Stored Procedures aus der RDBMS-Welt. Oder 0.94, das einiges an Leistungssteigerungen bereitstellte und den Betrieb vereinfachte. Die aktuelle Version 0.96 (liegt zum Zeitpunkt des Schreibens in Form eines Release Candidates vor) stellt Snapshots zur Verfügung (diese wurden auch in 0.94.6.1 nachträglich eingefügt) und Google Protocol Buffer basierte RPC-Protokolle – damit ist ab dieser Version ein rollendes Aktualisieren der Software möglich, ohne den Cluster stoppen zu müssen. Snapshots wiederum sind essenZiell, um Daten im laufenden Betrieb von HBase in einer Datensicherung ablegen zu können. Zuvor war dies nur im Offlinebetrieb möglich.

An allen Ecken und Enden wird verbessert und hinzugefügt, und die Entwicklergemeinschaft arbeitet gemeinsam auf eine Version 1.0 hin. Benutzer wie Facebook, eBay oder Apple zeigen, dass HBase im Mainstream nicht nur angekommen, sondern als produktives System akzeptiert worden ist. Alleine diese genannten Anwender besitzen riesige HBase-Cluster, z. B. Facebook mit mehr als zwei Petabyte komprimiert gespeicherten Daten, also mehr als 6 Petabyte roh, wenn man den Replikationsfaktor (dreifach) innerhalb von HDFS hinzurechnet, verteilt über mehrere separate Cluster. Kann man da noch zweifeln?

Tabelle 2: Technische Eigenschaften von HBase

Tabelle 2: Technische Eigenschaften von HBase

Tabelle 3: Details zu Lizenzen und Support

Tabelle 3: Details zu Lizenzen und Support

Tabelle 4: Clients für Java und andere JVM-Sprachen

Tabelle 4: Clients für Java und andere JVM-Sprachen

Aufmacherbild: SQL or NoSQL words written on white board, Big data concept von Shutterstock.com / Urheberrecht: Raywoo

Verwandte Themen:

Geschrieben von
Lars George

Lars George ist EMEA Chief Architect bei Cloudera und entwickelt datenorientierte Lösungen für Kunden und Partner. Er ist Autor des O’Reilly Buchs „HBase – The Definitive Guide“ und hat auf vielen NoSQL- und Hadoop-bezogenen Konferenzen vorgetragen, darunter Hadoop Summit und Hadoop World, QCon, FOSDEM, JAX und ApacheCon.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.