Posts Tagged ‘noSQL’

BigData mit Hypertable

Ich beschäftige mich beruflich gerade mit Big Data und deren Verarbeitung. Ich habe nur ein Problem, dass ich keine gute Hardware dafür habe, oder gar ein ganzes Rechenzentrum, wie Fratzenbuch oder google. Bei der Suche nach einem Lösungsansatz für mein Problem bin ich auf Hypertable gestoßen.

Wenn es um BigData geht, wird oft HBase genannt. In keinen kleinen Prototypen, war HBase in einer VM gefühlt viel langsamer als Hypertable. Deswegen habe ich mich weiter mit Hypertable und nicht mit HBase beschäftigt.

Hypertable ist eine verteilte Datenbank, welche vom Prinzip her spaltenorientiert ist. Dieses Prinzip kann mit Hilfe der Access Groups aufweichen. Man sollte auf keinen Fall versuchen aus Hypertable eine zeilenorientierte Datenbank zu machen.

Die aktuelle Zielarchitektur sieht wie folgt aus: Auf 12 Rechnern läuft HDFS von Hadoop. Auf 11 von diesen Rechnern läuft eine RangeServer für Hypertable. Dieser ist auf 2 GB RAM Verbrauch limitiert, weiterhin habe ich einen Hypertable Master. In meiner Testdatenbank habe ich 15,3 Millarden Datensätze. Auf dieser Datenmenge dauert ein random-Zugriff im Durchschnitt 200ms, wobei die worstcase Zeit einige Sekunden beträgt. Ich bin zumindest begeistert, dass ich derartig große Datenmengen auf schlechter Commodity Hardware handeln kann. Ich bin mir sicher, dass ich mit der zur Verfügung stehenden Hardware noch mehr haus holen kann.

noSQL Datenbanken

Ich arbeite inzwischen bei Unister als Junior Systemarchitekt. Zu meinen ersten Aufgaben hat gezählt eine Architektur für eine eine Datenbank zu schaffen, welche mit sehr hohen Schreibaufkommen zurecht kommt. Als Datenbank haben wir mongoDB benutzt. Dabei handelt es sich um eine noSQL-Datenbank. Diese Dazenbanken haben kein festes Datenbankschema.

Die ersten Ergebnisse waren sehr erschütternd. Die Schreibperformence war einfach zu gering. Da man bei mongoDB nichts konfigurieren kann (Im Vergleich zu klassischen Datenbanken, wie MySQL oder PostgreSQL) war ich erst einmal ratlos. Das ganze konnte mit Clustern nicht verbessert werden. Eine genaue Untersuchung der Applikation hat ergeben, dass die Daten synchron und damit blockierend geschrieben wurden. Nachdem die Inserts nicht blockierend und in Batches umgesetzt wurden konnte schon ein Performancesprung festgestellt werden. Das konnte weiter verbessert werden, als wir die einzufügenden Daten in der Applikation nach dem Index vorsortiert eingefügt haben. Die Ursache liegt darin, das die Datenbank den Batch schneller abarbeiten kann und weniger Operationen auf dem Index nötig sind.

Zum Schluss möchte ich noch ein paar Worte zum Clustern von mongoDB verlieren. Es wird alles mitgebracht um schnell einen Cluster aufzusetzten. Ich habe es es leider geschafft, durch den Absturz von einem Knoten, den gesamten Cluster zu zerstören. Also sollte man bei Wichtigen Daten für Redundanz im Cluster sorgen. Es gibt auch viele Mittel in mongoDB um diese Redundanz zu erreichen.