Wir wollen hier nicht auf die architektonischen Unterschiede zwischen den beiden Datenbanksystemen eingehen, etwa daß Cassandra im Gegensatz zu HBase masterless funktioniert und keinen Single-Point-of-Failure hat, sondern vielmehr auf die Gemeinsamkeiten der beiden und die in den Gemeinsamkeiten zu findenden gravierenden Unterschiede.
Beide Datenbanken gehören zur Familie der NoSQL-Datenbanken, die nach dem Wide-Column Store-Modell organisiert sind. Grundsätzlich kann man diese Form als simplen Key-Value-Store auffassen, wobei sich der Schlüssel aus drei Teilschlüsseln zusammensetzt: Dem RowKey, der ColumnFamily und dem ColumnKey.
Der Unterschied zwischen Cassandra und HBase besteht nun darin, daß es bei Cassandra keine Möglichkeit gibt, die Daten nach dem RowKey sortiert zu scannen.
Das ist ein gewaltiger Unterschied, der das Nutzungsfeld erheblich einschränkt, zumal alle Datensätze, die den selben RowKey haben, auf einem einzigen Server Platz haben müssen.
Es gab (oder gibt) in Cassandra die Möglichkeit zur Partitionierung den ByteOrderPartitioner einzusetzen. Damit ließe sich sortiert nach dem RowKey scannen (RowKey heißt im Cassandra-Sprech übrigens Partition Key), aber für die Partitionierung ist Handarbeit notwendig, indem für die zu erwartenden Bereiche des RowKeys entsprechend Nodes in den Ring eingefügt werden. HBase dagegen verteilt die Daten automatisch auf die Region-Server.
Was bei Cassandra zu allem Überfluß hinzukommt, ist daß als API ausschließlich nur noch CQL propagiert wird (Cassandra Thrift soll in zukünftigen Versionen nicht mehr verfügbar sein). CQL hat dem Anschein nach eine Ähnlichkeit mit SQL, bildet allerdings nur stark begrenzt die Funktionalität von SQL ab. Für die Arbeit mit Cassandra ist ein tiefes Verständnis des Wide-Column-Store-Models notwendig, das sich in CQL nicht widerspiegelt.
Ein Programmierer muß sich seine Datenbankabfragen im Wide-Column-Store-Model überlegen und diese dann in das beschnittene SQL namens CQL hineinformulieren. Ein Programmierer, der nur von der SQL-Seite her denkt, wird schnell von unerwarteten Ergebnissen seiner Abfragen überrascht.
Durch CQL wird Cassandra am Ende zu einer schlechten SQL-Datenbank degradiert, der man vollständigere SQL-Datenbanksysteme wie MySQL in den vielen Fällen vorziehen wird, weil Replikationen und Sharding auch dort kein Problem mehr sind.
Post a comment