Datenbanken sind langsam

Klar sind sie das. Datenbanken machen IO und IO ist generell nicht so wahnsinnig schnell. Und Datenbanken sind unendlich kompliziert und generell mit enorm viel Wartung verbunden und eigentlich total Überflüssig.

Für diese Probleme sehe ich bei meinen Codereviews immer wieder mehr oder minder originelle Lösungen.

Lösung: Alles im Speicher

Man verwaltet einfach alle Daten in einem großen Objektbaum, der dann hin und wieder auf die Festplatte serialisiert wird. Bei Programmstart wird das serialisierte Objekt mit allen Daten einfach geladen und Rock ’n‘ Roll.

Das funktioniert von mir aus einigermaßen mit der berühmten „Video Verwaltung“, die man gerne mal während des Studiums baut, und mag auch noch in kleinen Startups funktionieren, die einen Onlineshop mit 1000 Artikeln haben, aber da liegt dann auch schon das Problem: Bleibt es bei 1000 Artikeln, ist das Startup irgendwann Geschichte und die Lösung hat bis zum Schluss funktioniert. Der schlimmere Fall: das Startup wächst und irgendwann hat man 1 Mio Artikel. Die passen jetzt irgendwie nicht mehr in den Speicher. Mal ganz davon zu schweigen, dass das Serialisieren eines riesigen Objektbaums auf die Festplatte nicht wirklich transaktional ist. Das bedeutet, wenn etwas schief geht, geht es schief und die Daten sind weg. Konkurrierende Schreibzugriffe (Datensätze werden von mehreren Personen gleichzeitig bearbeitet) sind zwar total gut mit Time Slots zu lösen (von 9-11 Uhr darf nur die eine Abteilung ihre Daten bearbeiten, von 11-13 Uhr die nächste), aber das ist bei vielen Datensätzen nicht mehr wirklich praktikabel.

Also merke: Die Problemstellung der Video Verwaltung als Hausaufgabe während des Studiums war dazu da, grundlegende Datenstrukturen zu erklären und nicht als Lösungsvorschlag für kommerzielle Anwendungen.

Lösung: Ich suche alles selbst

Spätestens seit Hibernate ist es total einfach, Objekte statt direkt auf die Platte in eine Datenbank zu schreiben. Das ist schon mal gar nicht so schlecht. Der Vorteil ist, dass man nun Datensätze einzeln und in einer Transaktion speichert. Wenn da mal was nicht klappt, fehlt ein Datensatz, die restlichen Daten sind noch intakt. Auch können jetzt alle Abteilungen gleichzeitig an den Daten arbeiten. Das beste aber, der Code sieht fast wie normales Java aus. Die bösen Sachen übernimmt beispielsweise JPA für uns. Und da das alles so total nach Java aussieht und man total bekannte Datenstrukturen wie Listen aus der Datenbank kriegen kann, kann man da mit der hübschen for-Schleife aus Java 5 durchiterieren und sich die Daten mit if-Abfragen raus suchen, die einen interessieren.   Alles was man braucht, ist für jede Tabelle eine „finde Alles“ Methode und ab geht’s. Man kann sogar total nett mit dem Collection Framework seine Daten nach eigenen Kriterien sortieren.

Das ganze hat nur ein Problem: es ist total ineffizient und produziert Unmengen von absolut unnötigem Code.

Datenbanken machen Datensachen!

Eben weil man meist nur bestimmte Datensätze braucht, und diese nach bestimmten Kriterien sortiert sein müssen, haben vor ungefähr 500 Jahren schlaue Computerwissenschaftler die Abfragesprache (Query Language) erfunden. Ganz, ganz kalter Kaffee? Das ist schon so lange her, das kann heute gar nicht mehr rocken?

Viel, viel schlimmer: Die Sache wird seit Generationen an allen Ecken und Enden verbessert, aktualisiert, modernisiert. Man könnte davon ausgehen, dass es ziemlich schwer wird, sich als Allrounder mit einem Menschen anzulegen, der den ganzen Tag nichts anderes macht, als sich mit effizienter Datenhaltung zu beschäftigen. Im Fall von Datenbanken lagt man sich da aber mit Generationen von Entwicklern an, die unglaublich viele Arbeitsstunden in die Technik versenkt haben – und ja, die ganze Mühe kommt auch wieder raus, wenn man seine Abfragen über die dafür vorgesehene Sprache formuliert.

Klar, die muss man dafür erst mal lernen, aber der Aufwand dafür ist deutlich geringer, als das Rad jedes mal neu zu erfinden. Ein netter Einstieg in SQL ist beispielsweise Einführung in SQL. Von SQL zur Abfragesprache von JPA ist es kein weiter Weg und ein bisschen SQL können, hat noch niemandem geschadet.

Datenbanken können das wofür sie gebaut sind unverschämt gut: Daten verwalten. Und sie sind beispielsweise in Form von MySQL oder Postgesql frei verfügbar.

Selbst die klassische Video Verwaltung lässt sich super mit einer Datenbank erledigen. Natürlich will man für so eine einfache Desktopanwendung nicht unbedingt einen Datenbankserver installieren. Dafür gibt es dann embedded Datenbanken, wie z.B. DerbyDB.

Wenn man also Sachen mit Daten machen muss, nimmt man sich eine Datenbank – die kann das schon.

2 Gedanken zu „Datenbanken sind langsam

  1. Hans Müller

    wo du recht hast, hast du recht! hibernate & konsorten sind zwar angenehm zum entwickeln, was die geschwindigkeit betrifft allerdings unterste schublade… für anwendungen mit vielen usern gleichzeitig kaum zu gebrauchen.

    wenn schon hibernate, dann am besten die beans („dto“) für einen join erstellen, kein „rohes“ crud (create, read, update, delete) wo man für einen read-vorgang für jeweils eine abfrage SELECT * FROM Tabellenname macht, und anschliessend das ganze in 2 java.util.List’s, gefüllt mit dto’s, gegeneinander in 2 for-schleifen vergleicht… z.b. um einen join nachzubilden…

    wenn ich unbedingt sowas haben will, bastle ich mir das ganze eh selber, steh nicht so auf frameworks. dabei mache ich eine konstruktion aus dao’s (crud-grundoperationen), dto’s und einem service-layer für komplette db-operationen.

    gruss, hans

  2. tschuett Artikelautor

    Das nette an JPA ist, dass genau sowas damit total unproblematisch geht: Man baut sich einfach seine Abfrage zusammen und JPA ruft dann den entsprechenden Konstruktor des POJOs auf.
    SELECT NEW beispiel.MeinDAO(c.name, c.hauptstadt.name) FROM Land AS c
    Die Klasse muss eben nur den entsprechenden Konstruktor aufweisen. Wenn die JPQL abfragen sinnvoll formuliert sind, reicht es nach meiner Erfahrung schon für einen Großteil der Anwendungen dort draußen (auch gerne mit mehreren hundert parallelen Benutzern). Für Spezialfälle lassen sich die JPQL Queries aber auch durch „native“ SQL Queries überschreiben und der Code bleibt portabel. Ganz nett, wenn bestimmte Komponenten strategisch auf eine günstigere DB umgezogen werden sollen.
    Der Vorschlag von mir ist nicht, auf das Framework zu verzichten, sondern es zu benutzen und überdas Framework arbeit an die Datenbank auszulagern. Wenn ich mich für Java EE entscheide, habe ich den ganzen Luxus ja schon. Wozu sollte ich das Rad neu erfinden – außer ich bin facebook oder so was irres – aber dann funktioniert generell nichts von der Stange.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


+ sechs = 12