Hatte endlich mal Gelegenheit mich mit einer NoSQL Datenbank zu besch\u00e4ftigen: Cassandra von Apache. Allerdings f\u00fchlte ich mich aus Anwender – in meinem Fall also Anwendungsprogrammierer – in die Steinzeit der Datenbankprogrammierung zur\u00fcckversetzt: es gibt nur\u00a0propriet\u00e4re\u00a0Schnittstellen und die sind auch nicht abgek\u00fcndigt (Thrift). Selbst Apache\u00a0empfiehlt\u00a0auf ein abstrakteres API wie zum Bespiel Hector zu setzen.<\/p>\n
Leider f\u00fchlt sich auch Hector in keiner Weise so an wie man es von konventioneller Datenbank-Programmierung gewohnt ist. Das Java-API ist nach meinem Geschmack “gew\u00f6hnungsbed\u00fcrftig” um es einmal diplomatisch auszudr\u00fccken.<\/p>\n
Dabei gibt mit Spring-JDBC (oder neuerdings mit Spring-Data) l\u00e4ngst gute Beispiele wie man es gut machen kann. Jetzt kann man nat\u00fcrlich einwenden, dass diese “alten” Ans\u00e4tze f\u00fcr SQL-Datenbanken gemacht sind und sich daher nicht f\u00fcr NoSQL L\u00f6sungen eignen, aber wenn man zweimal hinsieht, dann merkt man schnell, dass das gar nicht stimmt.<\/p>\n
Der Unterschied bei der Sicht auf die Daten besteht meiner Meinung nach im Wesentlichen im Datenmodell, oder in der Art wie man zum Datenmodell kommt: entweder klassisch relational und normalisiert, oder Abfrage-Orientiert und\u00a0de-normalisiert.<\/p>\n
Wenn das Datenmodell aber steht, lie\u00dfe sich mit den Daten eigentlich genauso arbeiten wie mit SQL-Datenbanken: \u00fcber eine Abfrage-Sprache. Im Falle von Cassandra ist das CQL. Parallelen gibt es mit Keyspace = Database, ColumnFamily = Tabelle, und Column \/ Row genug. Die Einschr\u00e4nkungen \/ Erweiterungen con CQL sind eben der Datenbank geschuldet (z.B. kein Join) und st\u00f6ren erst mal nicht, wenn man sich f\u00fcr das NoSQL Modell entschieden hat.<\/p>\n
Jetzt gibt es mit Cassandra-JDBC sogar einen JDBC-Treiber f\u00fcr Cassandra, der auch CQL \u00fcber JDBC in jeder Java-Anwendung verf\u00fcgbar macht. Man sollte also meinen alles Handwerkzeug in H\u00e4nden zu halten, um “vern\u00fcnftig” arbeiten zu k\u00f6nnen.<\/p>\n
Leider ist dem im aktuellen Release 1.0.5 (Dez 2011) von Cassandra nicht so.<\/p>\n
Die Umsetzung ist etwas l\u00fcckenhaft, so dass praktisch bei jeder anderen Anwendung (au\u00dfer “Hello World”) Probleme auftreten.<\/p>\n
Spalten sind nicht l\u00f6schbar<\/strong><\/p>\n Will man eine Spalte l\u00f6schen, dann wird man im normalen SQL ein UPDATE … Feldname = NULL verwenden, was aber beide Spaltenorientierten Cassandra mit CQL nicht funktioniert. Dort muss stattdessen die Spalte selbst gel\u00f6scht werden mit DELETE Column(s) FROM ColumnFamily WHERE …<\/p>\n Unn\u00f6tig umst\u00e4ndlich wie ich finde. Man ist gezwungen UPDATES auf Rows in ein UPDATE und ein DELETE Statement aufzuspalten, wenn man einen Teil der Spalten l\u00f6schen will. Gerade weil Cassandra aber kein festes Schema mit beliebig vielen Spalten, die auch nicht notwendigerweise gef\u00fcllt sein m\u00fcssen, unterst\u00fctzt, ist dies doppelt \u00e4rgerlich.<\/p>\n Selects auf NULL-Spalten funktionieren nicht<\/strong><\/p>\n Wie schon erw\u00e4hnt wird man in einer Cassandra Persistenz sicher h\u00e4ufig auf Rows treffen, bei der nicht alle Spalten mit Werten belegt sind. Statt bei einer CQL Anfrage dann aber NULL, oder zumindest in der JDBC Darstellung NULL bzw. den passenden Default zu liefern, stolpert man \u00fcber eine Exception. Man kann gar keine Spalten abfragen, die nicht gesetzt sind.<\/p>\n Unzureichende Expression-Language<\/strong><\/p>\n Cassandra kennt zwar bestimmte Typen Spalten. Allerdings liefert CQL kaum ausreichen Ausdrucksm\u00f6glichkeiten mit diesen Typen umzugehen. Man kann nicht einmal einen Timestamp erzeugen, ausser den nackten Long-Wert direkt einzugeben, um nur ein Beispiel zu geben. Dies erschwert die Formulierung von Abfragen wiederum unn\u00f6tig. Man h\u00e4tte leicht bestehende Implementierungen von ELs adaptieren k\u00f6nnen, um halbwegs verwendbare Ausdr\u00fccke in CQL einsetzen zu k\u00f6nnen.<\/p>\n PreparedStatements funktionieren nicht<\/strong><\/p>\n In JDBC ist es eigentlich der Normalfall PreparedStatements zu nutzen. Nicht nur weil man dem Server Gelegenheit gibt, die Anfragen zu optimieren, auch Injection wird damit wirkungsvoll verhindert. Leider unterst\u00fctzt Cassandra 1.0.5 solche Anfragen bislang nicht. Der JDBC-Treiber bietet sie dennoch an.<\/p>\n Wie man in der Beschreibung und im Quellcode nachlesen kann, werden die Bindings jedoch schon auf der Clientseite aufgel\u00f6st und dann zum Server geschickt. Damit k\u00f6nnte man leben, wenn das wenigstens funktionieren w\u00fcrde. Leider ist auch hier die Implementierung fehlerhaft, sodass oft genug die Bindung schlicht falsch ist und der Server die Anfrage mit einem Fehler quittiert.<\/p>\n Fazit<\/strong><\/p>\n Will man Cassandra einsetzen, hat man sich so an das eine oder andere zu gew\u00f6hnen (oder wieder zu gew\u00f6hnen). Und damit meine ich nicht in erster Linie die Art der Datenmodellierung. Ich jedenfalls f\u00fchlte mich in mancher Hinsicht um eine paar Jahre in die Vergangenheit zur\u00fcck versetzt, als man mit Oracle noch per Oracle Call Interface (OCI) sprechen musste. Aber wenns denn Cassandra sein muss …<\/p>\n","protected":false},"excerpt":{"rendered":" Hatte endlich mal Gelegenheit mich mit einer NoSQL Datenbank zu besch\u00e4ftigen: Cassandra von Apache. Allerdings f\u00fchlte ich mich aus Anwender – in meinem Fall also Anwendungsprogrammierer – in die Steinzeit der Datenbankprogrammierung zur\u00fcckversetzt: es gibt nur\u00a0propriet\u00e4re\u00a0Schnittstellen und die sind auch … Weiterlesen