Hadoop, Cassandra, MongoDB – Ein Zwischenbericht

Ich habe mich die letzte Zeit viel mit Datenbanken beschäftigt, die mit richtig viel Daten (BigData DBs) umgehen können. Ich möchte mal kurz zusammen schreiben, was ich bisher herausgefunden habe:

scaleArbeitet man mit großen Datenmengen, sind die klassischen, relationalen RDBMS gänzlich ungeeignet. Das ist wohl die wichtigste Erkenntnis, die ich aus meinen Experimenten gezogen habe. Die Ursache ist ganz einfach: Relationale Datenbanken skalieren sehr schlecht. Irgendwann kann man nicht mehr noch bessere Hardware in den Server stecken (ScaleUp), sondern muss die Last auf mehrere Server verteilen (ScaleOut). RDBMS bieten hier nur die Möglichkeit der Replikationen (1-Master, n-Slave Systeme), wobei Schreibzugriffe zumeist auf dem Master ausgeführt werden und dieser somit zum Flaschenhals wird.

Distributed Databases

Was man braucht sind also echte verteilte Datenbankserver. Entweder managed oder unmanaged. Managed heißt, es gibt eine Software, die die Verwaltungsaufgaben übernimmt. Verwaltungsaufgaben ist z.B. neue Server zu registrieren, sicherstellen, dass alle Daten redundant vorhanden sind, Jobs verteilen. Hadoop wäre z.B. so ein managed System. Die Verwaltungsaufgaben übernimmt der Zookeeper aus dem Hadoop Ecosystem.
eventualCassandra und Mongo sind zwar beide unmanaged, aber trotzdem unterschiedlich. Während Cassandra das Gossip Protokoll nutzt um sich selbst zu managen, verlässt sich Mongo ganz auf den System Administrator. Über das Gossip Protokoll unterhalten sich die Server untereinander. Kommt z.B. ein neuer Server hinzu, muss nur ein weiterer Server davon wissen, der sagt es dann wieder einem anderen Server und der wiederrum sagt es auch wieder allen Servern die er kennt. So kommt es allerdings bei jeder Änderung zu kleinen Verzögerungen, die aber berechenbare Dauer haben und es ist sichergestellt, dass die Infos aber irgendwann bei allen Servern ankommen. Das nennt man dann Eventual Consistency.
MongoDB macht es sich da einfacher. Mongo verlässt sich nur auf das was in den Config-Dateien steht, Writes finden alle gleichzeitig auf allen Servern statt und Loadbalancing muss über spezielle Hardware geregelt werden.

BigData –> NoSQL (Not only SQL)

nosqlInteressant finde ich, dass wenn man über BigData Datenbanken auch automatisch von NoSQL Datenbanken spricht. Es ist also nicht nur die Topologie anders als bei Klassischen Datenbanken, sondern auch die Daten werden anders gespeichert und abgefragt. Die Daten sind zumeist in Key/Value Tabellen abgelegt, die zumindest bei Hadoop und Cassandra von Googles BigTable inspiriert sind. Das hat viele ganz grundlegende Auswirkungen:

  • Daten werden denormalisiert abgelegt (Ja, liebe Leser, stellt ruhig in Frage ob alles richtig ist, was ihr im Studium/Ausbildung gelernt habt!)
  • Daten werden intern Spaltenorientierten und nicht Zeilenbasiert abgelegt
  • MapReduce um Abfragen zu machen

Näher gehe ich auf die Punkte nicht ein, da es sonst den Rahmen sprengen würde.

Echtzeit

Sobald man von verteilten System redet, wird das Echtzeit oder nicht interessant. Zum einen beim Schreiben, was ich oben schon mit Eventual Consistency u.ä. behandelt habe, aber zum anderen auch mit Lesenden Zugriffen.
mapreduce-714818Bei MapReduce werden auch die Lese-Jobs auf mehrere Systeme verteilt. So steigt zwar die Response Time nicht mehr mit signifikant mit der Datenmenge, aber es gibt mehrere Delays zwischen den Servern. Das führt dazu, dass Queries unter 1 Sekunde nur schwerlich zu erreichen sind. Hadoop ist dazu nicht gemacht. Hadoop wurde ursprünglich von Facebook verwendet um eine Datenbank für das neue E-Mail System zu haben. Als Facebook eine Suche für die E-Mails bauen wollte, haben sie gemerkt, dass die Reaktionszeit von Hadoop einfach nicht schnell genug ist. Also haben sie Cassandra ins Leben gerufen um MapReduce, BigData und Echtzeitabfragen zu ermöglichen. Dazu mussten einige Kompromisse eingegangen werden –> Siehe Eventual Consistency!

