Datenbankserver und eingebettete Datenbanken: Vergleich von Architektur und E/A-Merkmalen

Datenbankserver

Ein Datenbankserver bezeichnet eine Datenbank, die als eigenständiger Serverprozess ausgeführt wird und Anfragen von Anwendungen über das Netzwerk verarbeitet. Die meisten uns vertrauten RDBMS, wie MySQL, PostgreSQL oder Oracle DB, entsprechen diesem Modell. Datenbankserver bieten die folgenden Vorteile.

• Zentralisierte Verwaltung: Die Daten werden an einem Ort integriert verwaltet, wodurch Konsistenz, Sicherheit sowie Sicherung und Wiederherstellung erleichtert werden.
• Ressourcenunabhängigkeit: Durch die Zuweisung eigener CPU-, Speicher- und Speicherressourcen wird unabhängig vom Zustand der Anwendung eine stabile Leistung gewährleistet.
• Hohe Parallelität und Skalierbarkeit: Die Systeme sind für den gleichzeitigen Zugriff vieler Nutzer optimiert, und die horizontale Skalierung durch Clustering oder Replikation ist vergleichsweise unkompliziert.

Aufgrund dieser Eigenschaften hat sich der Datenbankserver in den vergangenen Jahrzehnten als Standard der Softwareinfrastruktur etabliert. Durch technologische Entwicklungen und veränderte Umgebungsbedingungen treten die Nachteile des Datenbankservers in einigen Umgebungen jedoch zunehmend hervor, weshalb eingebettete Datenbanken als Alternative erneut Aufmerksamkeit gewinnen.

Neue Entwicklung: Eingebettete Datenbanken

Eingebettete Datenbanken sind Datenbank-Engines, die ohne separaten Serverprozess als Bibliothek in eine Anwendung eingebunden werden und innerhalb desselben Prozesses ausgeführt werden. SQLite, LevelDB und RocksDB gelten als typische eingebettete Datenbanken. Die Gründe, weshalb sich eingebettete Datenbanken in der aktuellen technologischen Umgebung als starke Alternative etabliert haben, sind folgende.

• Das Aufkommen von SSDs

  In den früheren, von HDDs geprägten Systemumgebungen war die Leistung beim wahlfreien Zugriff im Vergleich zum sequenziellen Lesen und Schreiben von Daten deutlich geringer. Daher bestand der Kern der Leistungsoptimierung darin, die Festplatten-E/A zu minimieren und das Speicher-Caching zu maximieren. Datenbankserver betrieben entsprechend große Caches und überwanden die physikalischen Grenzen der HDDs, indem sie Schreibvorgänge bündelten.

  Das Aufkommen von SSDs hat diese Prämisse jedoch grundlegend verändert. SSDs sind bei wahlfreien E/A-Operationen um ein Vielfaches schneller als HDDs, und ihre Latenzzeit ist erheblich kürzer. Infolgedessen hat die bisherige Auffassung, dass die Festplatten-E/A den größten Engpass darstellt, an Gültigkeit verloren, und stattdessen rückte die Latenz beim Zugriff auf einen entfernten Datenbankserver über das Netzwerk als neuer Engpass in den Vordergrund.

• MSA und Datenunabhängigkeit

  In der Vergangenheit war die Struktur, in der eine große monolithische Anwendung von einer einzigen zentralisierten Datenbank abhängt, weit verbreitet. Dieser Ansatz ist zwar einfach, führt jedoch mit wachsendem Dienstumfang zu Schwierigkeiten bei Änderungen des Datenschemas und zu einer übermäßig starken Kopplung, da alle Dienste dieselbe Datenbank gemeinsam nutzen.

  In modernen Microservice-Architekturen wird zur Lösung dieser Probleme das Prinzip "Database per Service" als wichtig erachtet. Indem jeder Dienst seinen eigenen dedizierten Datenspeicher besitzt und diesen kapselt, wird die Unabhängigkeit zwischen den Diensten gewährleistet, und Fehlerisolierung sowie Skalierung werden erleichtert. In diesem Zusammenhang stellen eingebettete Datenbanken eine ideale Wahl als dienstbezogener Datenspeicher dar. Sie sind leichtgewichtig und schnell und können zusammen mit dem Dienstcode bereitgestellt werden, weshalb sie sehr gut zu MSA-Umgebungen passen.

  Typischerweise wird in Kubernetes-Umgebungen häufig das Sidecar-Muster verwendet, bei dem eine eingebettete Datenbank neben dem Anwendungscontainer platziert wird, um die lokale Datenverarbeitung zu optimieren. Dies verringert Netzwerkengpässe und minimiert die Latenz beim Datenzugriff.

