Die heutigen „Serverless“-Datenbanken sind nicht wirklich serverlos

Die Illusion des Serverless

• Serverless hat sich als zentraler Trend in der Cloud-Technologie etabliert.
• Dieses Paradigma ermöglicht es Entwicklern, sich ohne den Aufwand der Serververwaltung ausschließlich auf die Geschäftslogik zu konzentrieren.
• Kostenmodell: Man zahlt nur für die tatsächlich genutzten Ressourcen, und der Betriebsaufwand liegt faktisch nahe bei Null.
• Mehrere Serverless-Datenbanken sind auf den Markt gekommen, wobei etablierte Anbieter wie Elastic, Confluent und Pinecone mit neuen Herausforderern wie Neon, WarpStream, Upstash und Turbopuffer konkurrieren.

Probleme herkömmlicher Serverless-Datenbanken

• Viele Serverless-Datenbanken sind nicht wirklich serverlos.
• Die meisten Services basieren auf Cloud-Native-Architekturen, die als innovative Architektur für das Zeitalter der Server-Pools entwickelt wurden.
• Sie betreiben Server-Cluster und nutzen komplexe Software sowie menschliche Eingriffe, um Lasten vorherzusagen und Kapazitäten zu verwalten.
• Diese Illusion verursacht den Nutzern tatsächlich spürbare Probleme.

Auswirkungen ineffizienter Architekturen

• Eine Architektur-Diskrepanz ist kein bloßes technisches Detail, sondern verursacht den Nutzern reale Probleme.
• Nutzer zahlen für Leerlaufressourcen von Servern, da Server-Cluster ständig für verschiedene Zwecke laufen.
• Skalierungsproblem: Das Hinzufügen neuer Server zu einem Cluster dauert mehrere Minuten, und dadurch kann ein plötzlicher Lastanstieg nicht sofort abgefangen werden.
• Eingeschränkte Wahl: Da die Infrastruktur pro Cloud-Region verwaltet werden muss, ist die Anzahl nutzbarer Service-Regionen begrenzt.

Ein nicht nachhaltiges Modell

• „Serverless“-Datenbanken, die auf Server-Pool-Architekturen basieren, sind langfristig nicht nachhaltig.
• Anbieter benötigen für den Betrieb von Server-Clustern erhebliche Investitionen, wodurch sich Preise ändern können.
• Schlanke Nutzer müssen dafür hohe Gebühren bezahlen, um das System zu stützen, und erfolgreiche Nutzer sehen sich mit unerwarteten Preissteigerungen konfrontiert.

Bedarf an serverless-native Architekturen

• In den frühen Tagen des Cloud Computing waren die meisten „Cloud“-Datenbanken klassische Legacy-Datenbanken.
• Eine serverless-native Architektur überlässt jede Infrastrukturverwaltung dem Cloud-Anbieter und nutzt statt Server-Clustern zustandslose Funktionen und Serverless-Services.
• Dieser Ansatz behandelt die Cloud-Infrastruktur wie einen einzelnen großen Supercomputer und ermöglicht damit sofortige Skalierbarkeit sowie ein echtes Pay-per-Request-Modell.
• Lackmus-Test: Um zu prüfen, ob eine Datenbank wirklich serverless-native ist, sollte sich verifizieren lassen, ob sie ohne Bereitstellung eines Kubernetes-Clusters oder VMs in einem Cloud-Konto bereitgestellt werden kann.

Einführung von LambdaDB

• LambdaDB ist eine neue Suchmaschine, die serverless-native gebaut wurde.
• Das System wird als Sammlung von Serverless-Funktionen und -Ressourcen betrieben und trennt Datenbanklogik und Infrastruktur vollständig.
• Nutzeranfragen laufen über ein Regional Gateway und werden je nach Anfrageart zu Control Functions (Steuerungsfunktionen) oder Data Functions (Datenfunktionen) geroutet.
• Enterprise-Funktionen: LambdaDB bietet Features wie Point-in-Time Recovery und Zero-Copy-Cloning, ohne dass Infrastrukturmanagement erforderlich ist.

Funktionsweise von LambdaDB

• LambdaDB-Architektur: Alle Komponenten werden mit serverlosen Cloud-Services aufgebaut.
• Das Gateway validiert den API-Schlüssel der Nutzeranfrage und routet sie zu Control Functions oder Data Functions.
• Control Functions verarbeiten CRUD-Operationen und Datenverwaltungsanfragen, während Data Functions die eigentliche Daten-Schreib- und Lesearbeit übernehmen.
• Schreibpfad: Writer Function schreibt die Anfrage auf, schreibt sie in einen robusten serverlosen Schreibpuffer und antwortet anschließend an den Client zurück.

Das Paradox der Kosteneffizienz

• LambdaDB reduziert die Rechenkosten im Vergleich zu Server-Pool-Datenbanken.
• Obwohl der Preis pro Lambda-Einheit höher als bei EC2-Instanzen ist, sinken die Kosten durch die Redundanz, die für Hochverfügbarkeit und Fehlertoleranz erforderlich ist.
• Verschwendung fixer Kapazität: Die durchschnittliche Rechenlastauslastung von Unternehmen liegt bei nur 10–20 %, weshalb serverloses Rechnen 50–90 % Kostenersparnis liefern kann.

Leistung und Skalierbarkeit

