Das NoSQL-Shootout bei SEARCHTEQ

Zum Thema Datenbanken finden sich im Netz allerhand Reviews, Vergleiche und Tests. Bei genauerer Betrachtung wird schnell klar, dass den Tests (fast) immer eine recht kleine Datenbasis zugrundeliegt. Dadurch sind diese Bewertungen nicht immer für große Produktivsysteme repräsentativ.

Die Datenbank-Hersteller wiederum präsentieren auf ihren Seiten sehr gerne für den Produktivbetrieb nicht verwertbare Benchmarks. Auch diese Zahlen sollte man nur mit großer Vorsicht genießen und auf keinen Fall dazu benutzen, die Geschwindigkeit der Lösungen miteinander zu vergleichen. Oft ist bei diesen Benchmarks die Last unterschiedlich, die Systeme sind mal verteilt, mal unverteilt. Mal werden die verschiedenen Datenbankenoperationen mit einem Thread, ein anderes Mal mit mehreren Threads durchgeführt. Letzteres gilt zum Teil auch für unsere Benchmark-Zahlen, so dass man mit diesen keine Aussage darüber treffen kann, welche Lösung die schnellste ist.

Im Fall unserer Suchmaschine www.suchen.de wurde schnell klar, dass eigene Vergleiche notwendig sind, um das Abschneiden der Datenbanken besser bewerten zu können.

Die Crux an relationalen Datenbanken ist das feste Schema, dem man unterworfen ist: Eine Tabelle besteht in der Regel aus mehreren Spalten. Nicht jede Spalte einer Zeile enthält unbedingt einen Eintrag. In diesem Fall schreibt die Datenbank hier NULL oder einem vordefinierten Wert. Bei uns trat das sehr oft, eigentlich immer auf. Auf der Suche nach einer "besseren" Datenbank stießen wir sehr schnell auf NoSQL-Datenbanken verschiedener Anbiet, die nicht das Problem der "gewöhnlichen" SQL-Datenbanken haben. Unsere Kandidaten kommen mit verschiedenen Features daher und wir standen daher vor der Wahl, die für unsere Anwendung beste Implementierung auszusuchen.

Unser Vorgehen

Die Auswahl der Technologie basierte auf folgenden Punkten:

• Definition eines Feature-Sets: Dazu wurde identifiziert, welche Features ein Store mindestens anbieten muss, um für uns als Lösung in Frage zu kommen. Wichtig ist, dass man – wie wir am Anfang des Artikels bereits betonten – nur zwingend erforderliche Features in diese Menge aufnimmt und die Anforderungen klar definiert.
• Identifizierung von Kandidaten: Kandidaten sollten möglichst dieses Feature-Set abbilden, was bei Voldemort nicht der Fall war.
• Implementierung des Test-Interfaces: Hier zeigte sich relativ schnell, ob eine in der Theorie benutzbare Technologie auch in der Praxis bestehen kann. In diesem Schritt gab es einige Überraschungen und Terrastore schied aus der Liste der Kandidaten aus.
• Lasttests: Diese Testphase lief über einige Tage. Dabei wurde versucht, die Datenbanken, wie im späteren Produktivbetrieb, unter eine möglichst realistische Last zu setzen. Bei MongoDB führte das schließlich zum Datenverlust auf einem kompletten Knoten. Der Datenbestand war danach inkonsistent und damit unwiederbringlich verloren.

Anforderungen

Die harten Anforderungen an die NoSQL-Datenbank waren

• Verteilung der Daten über mehrere Hosts verbunden mit der Möglichkeit, später weitere Hosts (im laufenden Betrieb) hinzuzufügen, wobei die "alten" Daten dann verteilt werden,
• Robustheit der Systems (ggf. die Möglichkeit der Datenspiegelung),
• Ausfallsicherheit des Systems (das bedeutet mehr als 99% Verfügbarkeit)
• und ein leicht anzubindender Java-Client.

Weiche Anforderungen:

• leichte Installation unter Linux und Windows
• gute und vollständige Dokumentation
• eine aktive Community – die Möglichkeit, bei Fragen schnell qualifizierte Hilfe zu bekommen
• schöner Client (thread-safe, übersichtliches und funktionales Interface, gern gesehen: ein Python-Client)
• Unterstützung von Range-Queries
• unser Zugriffsmuster ist: paralleles Schreiben vieler einzelner URLs, die Auswertung der Daten erfolgt pro Domäne, das bedeutet, lesend werden große Datenausschnitte auf einmal angefragt. Die Datenbank sollte dieses Muster möglichst gut unterstützen.
• transparente und zuverlässige Verteilung auf mehrere Knoten
• Sprachanbindungen (Java und Python)

Im Nachhinein betrachtet, stellten wir fest, dass viele Anforderungen, die ursprünglich als wichtig erachtet wurden, weniger relevant waren. So haben wir beispielsweise auf eine Datenspiegelung verzichtet: Die Hardwarekosten eines redundant ausgelegten Systems stehen in keinem Verhältnis zu den Kosten, die Daten partiell oder sogar komplett neu zu erzeugen. Befindet man sich also in einer ähnlichen Entscheidungssituation, sollte man zunächst versuchen, die minimale Feature-Menge in einem längeren Prozess zu identifizieren. Die tatsächlichen unentbehrlichen Anforderungen muss das System unbedingt erfüllen.

Testverlauf

Um ein Ergebnis vorwegzunehmen: Alle von uns getesteten Lösungen liegen beim Durchsatz in der gleichen Größenordnung und sind damit so schnell, dass bei der Entscheidungsfindung ausschließlich Faktoren, wie Benutzbarkeit, Abbildbarkeit der Anforderungen und Stabilität relevant waren. Wie schon erwähnt bildeten Performance-Tests, Reviews und die Anzahl der Features nicht die Grundlage zur Ernennung unseres Testsiegers.

Eine sehr gute Übersicht über mögliche Lösungen gibt es unter http://www.cattell.net/datastores/Datastores.pdf.

Unsere Testkandidaten waren:

• Voldemort
• Terrastore
• CouchDB
• MongoDB
• Cassandra

Im Verlauf des Tests blieben fast alle Produkte recht schnell und eindeutig auf der Strecke:

Wir haben uns letztendlich für Cassandra entschieden, da dieser Kandidat alle Phasen erfolgreich absolvierte. Wie sich letztendlich zeigte, sagt die Anzahl der Features nicht immer etwas über die Qualität des Produktes aus – wer hätte das gedacht...

Zum Entstehungszeitpunkt dieses Artikels speichert Cassandra eine gute halbe Milliarde Dokumente (2.25 TB Festplattenplatz) und reagiert immer noch sehr zügig auf Anfragen jeglicher Art (Abfragen, Einfügen, Löschen). Die NoSQL-Datenbank ist auf 16 Knoten verteilt, wobei jeder Knoten ungefähr 40 Millionen Einträge beziehungsweise 145 GB an Daten hält. Diese Werte blieben in der jüngsten Vergangenheit sehr konstant. Cassandra verarbeitet auf unseren Knoten über 1000 Anfragen pro Sekunde. Unsere vorherige MySQL-Datenbank war seit langem nicht mehr effizient, was das Abfragen von Dokumenten angeht und ebenfalls nicht mehr in der Lage, die Dokumente effizient abzubilden.

Wir werden in weiteren Artikeln den genauen Testverlauf pro Datenbank darstellen.