Warum Datenbanken und ihre Komplexität heute unnötig sind

Probleme von Datenbanken und warum ihre Komplexität unnötig ist

• Datenbanken sind globaler veränderlicher Zustand, was Code komplexer und schwerer verständlich macht.
• Datenmodelle sind eingeschränkt und können nicht alle Anwendungsfälle unterstützen, weshalb oft mehrere Datenbanken nötig sind.
• Das Spannungsfeld zwischen Normalisierung und Denormalisierung erzeugt einen Zielkonflikt zwischen Datenkonsistenz und Performance.
• Eingeschränkte Schemata verursachen zusätzliche Komplexität, weil Domänenmodelle an die Datenbank angepasst werden müssen.
• Komplexe Deployments erhöhen durch die Kombination und Integration verschiedener Tools Kosten und Komplexität.

Ein konsistentes Modell für den Aufbau von Application-Backends

• Die grundlegende Funktion eines Backends besteht darin, neue Daten entgegenzunehmen und Fragen zu diesen Daten zu beantworten.
• Ein ideales Backend-Design sollte dem Ideal so nahe wie möglich kommen und dabei reale Rahmenbedingungen erfüllen.

Rama

• Rama ist eine Plattform für die Backend-Entwicklung, die Mastodon neu implementiert und damit einen Dienst in Twitter-Größe bereitstellt.
• Rama implementiert alle Elemente eines Backends – Daten, Indizes, ETL, Abfragen usw. – auf allgemeine Weise.
• Rama vereinfacht komplexe Deployments und integriert Monitoring, wodurch Entwicklungs- und Wartungskosten deutlich sinken.

Meinung von GN⁺

• Das Problem des globalen veränderlichen Zustands in Datenbanken erhöht die Komplexität des Codes und die Fehleranfälligkeit; damit sind Entwickler häufig konfrontiert.
• Rama präsentiert einen neuen Ansatz, der die Grenzen bestehender Datenbanken überwindet und die Komplexität der Backend-Entwicklung reduziert.
• Dieser Beitrag bietet interessante und nützliche Informationen für Entwickler, die die Komplexität von Datenbanken und Backend-Systemen verringern möchten.

[GN⁺]

Hacker-News-Kommentar

• Man sollte ein Subsystem verwenden, das die Source of Truth repräsentiert, und ein weiteres Subsystem, das mehrere aus dieser Quelle abgeleitete Index-Speicher implementiert. Das ist die Kombination aus Event Sourcing und Materialized Views.

  • Event Sourcing und Materialized Views: Die Lösung besteht darin, das System, das die Source of Truth repräsentiert, und die darauf basierenden Index-Speicher getrennt zu verwalten.

• Wir trennen Lese- und Schreibmodell: Das Schreibmodell ("Source of Truth") besteht aus einem traditionellen relationalen Domänenmodell, und fast jeder Befehl erzeugt ein Event, das in eine gemeinsame Domain-Event-Queue veröffentlicht wird. Das Lesemodell besteht aus Workern, die Events konsumieren und Views aufbauen.

  • Trennung von Lese-/Schreibmodell: Das Schreibmodell besteht aus einem relationalen Domänenmodell, und Befehle erzeugen Events, die in eine Domain-Event-Queue veröffentlicht werden. Das Lesemodell konsumiert die Events und baut daraus Views auf.

• Materialisierung bei Datenänderungen kann Vorteile bringen, wenn ein Produkt eine einzige Aufgabe sehr schnell ausführen muss. Probleme entstehen jedoch, wenn komplexe Transaktionen erforderlich sind oder neue Funktionen hinzugefügt werden sollen, die anders organisierte Daten benötigen.

  • Grenzen der Datenmaterialisierung: Sie ist nützlich, wenn auf eine einzelne Aufgabe optimiert wird, kann aber bei komplexen Transaktionen oder beim Hinzufügen von Funktionen mit neuen Datenstrukturen Probleme verursachen.

• Zu behaupten, dies sei als „Mastodon-Client im Twitter-Maßstab“ bewiesen, ist nicht möglich, solange man nicht tatsächlich eine Website mit 40 Millionen täglichen Nutzern betreibt.

  • Die Bedeutung von Skalierung: Eine tatsächlich großskalige Nutzerumgebung zu simulieren, ist unmöglich, weshalb sich eine solche Behauptung nur schwer stützen lässt.

• Ein besserer Ansatz ist die Kombination aus Event Sourcing und Materialized Views.

  • Kombination aus Event Sourcing und Materialized Views: Wird trotz der damit verbundenen zusätzlichen Komplexität als der bessere Ansatz dargestellt.

• Ein einzelnes Datenmodell kann nicht alle Anwendungsfälle abdecken.

  • Vielfalt von Datenmodellen: Es ist unmöglich, mit einem einzigen Datenmodell alle Anwendungsfälle zu unterstützen.

• Ich habe nichts gegen Datenbanken.

  • Gültigkeit von Datenbanken: Es gibt keine Einwände gegen Datenbanken; sie sind weiterhin ein gültiges Werkzeug.

• Fehlen hier nicht Konzepte wie Nebenläufigkeit, Isolation und Constraints? Ist „Query Topology“ der Entwicklererfahrung wirklich überlegen?

  • Fragen zu Query Topology: Es wird infrage gestellt, ob wichtige Konzepte wie Nebenläufigkeit, Isolation und Constraints fehlen und ob Query Topology der Entwicklererfahrung tatsächlich überlegen ist.

• Ich brauche eine ELI5-Erklärung zu Rama. Die Dokumentation ist verwirrend, und bitte keine Buzzwords wie „Paradigmenwechsel“ oder „Plattform“.

  • Bitte um eine einfache Erklärung zu Rama: Gewünscht wird eine leicht verständliche Erklärung zu Rama ohne Buzzwords.

• Event Sourcing (+ Materialized Views und Indizes) bedeutet nicht, dass man ein RDBMS wegwirft. Man kann beides zusammen verwenden.

  • Koexistenz von Event Sourcing und RDBMS: Event Sourcing und Materialized Views können zusammen mit einem RDBMS eingesetzt werden; beides schließt sich nicht gegenseitig aus.

Hintergrundwissen:

• Event Sourcing: Ein Entwurfsmuster, bei dem Zustandsänderungen eines Systems als Events aufgezeichnet werden, sodass sich der Zustand des Systems durch deren Wiedergabe rekonstruieren lässt.
• Materialized Views: Eine Technik, bei der die Ergebnisse von Datenbankabfragen physisch gespeichert werden, um die Leseleistung zu verbessern.
• RDBMS (Relational Database Management System): Ein System zur Verwaltung relationaler Datenbanken.