solrCassandra bedeutet übrigens nicht, dass man damit sofort die perfekte Datenbank mit Volltextsuche hat. Cassandra ist nur das perfekte Backend für einen Suchserver, wie z.B. Apache Solr. Zusammen mit Cassandra, schimpft sich das Packet dann Solandra.

Stolpern ist das neue Surfen

Zusammen mit dem Internet hat sich der Begriff surfen etabliert. Ursprünglich hatte es die Bedeutung, Internetseiten des World Wide Web zu erkunden. Wer ehrlich zu sich selbst ist, surft doch heut zu Tage immer wieder die selben Seiten an. Von Erkunden kann da keine Rede mehr sein. Dabei gibt es doch im Internet so viele unterschiedliche, erstaunliche, verrückte, inspirierende Dinge zu entdecken.

Mich hat es geärgert, dass die Mauern um meinen (Internet-)Horizont immer höher wurden und bin auf eine echt tolle Seite gestoßen: http://www.stumbleupon.com/

Per Mausklick, kommt man auf eine zufällige Seite, über die andere StumpleUpon-Nutzer bereits “gestolpert” sind. Das funktioniert erstaunlich gut! Ich bleibe immer wieder auf neuen Seiten hängen und wenn es mich nicht interessiert – KLICK – nächste Seite. StumbleUpon funktioniert auch deswegen so gut, weil man seine Interessengebiete eingrenzen kann.

Wer wissen will was mich so interessiert, schaut doch einfach mal auf mein Profil: http://www.stumbleupon.com/stumbler/balomueller

Basisdemokratisch bis ins Manangement

Ich wurde auf einen tollen Artikel hingewiesen: Die Befreiung der Arbeit – Das 7 Tage Wochenende Den sollte wirklich jeder mal lesen!

Kurzzusammenfassung: Die brasilianische Firma Semco hat ihre inneren Strukturen im Grunde komplett basisdemokratisch ausgelegt. Selbst das Gehalt aller Mitarbeiter ist vollkommen transparent und es wird demokratisch entschieden ob jemand eine Gehaltserhöhung bekommt oder nicht. Außerdem entscheidet jeder selbst wann er wie viel arbeitet.

So chaotisch es klingt: Es funktioniert! Was mich ehrlich gesagt sehr verwundert! Solche System funktionieren doch eigentlich nur dann wenn eine gute Balance zwischen Chaos (bzw. Freiraum) und Ordnung (bzw. Eingeschränktheit) existiert. Beispiel: Mitarbeiter einer großen Firma, die an PC Arbeitsplätzen arbeiteten, wollten flexibler werden und sich je nach Projekt im Team zusammen setzen. Also hat die Firma allen Notebook besorgt und zu jedem Projekt haben sich die Leute immer wieder neu zusammen gewürfelt und neue Büros bezogen. Das Problem war, dass Mitarbeiter die einen Kollegen gesucht haben, der  in einem anderen Projekt arbeitet, diesen nicht gefunden haben! Es herrschte also zu viel Chaos. Die Lösung war der Mittelweg: Die Mitarbeiter wurden in Bereiche eingeteilt, die alle in einem Stockwerk sitzen und innerhalb der Stockwerke konnten sie sich frei ihre Arbeitsplätze aussuchen.

Wieso funktioniert diese offensichtlich sehr chaotische Struktur bei Semco? Ich glaube der Schlüssel liegt in der Firmenkultur sich immer wieder selbst zu reflektieren und zu verbessern! Existiert zu viel Chaos, müssen die Mitarbeiter sich selbst Beschränkungen auferlegen, dass das schlechte Chaos zu gutem Freiraum wird. Hat man eine solche Kultur etabliert, kann (und sollte!) man den Schritt zu mehr Selbstmanagement wagen!