Cassandra ist eine noSQL Datenbank, die insbesondere im Kontext großer Datenmengen bei sehr hoher Verfügbarkeit eingesetzt wird. Dabei ist bei Cassandra entscheidend, dass das Schema passend zu den jeweils zu unterstützenden Anwendungsfällen konzipiert ist: Nur so werden die hohe Geschwindigkeit von Cassandra und die Verfügbarkeit sichergestellt.

Doch Anforderungen können sich ändern, und damit muss auch die Anwendung angepasst werden. Das kann sich auch auf die Datenstrukturen in Cassandra auswirken.
Ein Weg, damit umzugehen, sind Cassandra Materialized Views oder ein kompletter Datenexport als CSV und Re-Import. Bei den für Cassandra typischen großen Datenmengen ist das selten praktikabel.

Unabhängig davon, ob man sehr kleine Datenmengen in Cassandra vorhält, zum Beispiel zur Entwicklungszeit, oder eine spezielle Migrationsanwendung für den produktiven Einsatz mit Cassandra erstellt: Die Migrationen sollten sich einfach verwalten und in der Versionskontrolle ablegen lassen.

Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt.
Für eine einzelne Umgebung funktioniert das Verfahren soweit ganz gut. Wenn jedoch verschiedene Varianten, z.B. für mehrere Umgebungen, bereitgestellt werden sollen, steigt der Aufwand und auch das Risiko von Configuration Drift. Helm tritt an, um dabei Abhilfe zu schaffen.

Cassandra 4 ist ein lang erwartetes Release der Cassandra Datenbank. Dabei hat sich nicht nur einiges in der Datenbank selbst geändert, sondern auch die Java Libraries für den Zugriff haben einige API Änderungen erfahren.
In dem Zuge sind viele andere Projekte aktuell noch nicht soweit, gute Unterstützung für Cassandra 4 zu bieten. Spring Boot bzw. Spring Data Cassandra ist jedoch bereits soweit, dass aktuelle Treiber genutzt werden. Dort stellt sich die Frage, wie das Thema Unit Test bzw. Integrationstest mit Cassandra 4 umgesetzt werden kann.