Hibari – Datenspeicher für Big Data So nutzen Sie die Big-Data-Datenbank der großen Provider

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Disy Informationssysteme GmbH

Confluent Germany GmbH

Die Open-Source-Lösung Hibari bietet effiziente Datenspeicherung für große Umgebungen: Hochverfügbare Strukturen, Replikationen und eine schnelle Bereitstellung zeichnen sie aus. Die derzeit größte Installation besteht aus weit über hundert Clusterknoten.

Einige Telekommunikationsunternehmen setzen auf Hibari. Entwickelt wurde die Datenbank ursprünglich von Cloudian (vormals Gemini Mobile). Dabei handelt es sich um einen Lieferanten für Telekomsysteme. Das Unternehmen hat einen großen Datenspeicher benötigt, der schnell, flexibel, skalierbar und robust ist. Daher begann Cloudian 2005 mit der Entwicklung. Mittlerweile ist Hibari Open Source und wird beständig weiter entwickelt.

Hibari steht in der Leistung führenden Open-Source-Datenbanken wie NoSQL in nichts nach. Auch diese Datenbank setzt, wie NoSQL, auf verteilte, nicht relationale Datenbanktechnologien. Hibari verwendet dabei vor allem Schlüsselwertspeicher und eine Ketten-Replikation.

Diese Technologien bieten einige Vorteile, etwa niedrige Kosten und eine hohe Zuverlässigkeit. Dabei wird die Datenspeicherung auf Dutzenden oder Hunderten von PC-Servern durchgeführt, anstatt kostspielige Spezialspeichergeräte wie SANs zu verwenden. Die verschiedenen Server und PC-Server müssen noch nicht einmal identische Hardware aufweisen: Hibari kann die Hardware selbst flexibel nutzen, sodass sich CPU, Arbeitsspeicher und Festplattenkapazität unterscheiden können. Außerdem unterstützt Hibari fast alle verfügbaren Betriebssysteme. Insgesamt geben die Entwickler eine Grenze von maximal 250 Knoten für einen Hibari-Cluster an.

Datenkonsistenz

Die Datenbank setzt in hohem Maße auf Konsistenz und spielt zugleich ihre Vorteile vor allem dann aus, wenn sehr große Datenmengen in kurzer Zeit verarbeitet werden müssen.

Wer sich etwas mit dem System auseinandergesetzt hat, findet auch einige Optimierungsmöglichkeiten: So können einige Tabellen im Arbeitsspeicher, andere Tabellen der Umgebung auf lokalen Datenträgern gespeichert werden.

Beispielsweise wird Hibari als Datenbank in einer sehr großen Webmail-Umgebung mit mehreren Millionen Nutzern eingesetzt. Hier werden über 2.000 Transaktionen pro Sekunde durchgeführt, mit Leselatenzen von etwa ein bis 20 Millisekunden und Schreiblatenzen von etwa 20 bis 80 Millisekunden. Entwickelt wird Hibari auf Basis der Programmiersprache Erlang, die Lizenzierung erfolgt durch die Apache-Lizenz. Hibari unterstützt daneben Java, C / C ++, Python, Ruby und andere Sprachen.

Replikation und Hochverfügbarkeit

Ein Knoten im Hibari-Cluster übernimmt die Steuerung der anderen Knoten. Fällt dieser Admin-Server aus, übernimmt ein anderer Knoten des Clusters dessen Aufgabe. Dazu wird das Quorum des Clusters im Rahmen der Replikation auf andere Server übertragen. Der Übertrag kann zwar bis zu 30 Sekunden dauern, allerdings bemerken Clients davon kaum etwas.

Die Replikation funktioniert auf Basis einer Kette. Erfolgt eine Schreibanforderung an einen Hibari-Cluster, antwortet zunächst der Head-Brick, gibt die Anfrage an den Middle Brick weiter, der wiederum den Tail Brick informiert. Dieser gibt anschließend die Antwort an den Client weiter. Beim Lesen wird sofort der Tail Brick verwendet. Beim Aufbau eines Clusters muss beachtet werden, dass die physischen Server, auf denen der Head Brick und der Tail Brick laufen, mehr belastet werden als die Middle Bricks.

