Datenmodellierung für Apache Cassandra

Cassandra ist eine Datenbank, die nicht eindeutig in die 5 Kategorien der NoSQL-Datenbanksysteme eingeordnet werden kann: Einesteils ist sie Spalten-orientiert, andererseits wird für den effizienten Zugriff auf Daten ein “Partition Key” benötigt, also ein eindeutiger Primärschlüssel. Dies entspricht damit eher einem Key-Value-Store. Die Datenmodellierung für Apache Cassandra muss diese Besonderheiten berücksichtigen, um eine effiziente Datenverarbeitung ermöglichen zu können. Weiterlesen

Weiterlesen

Garbage Collection

Garbage Collection und Java Virtual Machine

Alle erzeugten Objekte werden im Heap-Speicher der JVM (Java Virtual Machine) abgelegt. Da aber dieser Speicherbereich nicht unendlich groß ist, müssen die nicht mehr benötigten Objekte wieder entfernt werden. Diese Aufgabe könnte uns als Entwickler obliegen. Doch wir haben Glück: Java kennt eine automatische Speicherbereinigung, die Garbage Collection (Übersetzt: Müllabfuhr). Alle nicht referenzierten Objekte werden aus dem Heap-Speicher entfernt.
Trotzdem kann es durch unachtsame Programmierung zu Speicherlecks (Memory Leaks) kommen. Wenn eine nicht mehr benötigte Referenz noch ein Objekt, dies kann auch eine sehr große Collection sein, referenziert, wird dieses Objekt eben nicht aus dem Speicher entfernt. Weiterlesen

Weiterlesen

Referenzen und Objekte

Objekt-orientierte Programmierung ist bekanntermaßen ein sehr verbreitetes Konzept zur Modellierung komplexer Anwendungen. Die Programmiersprache Java hat bereits seit ihrer Einführung 1995 dieses Konzept aufgenommen. Auch die Laufzeitumgebung, also die Java Virtual Machine (JVM) berücksichtigt dieses Konzept und implementiert deshalb ein Speichermodell, das auf Referenzen und Objekte ausgerichtet ist.

Stack und Heap

Der Speicher der Java Virtual Machine ist in einen Stack- und einen Heap-Bereich unterteilt.

Stack und Heap der JVM

Diese Unterteilung ist zwar etwas grob, genügt aber für die folgende Betrachtung völlig.

Jede Java-Methode bekommt ihren eigenen Stack-Bereich zugeordnet. Innerhalb des Stacks werden sämtliche lokalen Variablen abgelegt. Wie im Objekt-orientierten notwendig sind diese Variablen in Java stets Referenzen auf Objekte. Diese werden im Heap-Bereich abgelegt.

Dies sei am Beispiel der folgenden main-Methode aufgezeigt:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
}

Im Speicher der JVM ergibt sich das folgende Bild:

Die main-Methode mit den lokalen Variablen message und names

Methodenaufruf

Nun definieren wir eine zweite Methode, called, diesmal mit 2 Parametern

public static void called(String str, String[] list){

}
Die methoden called mit den beiden Parametern str und list

Diese Methode wird aus main heraus aufgerufen:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
}

Wie erfolgt nun jedoch die Übergabe der lokalen Variablen message und names in die Parameter str und list?

Wie werden die Parameter belegt?

Dazu wird die JVM die Werte der Referenzen als Kopie übergeben, also ein “CallByValue”-Verhalten auf der Ebene der Referenzen:

Copy By Value mit Referenzen

Im Endeffekt zeigen die Referenzen auf die selben Objekte im Heap.

Zuweisung von Werten

Was passiert aber nun, wenn in der aufgerufenen Methode den Parametern neue Werte zugewiesen werden? Hier ergibt sich ein feiner aber unglaublich wichtiger Unterschied: Belegen wir den Parameter str einfach mit einem neuen Wert, z.B. mit

str = "Goodbye";

so wird die Variable im Stack einfach mit einer Referenz auf das neue Objekt im Heap überschrieben:

Zuweisung eines neuen Wertes an den Parameter str

Wichtig hier ist, dass in der aufrufenden main-Methode die Variable message davon völlig unbeeinflusst bleibt.

Was passiert aber, wenn wir die Referenz auf das Array benutzen, um beispielsweise den Wert des zweiten Elements mit Index 1 auf “Paul” zu setzen?

list[1] ="Paul";

Nun ergibt sich ein anderes Bild:

Zuweisung eines neuen Wertes an das zweite Element der Liste

Hier ist klar ersichtlich, dass diese Änderung des Array-Objekts innerhalb der Methode called auch direkt Auswirkungen auf die aufrufende main-Methode hat: Nachdem die Methode called terminiert ist referenziert auch die Variable message auf das Array, dessen zweites Element nun auf “Paul” zeigt.

Also innerhalb von main

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
System.out.println(names[1]); //-> Paul
}

Zusammenfassung und Ausblick