• Leistung und Skalierbarkeit: LambdaDB hat seine Leistung in einem Experiment nachgewiesen, bei dem Millionen von Vektoren mit 960 Dimensionen hinzugefügt wurden.
• Schreiblatenz: Bei 10 Upserts pro Sekunde beträgt die Medianlatenz 43 ms; selbst bei 100-fach höherem Traffic bleibt die Latenz vergleichbar stabil.
• Abfrage-Latenz: Die Abfragelatenz bleibt unter variabler Last stabil, wobei das 99. Perzentil zwischen 172 ms und 210 ms liegt.
• Optimierungsaufwand: Die Latenz von Query Functions wird kontinuierlich optimiert, und die Serverless-Infrastruktur wird ebenfalls verbessert.

Vorteile für Kunden

• Kostensenkung: LambdaDB ist mehr als zehnmal günstiger, weil es keine Leerlaufserver gibt.
• Sofortige und unbegrenzte Skalierbarkeit: LambdaDB kann sich innerhalb von Millisekunden auf tausende parallele Funktionen ausdehnen.
• Einfacher Start und Skalierung: Starke KI-Anwendungen lassen sich aufbauen, und mit dem Wachstum bleibt die Architektur einfach und kosteneffizient.
• Enterprise-Funktionen: LambdaDB bietet Funktionen wie Point-in-Time Recovery und Zero-Copy-Cloning, ohne zusätzliche Komplexität oder Kosten.

Zukunftspläne und Vision

• LambdaDB verarbeitet bereits heute Millionen von Anfragen täglich für Hunderte Millionen Dokumente.
• Langfristige Pläne: Geplant ist die Unterstützung weiterer Datenmodelle (relationale Daten, Streams, Key-Value, Graphen usw.).

[davidshim]

Die Idee ist gut, aber für die Verringerung der Abfrageverzögerung wird zwangsläufig ein State benötigt. Im Vergleich zu MySQL, PostgreSQL usw. ist die Abfrageverzögerung fast hundertmal höher. Es wirkt fast wie die Ein- und Ausgabe in einem Dateisystem.

[stevenk]

Vielen Dank für den guten Beitrag. Der von Ihnen genannte Punkt, dass ein State zur Verringerung der Latenz erforderlich ist, trifft genau den zentralen Trade-off unserer Architektur.

Zunächst zur Abfrage-Latenz: In unseren Benchmarks liegt das P99 (99. Perzentil) bei etwa 130–210 ms. Der Hinweis auf einen Faktor 100 bezieht sich vermutlich auf den im Beitrag erwähnten Worst Case, bei dem ein „Cold Start“ mehrere Sekunden dauern kann. Wie Sie richtig anmerken, ist dies eindeutig ein Nachteil unserer Architektur; wie im Beitrag erwähnt, tritt er in Produktionsumgebungen bei weniger als 0,01 % (P99.99) auf. Im Übrigen sind die meisten anderen Abfragen so ausgelegt, dass sie den lokalen Speicher- und Festplatten-Cache jeder Lambda nutzen, um stabile Leistung zu gewährleisten.

Wie Sie zu Recht anmerkten, kann diese Architektur für ultra-latency Finanzhandelssysteme, bei denen für alle Abfragen eine Latenz unter 10 ms garantiert werden muss, möglicherweise nicht geeignet sein. Für die meisten KI-basierten Such- und Empfehlungssysteme ist jedoch eine Latenz im Bereich von 100–200 ms auf P99-Basis bereits eine sehr gute Leistung. Ich denke, der Vorteil, die Infrastrukturkosten und den Betriebsaufwand um mehr als 90 % zu senken, ist deutlich größer.

Nochmals vielen Dank für Ihren tiefgehenden Beitrag.

[davidshim]

Wie Sie es sagen, wird es wohl eher eine Lösung sein, die in bestimmten Situationen als „echte“ Serverless genutzt werden kann, als eine universelle Datenbank.

[davidshim]

Ich hätte nicht gedacht, dass jemand auf Koreanisch antwortet! (Das habe ich wohl zu zynisch formuliert...)

Zuerst hielt ich die Idee für bahnbrechend. Tatsächlich liegt das größte Problem der serverlosen Datenbanken darin, dass an einer Stelle im Hintergrund dennoch ein echter Server läuft. Wenn dann viel Traffic einströmt, kann es passieren, dass der Dienst bis zur Zuweisung dieses Servers einfach nicht reagiert (ca. fünf Minuten). Deshalb sind bestehende serverlose DBs der Cloud-Anbieter (wie AWS usw.) im Produktivbetrieb schwer einzusetzen.

Ich dachte, ich könnte es mal ausprobieren. Der Grund für meine Sorge war jedoch, dass man dann Logiken wie Indexierung, Sortierung und andere binäre Logiken, die in MySQL, PostgreSQL usw. bereits implementiert sind, ebenfalls selbst umsetzen müsste – und ich fragte mich, wie schwierig es wäre, ein so zuverlässiges Open-Source-DB-Projekt auf Lambda neu aufzubauen.

Da es ein Produkt ist, das Sie selbst bauen, erwarte ich große Fortschritte davon~!

[stevenk]

Vielen Dank für Ihre freundlichen Worte. Wie Sie sagten, eignet es sich nicht für RDB-Anwendungsfälle, sondern sollte eher als Position als Suchmaschine (Elasticsearch) bzw. Vektor-Datenbank (Pinecone) verstanden werden. Intern setzen wir zudem Lucene ein, das sich über einen langen Zeitraum bewährt hat, um Funktionen wie Indexierung, Sortierung und Aggregation zu unterstützen. Vielen Dank :)