Die Länge der Replikations-Kette lässt sich bei der Einrichtung steuern. Unternehmen müssen also nicht immer drei Knoten einsetzen (Head Brick, Middle Brick und Tail Brick), sondern können auch vier und mehr Knoten einsetzen. Zusätzliche Knoten werden als Middle Brick eingefügt. Es lassen sich aber auch Zwei-Knoten-Replikationen durchführen. In diesem Fall gibt es keinen Middle Brick.

Überwachung der Knoten

Hibari erkennt den Ausfall jedes Knotens. Fällt der Head Brick aus, übernimmt der Middle Brick die Aufgabe des Heard Bricks. Der Cluster hat auch keine Probleme damit, wenn der Head Brick und der Middle Brick ausfallen. Gibt es in einem solchen Szenario nur noch den Tail Brick, also den letzten Knoten der Kette, dann übernimmt dieser automatisch alle Aufgaben.

Die logische Aufteilung der verschiedenen Bricks muss aber nicht zwingend auch auf physischen Knoten abgebildet werden. Auf einem physischen Server können daher durchaus mehrere logische Bricks betrieben werden. Für die Ausfallsicherheit sollten Entwickler aber darauf achten, die logischen Knoten und physischen Knoten zu verteilen.

Über die Möglichkeiten der Ketten-Replikation lassen sich auch Loadbalancer-Umgebungen realisieren. Wie die Einrichtung vorgenommen wird, zeigen Entwickler im Tutorial. Jede Kette besteht immer aus mehreren Bricks (Ziegelsteinen). Dadurch lässt sich auch der Hash und Schlüssel auf mehrere Ketten verteilen. Die verschiedenen Bricks laufen jeweils in einer eigenen, virtuellen Erlang-Instanz. Anfragen werden immer an den ersten Brick, den Head Brick, geschickt. Dieser repliziert die Daten in der Kette nach unten.

Um die Leistung eines Clusters zu verbessern, werden einfach weitere Ketten auf zusätzlichen physischen Servern implementiert. Die verschiedenen Rollen dieser Ketten werden auf die neuen physischen Knoten verteilt. Clusterknoten lassen sich jederzeit hinzufügen und entfernen, ohne den Cluster zu beeinträchtigen.

Consistent Hashing

Hibari-Clients verwenden einen Algorithmus um zu berechnen welche Operationen in der Kette durchgeführt werden müssen, um einen Schlüssel zu erhalten. Die notwendigen Informationen werden durch den Admin-Server zugeteilt. Dadurch erhalten die Clients die notwendigen Informationen, um den richtigen Knoten zu kontaktieren. Wird der falsche Knoten kontaktiert, erkennt das der Cluster und leitet die Anfrage an den richtigen Knoten weiter. Zur Datenspeicherung unterstützt Hibari verschiedene APIs:

• Native Erlang,

• Universal Binary Format (UBF/EBF),

• Thrift,

• Amazon S3 und

• JSON-RPC.

Fazit

Hibari ist eine durchaus ernst zu nehmende Alternative zu anderen NoSQL-Datenbanken, die für Big Data zur Verfügung stehen. Ihren Schwerpunkt hat die Lösung vor allem in Umgebungen, in denen günstig große Datenmengen schnell verarbeitet werden müssen. Die meisten verteilten Datenbanksysteme haben Probleme damit die Datenkonsistenz auch dann sicherzustellen, wenn Replikationen im Einsatz sind. Diese Probleme gibt es mit Hibari nicht. Durch die Chain Replication ist die Konsistenz der Daten jederzeit sichergestellt. Erst wenn die Daten von Clients in der ganzen Kette repliziert sind, wird der Vorgang als abgeschlossen betrachtet. Dadurch ist gleichzeitig aber auch sichergestellt, dass Clients bei Lesevorgängen immer die neusten Daten erhalten, da die Lesevorgänge immer am letzten Knoten (Tail Brick) durchgeführt werden.

(ID:44036592)