Durch die Betrachtung des Speichermodells der Java Virtual Machine wird die Arbeitsweise eines Objekt-orientierten Programms unter Verwendung von Referenzen klar und verständlich. Das komplette Beispiel liegt als fertiges Eclipse-Projekt vor und enthält zusätzlich Konsolen-Ausgaben, die den Ablauf des Programms demonstrieren. Selbstverständlich kann aber auch der Eclipse-Debugger benutzt werden, um die Ausführung nachzuvollziehen.

Allerdings sind sicherlich auch noch einige Punkte nicht fundiert behandelt worden:

  • Das vorgestellte Speichermodell ist stark vereinfacht. Wie schaut es denn tatsächlich aus?
  • Was passiert eigentlich mit dem armen Objekt “Fritz”, das nun komplett losgelöst im Heap vorhanden ist?

Diese beiden Punkte werden in einem folgenden Artikel, der den Garbage Collector der JVM als Thema hat, behandelt.

Seminar zum Thema

Weiterlesen

Weiterlesen

Docker Compose

Übersicht: Was ist Docker Compose?

Die Definition eines Docker-Containers erfolgte bisher durch die Parametrisierung des docker create-Befehls. Dies wurde so auch in früheren Artikeln so beschrieben und ist auch ein durchaus korrekter Ansatz. Allerdings werden diese Befehle spätestens in dem Moment sehr unhandlich und unübersichtlich, wenn mehrere Container miteinander verlinkt werden und damit voneinander abhängig sind.

Mit Docker Compose wird die Definition verlinkter Container besser gelöst: Statt eines Aufrufs von docker createmit vielen Parametern werden diese in einer einfach strukturierten Textdatei abgelegt. Als Dateiformat hat sich die Docker-Community für YAML entschieden, eine sinnvolle und nachvollziehbare Entscheidung.

Damit wird werden Dependencies zwischen Docker-Containern deutlich vereinfacht. Dies kann auch sofort dem WordPress-Beispiel aus der Docker Compose-Dokumentation entnommen werden:

 

version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {}

Selbst ohne bisherige Kenntnisse in Docker Compose ist einem Leser mit Docker-Hintergrund sofort klar, was mit dieser Datei bezweckt werden soll:

  1. Es wird ein MySQL-Container aus dem mysql:5.7-Image erzeugt.
  2. Dieser benutzt ein Volume namens db_data
  3. und wird automatisch gestartet, sobald die Docker-Engine aktiv ist.
  4. Benutzername, Passwort und der Name der Datenbank werden über Environment-Parameter gesetzt.
  5. Ein weiterer Container beruht auf dem wordpress:latest-Image und stellt einen WordPress-Server bereit.
  6. Auch hier erfolgt die Konfiguration über Environment-Parameter, zusätzlich erfolgt ein Port-Mapping.
  7. Mit depends-on wird dieser Container aber nun mit dem MySQL-Container verlinkt. Damit steht für beide Container ein gemeinsames Netzwerk bereit, so dass der Web Server von WordPress direkt auf den MySQL-Server zugreifen kann.

Falls nun Docker Compose installiert ist wird diese Information ganz einfach in einer Datei namens docker-compose.yml abgelegt.

Und dann genügt tatsächlich der Befehl docker-compose up, um die gesamte Anwendung zu starten!

Einige Details

Installation

Die Installation ist detailliert hier beschrieben, wird aber hier exemplarisch für eine Linux-Distribution, z.B. SLES 12, durchgeführt:

Als erstes wird die für die Distribution relevante Compose-Version von GitHub geladen und ausführbar gemacht:

sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose

chmod +x /usr/local/bin/docker-compose

Zusätzlich kann die Bash-Completion installiert werden:

curl -L https://raw.githubusercontent.com/docker/compose/1.21.2/contrib/completion/bash/docker-compose -o /etc/bash_completion.d/docker-compose

Ab jetzt sollte der Befehl docker-compose verfügbar sein, also beispielsweise

docker-compose -v

Arbeitsweise

Docker Compose ist keine Erweiterung der Docker-Engine sondern “nur” ein Generator für Docker Befehle auf Grundlage der yml-Datei. So erzeugt der up-Befehl von docker compose ganz normale Docker-Container, die beispielsweise über ein docker ps aufgelistet werden können. Entsprechend wird der down-Befehl diese Container wieder löschen.

Kommando-Referenz

Selbstverständlich müssen die über docker compose definierten Container nicht jedesmal erneut mit up erzeugt werden. Zum Starten und Stoppen dienen die Befehle start und stop, die die vorhandenen Container benutzen.

Die vollständige Kommando-Referenz ist Bestandteil der Docker-Compose Dokumentation, ebenso die Command Line-Befehle.

Compose und Build-Prozess

Für eine agile Entwicklung kann die docker-compose.yml auch ein Dockerfile angeben und vor der Erstellung der Container erst einmal das zugehörige Image neu bauen. Damit kann compose auch sinnvoll in den Buildprozess einer Docker-Anwendung integriert werden.

  Weiterlesen

Weiterlesen