Ich kann mich kaum daran erinnern, jemals ein Projekt umgesetzt zu haben, welches keine Datenbanken verwendet! Datenbanken sind für uns als Entwickler so fundamental wichtig und trotzdem sprechen wir wenig bis gar nicht darüber. Wir kennen unseren SQL oder Oracle Server in- und auswendig, mit all ihren Eigenheiten und Macken. Ja, wir lösen all unsere Probleme mit unserem bevorzugten relationalen Datenbanksystem. Wir lassen uns sogar dazu hinreissen, mit anderen Entwicklern darüber zu streiten, ob und weshalb unser ER-Baby nun das Beste ist, als ob wir als überemotionale Eltern beim Spiel unserer Kinder in einer Juniorliga zusehen würden. Während wir mit unseren Grabenkämpfen beschäftigt waren, entstanden ganz neue Datenbanken, welche uns neue Möglichkeiten schaffen und ungewöhnliche Antworten auf unsere alten und neuen Probleme geben.
In einer Trilogie von Blogposts möchte ich in die Welt der Datenbanken eintauchen und aufzeigen, was es ausserhalb der ER-Welt noch gibt und wie wir unsere zukünftigen Probleme damit lösen können. Alles Wissen, welches ich hier teile, stammt entweder direkt von mir, oder ich kann es durch meine Erfahrung als korrekt ausweisen.
Die Welt wie sie bisher war…
ERM, oder Entity-Relationship-Model Datenbanken sind bis heute der de facto Standard für Persistenzfragen (all jene, welche keine File-Persistenz nutzen!). Sie haben eine lange Geschichte, welche mit Vertretern wie DB2 beginnt und bis heute von Oracle und Microsoft dominiert wird. Sie sind in höchstem Masse optimiert und meist in ihrer Tiefe sehr komplex in Benutzung, Betrieb und für die Entwickler, welche sie benutzen. Wenn wir in die Softwareentwicklung im Jahr 2015 zurückschauen, sehen wir kaum noch Applikationen, welche für Desktop-PC’s entwickelt wurden! Moderne Applikationen werden für die Cloud entwickelt und sind von ihren Endgeräten sehr unabhängig oder agieren gar komplett im Hintergrund, ohne überhaupt ein Frontend zu haben! Moderne Applikationen müssen innert Tagen mit unvorstellbaren Nutzeranstürmen umgehen oder innert Minuten Milliarden von Neujahrgrüssen rund um die Welt zustellen! Anwendungsfälle in diesem Ausmass sind selten, treten aber trotzdem öfters auf als angenommen. Traditionelle ER-DBMS haben mit solchen Anwendungsfällen riesige Probleme, da sie nur äusserst begrenzt skalieren können. Wir können neue Anforderungen nicht mehr mit alten Möglichkeiten lösen, wir brauchen neue Lösungen zugeschnitten auf diese neuen Anforderungen. Diese beiden Aspekte werde ich hier etwas näher betrachten:
Neue Anforderungen
Schemaänderungen / Schemalosigkeit
Diskussionen über Datenbanken begnügen sich meist mit der Bewertung, welche Leistungen eine Datenbank im produktiven Einsatz bietet. Häufig wird komplett ausgeklammert, wie stark die Datenbank den Enwickler unterstützt oder gar behindert. Ein wichtiger Aspekt von ER-Datenbanken sind deren Schemata, welche definieren, welche Daten wo, wie und mit welchem Typ gespeichert werden. Solche Schemata sind oft stark mit der Struktur der Daten auf der Festplatte verknüpft und können nur unter grossem Aufwand geändert werden. Als Anwendungsfall könnte man eine ER-Tabelle mit Logeinträgen heranziehen. Solche Tabellen enthalten (unbereinigt) bald einige Milliarden Einträge. Eine einfache Schemaänderung (Erweiterungen sind oft fast problemlos) können Produktivsysteme schnell einmal während Stunden offline nehmen oder komplett auslasten!
Kein Schema zu haben erleichtert den Umgang ganz besonders bei der Migration grosser Datenmengen, indem irrelevante und obsolete Daten nicht mehr migriert oder ausgewertet werden müssen, sondern einfach in ihrer alten Form weiter bestehen können. Diese Eigenschaft ist besonders für Entwickler von grossem Vorteil, da sie so Schemaänderungen einfacher und schneller vornehmen können, was den Entwicklungszyklus einer Applikation stark beschleunigen kann!
Datenmengen
Sogar kleine Softwaresysteme können heute schnell grossen Mengen an Daten ansammeln, grössere Softwaresysteme sammeln heute bereits mit wenigen Nutzern Terabytes an Daten. Manchmal ertappt man sich als Entwickler dabei, Anforderungen von sich fern zu halten, weil die daraus resultierenden Datenmengen unsere ER-Datenbanken zu Fall bringen würden. Moderne Systeme müssen jedoch jederzeit bereit sein, auch in kürzester Zeit um mehrere Terabytes zu wachsen und trotzdem weiterzuarbeiten. Datenbanken müssen unsere Daten klassifizieren und entsprechend gewisse Einträge auf Kosten anderer schneller ausliefern.
Andererseits führen die Informationen, welche Endnutzer benötigen, sehr schnell zu grossen Abfragen, bei denen tausende Einträge aggregiert und zurückgegeben werden. Traditionelle ER-Datenbanken setzen dabei auf Datawarehouses – separate und oft bereits verdichtete Kopien der produktiven Daten. Diese sind aber im Betrieb sehr mühsam und in ihrer Flexibilität sehr eingeschränkt, da neue Auswertungen oft grosse Änderungen beim Auslesen und Verdichten der produktiven Daten zur Folge haben und erst ab jenem Zeitpunkt Informationen liefern, ab dem diese neue Pipeline läuft.
Moderene Applikationen setzen immer mehr darauf, Daten nicht mehr zu ändern, sondern neu zu schreiben. Diese Konzepte nehmen Duplikate der Daten bewusst in Kauf um Leistungsverlusten durch Sperrung der Daten vorzubeugen. Die daraus resultierenden Datenmengen sind fast unvorstellbar gross und stellen für traditionelle ER-Datenbanken eine unlösbare Aufgabe dar.
Klassifizierung der Daten
Niemand wirft gerne etwas weg. Um unsere Datenbanken in administrierbaren Grössen zu halten, bereinigen wir diese. Dies tun wir, weil ER-Datenbanken Klassifizierung von Daten nicht beherrschen und folglich Einträge nicht nach ihrer Verwendung klassifizieren können. Eine Bestellung, welche 10 Jahre alt ist, wird niemanden mehr interessieren, trotzdem behandeln ER-Datenbanken diese Daten genau gleich, wie momentan aktive Bestellungen, was wenig Sinn macht.
Ein Nutzer hat Verständnis dafür, dass sein Facebook-Post von vor 5 Jahren etwas länger zum Laden braucht als einer, welcher fünf Minuten alt ist. Eine Persistenz-Schicht sollte eine solche Entscheidung fällen können.
Echtzeit Informationen
Produktive DB-Installationen stehen eigentlich immer unter Last. Besonders aber, wenn die Nutzer rund um die Welt sitzen. Um Auswertungen zu erhalten, werden diese produktiven Datensätze stetig abgefragt, verdichtet und in Datawarehouses(DWH) gespeichert, wo sie dann – weil bereits verdichtet – schnell abgefragt werden können. Solche ETL-Prozesse sind aber in der Regel sehr komplex, müssen sauber programmiert werden und sind dadurch sehr starr. Werden neue ETL-Pipes in Betrieb genommen, können nur neue Daten, welche ab diesem Zeitpunkt hinzukommen ins DWH übernommen werden. Von modernen Systeme wird jedoch von Analysten erwartet, dass sie alle ihnen zur Verfügung stehenden Daten abfragen können, nicht nur jene von einem Zeitpunkt bis in die Gegenwart. Dies bedingt jedoch auch, dass produktive Daten abgefragt werden müssen.
Neue Möglichkeiten
Technische Fortschritte ermöglichen immer wieder neue Funktionen für Datenbanken. Bis heute versuchen ER-Datenbanken ihre Daten im oberen Speicherbereich der Festplatte abzulegen. Mit Magnetplatten macht dies auch wirklich Sinn. Leider ist dies heute nicht mehr der Fall. Datenbanken werden auf Flash-Platten, Disk-Arrays oder gar virtualisiertem Speicher betrieben, was der Lesegeschwindigkeit der Datenbank empfindlich schaden kann! Es gibt noch einige weitere neue Möglichkeiten, welche unsere Datenbanken nutzen könnten:
Nahezu unlimierter Speicher
Plattenspeicher kostet eigentlich nichts mehr. Bestehende ER-Datenbanken tragen diesem Umstand keine Rechnung. Sie sind darauf getrimmt, im sehr limitierten Speicherplatz der 90er Jahren zu überleben, genau dafür brauchen sie ein Schema. Sie benutzen dieses Schema dazu, Daten möglichst platzsparend und nahe beieinander abzulegen und sie dadurch schnell lesen zu können.
Ist Speicherplatz günstig, ist es nicht mehr so wichtig, einzelne Bytes zu sparen, dafür können mehr Metadaten zu den Einträgen gespeichert werden, welche im Gegenzug eine Suche beschleunigen können (Zeit-Speicherabhängigkeit).
Skalierbarkeit
Die Cloud ermöglicht es uns, innert Sekunden tausende Maschinen zu starten um einen Nutzeransturm zu bewältigen. Fast alle grossen ER-Datenbanken brüsten sich mit ihren Möglichkeiten, „linear“ skalieren zu können, faktisch ist es jedoch so, dass eigentlich niemand diese Möglichkeiten verwendet, sei dies aus Angst, die Leistung der DB gar zu schmälern, oder aber es fehlt das Know-How. Selbst wenn die Datenbank fast linear skalieren könnte, tut sie dies meist nicht, da Änderungen auf der DB stets mindestens einen Row-Lock zur Folge hat, welcher alle anderen laufenden Transaktionen blockiert. Diese Sperrungen können die Leistung eines Datenbankclusters schnell gegen die Nullmarke drücken.
Grossen Mengen Memory
Frühere Datenbanksysteme mussten daruf getrimmt sein, wenig Ressourcen (Speicher, Memory, CPU-Cycles) zu verwenden, da diese Ressourcen teuer und knapp waren. Dieses Problem haben wir heute nicht mehr. Wenn wir heute einen In-House-Server bauen fragen wir uns nur noch, ob wir nun statt 512Gb Hauptspeicher lieber ein Terabyte einbauen. Höchstwahrscheinlich passen die produktiven Daten von 80% aller Datenbanken weltweit in 512Gb Memory. Herkömmliche ER-Datenbanken tragen auch diesem Umstand keine Rechnung und speichern Daten höchstens temporär im Memory, danach aber kommen sie auf die langsame Festplatte. Besser wäre jedoch eine Unterscheidung machen zu können, welche anhand eines Kriteriums bewertet, ob Daten nun im Memory, auf SSDs oder auf der Festplatte gespeichert werden. Ein Entwickler muss dieses Kriterium von aussen bestimmen können, da nur er abschätzen kann, welche Daten wohin gehören könnten.
Transaktions- und Schemalosigkeit
Transaktionen und Schemata bremsen Datenbanken aus und bringen im 21. Jahrhundert nur wenig Vorteile. Hätte jemand in den 90iger Jahren empfohlen, kein Schema zu verwenden, wäre er ausgelacht und ignoriert worden. Heute können viele Entwickler gut auf ACID-Garantien, Transaktionen und Schemata verzichten. Diese Entwicklung ermöglicht ganz neue Datenbanksysteme mit radikal anderen Ansätzen und nie dagewesenen Leistungsdaten.
Neue Anforderungen treffen auf alte Lösungen. Als ich ER-Datenbanken kennenlernte wurden sie für mich zum Hammer und da ich nun einen Hammer hatte, wurde jedes Problem zum Nagel. Ich bin nicht alleine: Bis heute versuchen wir mit ER-Datenbanken unsere Anforderungen zu erschlagen und schaffen uns mehr Probleme als Lösungen. Als ob wir nicht gemerkt hätten, dass unser Problem eine Schraube ist, versuchen wir sie mit unserem Hammer in ihr Gewinde zu schlagen. Alles was wir damit erreichen ist ein kaputtes Gewinde und wenn die Schaube trotzdem halten sollte, tut sie das eher schlecht als recht.
Wir haben sie aber die neuen Antworten auf unsere neuen Probleme, diese werde ich in den nächsten zwei Blog-Posts aufzeigen. Das eine sind Dokumentendatenbanken, das andere Graphendatenbanken. Wichtig ist jedoch, dass wir bereit sind, unsere Probleme auch als Schrauben zu sehen (nicht als Nägel) und uns auf neue Werkzeuge einlassen, auch wenn es gerade einfacher wäre, den Hammer weiter zu benutzen!
Viel Spass mit den Follow-Ups!
