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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>