Kochen mit Wasser

Es gibt sicher interessantere Dinge, die man an einem Feiertag machen kann. Mein neues NAS kann Docker von Haus aus, also warum nicht ein bisschen damit rumspielen. Und weil beruflich gerade das Thema noSQL in Form einer Apache Cassandra-Datenbank durch Home Office gewabert ist, war ich doch ein bisschen neugierig, was es damit auf sich hat. Außerdem hat es eh geregnet.

noSQL-Datenbank hatten ja bisher sowas mythisches für mich. Ich komm aus der klassischen relationalen Datenbank-Ecke: Viele Tabellen, Schlüssel hinten und vorne, die das ganze Konstrukt zusammenhalten. Und ganz wichtig: Möglichst nichts doppelt speichern! Ein Hoch auf Normalisierung. Wenn ich das richtig überblicke, ist die 3. Normalform immer noch der Idealzustand, der sowohl im Studium wie auch in der Ausbildung gepredigt wird. Die praktische Realität sieht anders aus. Aus dem eine oder anderen Grund.
noSQL war in meinem Kopf immer der krasse Gegenentwurf: Alles ist irgendwie frei fließend, keine Tabellen mehr, Daten auf fast schon magische Art und Weise verknüpft. Entsprechend habe ich mich immer gewundert, wie man Daten da rein und wieder rausbekommen soll.

Versuch macht kluch

Also Cassandra-Docker-Container installiert und gestartet. Die Guides erzählen dann was von Scripten, die in Ordnern abgelegt werden sollten. Dummerweise ist die Container-Station von QNAP da alles andere als komfortable und legt die Daten von sich aus erstmal irgendwo ab. Über den SSH-Zugriff kommt man an Stellen raus, wo man nie hin wollte. Einen Editor, wie den vi oder nano kennt die Shell nicht. Perfekte Voraussetzungen. Man muss da schon ein bisschen Lust drauf haben, das machen zu wollen, hatte ich den Eindruck.
Immerhin habe ich es nach ein paar Versuchen dann doch zum laufen bekommen und den Weg zur Shell gefunden um Kommandos abzusetzen. Nach einem kostenlosen Editor wie dem DBeaver kann man lange suchen. Ich habe auf die schnelle für Cassandra zumindest nichts gefunden dass kostenlos und halbwegs brauchbar aussah. Ich hatte jetzt auch keine Lust da stundenlang auszuprobieren.

Am Ende der Magie

Was mir an den ersten Beispielen schon aufgefallen ist CQL (Cassandra Query Language) sah verdächtig nach SQL aus. Wenn da was kommt wie…

SELECT * FROM DINGENS.BUMENS

…dann hab ich das in meiner Karriere schon ein paar Mal gesehen. Auch der Create für die Tabelle (!) kam mir seltsam vertraut vor. Nicht all zu komplex, aber war ja auch nur ein Tutorial um mal ein bisschen zu probieren. Aber auch das etwas tiefergehende Tutorial bei Baeldung war eher desillusionierend. Moment… eigentlich ist das alles so wie ich das schon 15 Jahren mit normalen Datenbanken kenne? Nur irgendwie teilweise auch doofer?

Die Sache mit den Tabelle

Okay, Tabellen gibt es nicht. Also eigentlich. Tabellen heißen halt Column-Families, werden aber mit create Table angelegt. Sieht alles aus wie SQL. Funktioniert auch genauso. Also das meiste davon.
Beziehungen gibt es nicht. Ist ja Join-less. Dem entsprechend auch keine Fremdschlüssel. Klatsch einfach alles was du irgendwann mal wissen willst, in eine Tabelle. Referenzen musst der Entwickler sich dann drum kümmern.

Will ich zum Beispiel eine Benutzerverwaltung machen, brauche ich eine Tabelle für den Benutzer. Alle Daten kommen da rein. Wie der Benutzer heißt, was es sonst noch so zu ihm zu wissen gibt (Adresse, Firma usw.) und eben ne eindeutige Kennung.
Will ich dann wissen was mit dem Benutzer passiert ist oder er getan hat, brauche ich eine zweite Tabelle in der ich zu diesem User alle Einträge speichere. Was man bei einer normalen Datenbank mit Primär- und Fremdschlüssel verknüpfen würde und eventuell auch über referenzielle Integrität und kaskadierendes Löschen in den Griff bekommen würde, geht hier nicht. Muss sich das Programm drum kümmern. Okay, gibt das Konstrukt mit dem Cluster halt nicht her. Wer weiß schon, welchen Stand die Tabellen zur Zeit haben. Ich sehe Datenmüll auf dem Datenbanksystem vor mir.

Was es auf Grund des Cluster-Systems auch nicht gibt, ist mein heiß geliebtes Auto-Increment. Also dass die Datenbank selber mitzählt. Auch das geht nicht. Kann ja sein, dass Node 1 schon bei 728 ist, Node 10 aber erst bei 17. Wenn man einen Identifier braucht, dann bietet sich nur UUID an. Wer ne Reihenfolge in seinen Einträgen haben will, kommt wohl um einen Timestamp nicht drum rum. Da wäre es ja clever, den einfach als Default beim Insert zu setzen. Wäre ja unkritisch. Ja, vergiss es… Gibt’s auch nicht.
Will ich was in der Datenbank haben, muss ich mich um alles selber kümmern. So sinnig oder unsinnig es auch sein mag.

Das war der Moment, in dem in meinem Kopf ein Luftballon sehr viel Luft verloren hat und schlapp in der Ecke gelandet ist.

…aber Vorteile?

Ich glaube, die Vorteile spielt noSQL erst aus, wenn man in einem Netzwerk viele Instanzen davon hat. Also einen räumlich verteilten Cluster, der nicht mehr zwangsweise an einem Ort stehen muss. Denn klassische Datenbanken im Cluster haben wir bei uns im RZ auch. Auch die syncen sich. Sogar wesentlich unkomplizierter. Und ich glaube, die Diskussion über Performance würde ich mit unserem Datenbank-Admin verlieren. Haushoch.

Was bleibt also nach zwei Stunden Apache Cassandra an einem verregneten Nachmittag? Aus Entwicklersicht nicht viel. Gegenüber einer relationalen Datenbank ist es funktional für mich eher ein Rückschritt. Viel zu viel Zeug um das ich mich auf einmal selber kümmern müsste, Features die ich selber implementieren müsste, ohne dass ich aus Entwicklersicht einen Mehrwert habe. Es ist ne Datenbank. Ohne Magie ohne alles.

Für den Betrieb sieht das sicher ein Stück anders aus: Meine Datenbank muss nicht mehr (nur) an einem Ort stehen sondern die Nodes müssen sich über’s Netz nur kennen. Ob ein Teil in Flensburg, ein Teil in München und einer im Ruhrgebiet steht, ist eigentlich egal. Die Datenbank sorgt schon dafür dass überall die gleichen Daten sind. Und wenn’s doch mal knallt und ein Node kaputt geht, betanken ihn die anderen dann schon wieder. Anders müsste ich das selber mit einem komplizierten Push- oder Sync-Verfahren selber machen.

Tja, aber der mystische Ruf von noSQL-Datenbanken ist bei mir erstmal dahin. Doch alles nur mit Wasser gekocht. Schade.