• Vereinfachung des Betriebs

  Datenbankserver erfordern komplexe Betriebsabläufe wie Installation, Patching, Sicherung, Wiederherstellung nach Ausfällen, Replikation und Leistungsüberwachung, wofür speziell zuständige DBAs und qualifiziertes Betriebspersonal notwendig sind. Insbesondere in großskaligen Umgebungen ist diese Verwaltungslast sehr hoch.

  Eingebettete Datenbanken mildern diese Probleme erheblich. Wenn die Datenbank in die Anwendung integriert ist, erfolgen Modultests, Build, Versionsverwaltung und Deployment gemeinsam, sodass kein separater Serverbetrieb erforderlich ist. Zudem skaliert die eingebettete Datenbank mit, wenn die Anwendung horizontal skaliert wird, und durch DevOps-Kultur sowie CI/CD-Pipelines wird eine automatisierte Verwaltung möglich. Insbesondere in Startups, kleinen Diensten und Prototypenentwicklungsumgebungen senken eingebettete Datenbanken die betriebliche Komplexität erheblich und beschleunigen Entwicklung und Deployment deutlich.

• Systemsprachen mit hoher Leistung und Entwicklung des Ökosystems

  In der Vergangenheit wurden Datenbanken und Anwendungen in der Regel in unterschiedlichen Sprachen entwickelt. Beispielsweise wurden leistungskritische Datenbank-Engines überwiegend in C und C++ geschrieben, während Anwendungen in Sprachen wie Java, Python oder PHP entwickelt wurden. Dieser Ansatz war für die Leistungsoptimierung zwar wirksam, wies jedoch Einschränkungen auf, nämlich Probleme mit der Speichersicherheit, komplexe Nebenläufigkeitsbehandlung, Latenzzeiten sowie Schwierigkeiten bei der Integration von Bibliotheken und beim Deployment.

  Mit dem Aufkommen moderner Systemprogrammiersprachen wie Go und Rust haben sich diese Einschränkungen jedoch deutlich verringert. Insbesondere Go eignet sich sowohl für leistungsstarke Anwendungen als auch für die Entwicklung niedrigstufiger Programme wie Datenbank-Engines, sodass Datenbanken und Anwendungen innerhalb eines einzigen Sprachökosystems gemeinsam entwickelt werden können.

  Tatsächlich werden in Golang leistungsstarke eingebettete Datenbanken wie BadgerDB und PebbleDB intensiv eingesetzt. Dies zeigt, dass sich eingebettete Datenbanken nicht nur als leichtgewichtige Alternative zu Datenbankservern etabliert haben, sondern als wichtige Option mit eigener Wettbewerbsfähigkeit.

Fazit

Unter Bedingungen, die eine zentrale Verwaltung großer Datenmengen, komplexe Transaktionen und hohe Parallelität erfordern, ist der Datenbankserver nach wie vor die leistungsfähigste Lösung. Für einzelne Dienste in MSA-Umgebungen, IoT-Edge-Geräte, schnelles Prototyping und Projekte, in denen die betriebliche Effizienz im Vordergrund steht, können eingebettete Datenbanken jedoch die effizientere und sinnvollere Wahl sein. Entscheidend ist letztlich, das für die jeweilige Situation und die Anforderungen am besten geeignete Werkzeug auszuwählen, und die Weiterentwicklung eingebetteter Datenbanken bietet uns dabei eine breitere und vielfältigere Auswahl.