Vergleich der Implementierung (Teil 5)

Die Finanzverwaltung existiert nun in zwei Architekturen. Nun kein ein Vergleich erfolgen. Welches ist für eine private Anwendung die sinnvollere Architektur?

Die folgenden Kriterien zieht der Vergleich heran:

  • Größe der Programmdatei
  • Performance
  • Komplexität der Weiterentwicklung

Nach dem Vergleich folgt die Bewertung. Hierdurch ist die Entscheidung für eine zu wählende Architektur möglich.

Größenvergleich

Ohne dem kommen die Kerl doch nie aus *g*. Allerdings ladet der Inhalt der Archive erst mal im Speicher. Folglich startet das Programm mit dem kleineren Archiv schneller und läßt mehr Freiraum für Daten. Mit 26,8 zu 44,7 MB haben hier klar die Events die Nase vorn. Bei den Events entfällt JPA mit allen zugehörigen Bibliotheken zudem die Datenbank. Folglich steckt hier auch sehr viel weniger in der Jar-Datei.

Vergleich der Performance

Den Vergleich der Performance gilt es zu differenzieren. Ich mag einmal die Event-Variante mit einer echten Datenbank-Version vergleichen, beide male landen die Daten in einer Datei. Allerdings teste ich auch die In-Memory-Datenbank, hierdurch versuche ich einen Vergleich zwischen der reinen Architektur zu ermöglichen. Denn hier zählt nicht die Zeit eines Dateizugriffs.

Die einzelnen Werte fasst die folgende Tabelle zusammen:

Kriterium Redux JPA-In-Memory JPA-Datei
Start-Zeit ohne Daten 2 s 4 -5 s 5 s
Start-Zeit mit Daten 2,5s  – 4,4 s
Konto lesen ohne Daten 4-5 ms 5 ms 5 ms
Konto lesen mit Daten 3 ms 4-5 ms 5 ms
Buchungen lesen 3-4 ms 11-12 ms 11 ms
Buchen 4 ms 12 ms 12 ms

Zunächst gilt es zu bemerken: wer misst misst Mist! Die Zahlen sind natürlich abhängig von meinem Rechner und was er sonst noch zu tun hat.

Zunächst gab es jeweils ein Warm-Up mit 3 lesenden bzw. 5 schreibenden Aufrufen. Die Buchungen je Konto habe ich gelesen nach 5 Warm-Up + 50 Buchungen. Mehr Buchungen auf einen Streich kann keine Oberfläche sinnvoll darstellen und folglich unrealistisch. Anschließend folgten weiter 1000 Buchungen, damit für einen Start mit Buchungen auch Futter da war. Die Startzeit mit Buchungen ist für Redux eine Herausforderung. Bevor es weiter arbeiten kann, hat es alle alten Actions zu lesen und zu verarbeiten. Natürlich dauert das umso länger, je mehr Action vorliegen.

Allgemein ist die Event-Verarbeitung schneller als die Datenbank-Alternative. Schließlich gibt es auch weniger technischen Overhead. Trotz der gut 1000 Buchungen ist selbst die Startzeit geringer als mit der Datenbank. Ich habe mal einen Start mit 10.000 Buchungen gemacht. Damit Dauerte der Redux-Start etwa so lange, wie die JPA.
Der Vergleich zwischen einer in Memory und einer in die Datei schreibenden Datei bringt dagegen keine nennenswerten Unterschiede.

Vergleich der Erweiterbarkeit

Wie steht es um die Erweiterbarkeit? Dazu möchte ich die Arbeitsschritte für das Einfügen einer neuen Entität aufzählen.

Schritte für die JPA-Implementierung

  • Zunächst ist eine Modell-Klasse anzulegen.
  • Die Modell-Klasse benötigt JPA-Annotationen
  • Es folgen das Repository und ggf.
  • Serviceklassen zur Darstellung neue Anwendungsfälle
  • Das Datenbankschema ist zu erweitern

Schritte für Redux

  • Auch hier ist eine Modell-Klasse anzulegen
  • Es folgen Action und Reducer für die neuen Anwendungsfälle
  • ggf. ist der Status zu erweitern.

Vergleich zwischen den Implementierungen

Ein generisches Speichern von Actions vorausgesetzt, ist Redux praktisch leichter umzusetzen. Die verwendeten Technologie ist dort schlicht Java. Reducer ggf. Filter auf den State sind reine Funktionen und somit auch recht leicht testbar. Im Gegensatz dazu sind im JPA-Umfeld unterschiedliche Techniken zu beherrschen: Annotationen, Spring-Data-Konventionen bzw. JQL-Abfragen, SQL für’s Schema – das ganze Datenbankabhängig. Abschließend sind etliche Tests eher Integrations- als Unittest.

finally

Unter dem Strich ist Redux kleiner und schneller, jedenfalls bei dieser Datenmenge. Bei einem deutlich größeren Datenvolumen, käme der Speicher des Redux ohne weitere Maßnahmen an seine Grenzen. Die notwendigen Erweiterungen könnten dann für die Datenbank sprechen.

Die gemessenen Zeiten sind generell für ein kleines Programm im Heimgebrauch zu vernachlässigen. Umso mehr wiegt die Erweiterbar- und Wartbarkeit. Hier ist der Redux-Ansatz weniger komplex.

Schnell und einfach spricht bei den gegebenen Annahmen mehr für den Redux-Ansatz. Folglich werde ich ihn weiter vorantreiben.

Happy coding!