Eine vollständige DuckDB-Datenbank direkt auf S3 ohne zusätzliche Dienste betreiben

Ingenieure haben eine Methode entwickelt, um eine vollständige DuckDB-Datenbank direkt auf einem Objektspeicher wie Amazon S3 zu betreiben. Dies eliminiert die Notwendigkeit separater Datenbankserver oder komplexer Data-Lake-Kataloge. Dieser Ansatz wurde im Oktober 2026 veröffentlicht und nutzt eine benutzerdefinierte Erweiterung namens duckdb_objfs, um den internen Speicher-Engine von DuckDB auf SlateDB abzubilden, einen eingebetteten Key-Value-Speicher, der für Cloud-Objekte konzipiert ist.

Was passiert ist

Die Kerninnovation ist eine DuckDB-Erweiterung, die es der Datenbank ermöglicht, einen S3-Bucket als primäres Laufwerk zu behandeln. Im Gegensatz zu bestehenden Lösungen wie Iceberg oder DuckLake, die sich auf die gemeinsame Nutzung von Parquet-Tabellen über verschiedene Engines hinweg konzentrieren, bewahrt diese Methode den gesamten Funktionsumfang von DuckDB. Dazu gehören erweiterte Indizes, Constraints, Views, Makros und spezifische Datentypen, die bei der Konvertierung in offene Tabellenformate oft verloren gehen oder schlecht abgebildet werden.

Das System ermöglicht es einem einzelnen Schreibprozess, die Datenbank zu aktualisieren, während mehrere andere Prozesse im schreibgeschützten Modus an dieselben Daten angehängt werden können. Diese Leser können komplexe SQL-Abfragen, einschließlich Joins und Aggregationen, direkt gegen die Daten im Bucket ausführen. Die Architektur stellt sicher, dass die Leser immer einen konsistenten Zustand der Datenbank sehen, auch wenn sie dem neuesten Schreibvorgang leicht hinterherhinken. Dies verhindert teilweise oder fehlerhafte Lesevorgänge während Aktualisierungen.

Wie es funktioniert

Die Erweiterung funktioniert, indem sie die zugrunde liegende Disk-Ebene ersetzt, anstatt den Speicher-Engine von DuckDB selbst zu modifizieren. Sie registriert einen benutzerdefinierten Dateisystem-Handler für das Schema duckdb_objfs://. Wenn DuckDB versucht, Dateien zu lesen oder zu schreiben, wird die Anfrage über eine C-Schnittstelle an einen Rust-Core weitergeleitet, der SlateDB verwaltet. SlateDB fungiert als Adapter und übersetzt Dateioperationen in Aufrufe des Objektspeichers unter Verwendung von Apache OpenDAL, das verschiedene Backends wie S3, MinIO und lokale Verzeichnisse unterstützt.

Um die Diskrepanz zwischen den In-Place-Dateiaktualisierungen von DuckDB und der Unveränderlichkeit des Objektspeichers zu handhaben, richtet das System die Datenblöcke präzise aus. Jeder 256 KiB große DuckDB-Block wird einem einzelnen 256 KiB großen Chunk in SlateDB zugeordnet, beginnend nach einem 12 KiB großen Header. Diese Geometrie stellt sicher, dass das Schreiben eines Blocks nur einen Put-Vorgang erfordert und das Lesen nur einen Get-Vorgang, wodurch teure Read-Modify-Write-Zyklen vermieden werden. Die Dauerhaftigkeit wird gewährleistet, indem verschmutzte Chunks und Metadaten in einem einzigen Schreibbatch gebündelt und vor der Rückkehr des File-Sync-Aufrufs in den Bucket gespült werden.

Wichtige Details

• Vollständige SQL-Unterstützung: Die Lösung behält alle DuckDB-Funktionen bei, einschließlich ART-Indizes, räumlicher R-Trees und experimenteller HNSW-Vektorindizes, die in standardmäßigen Parquet-basierten Tabellenformaten nicht unterstützt werden.
• Single-Writer-Modell: Nur ein Prozess kann gleichzeitig in die Datenbank schreiben. Writer Fencing verhindert Konflikte, indem sichergestellt wird, dass ältere Schreibprozesse I/O-Fehler erhalten, wenn ein neuerer Schreibprozess übernimmt.
• Konsistente Lesevorgänge: Schreibgeschützte Anhänge verwenden Non-Fencing-Reader, die ihre Sicht auf das Manifest alle zehn Sekunden aktualisieren. Dies garantiert Konsistenz, ohne den Schreibprozess zu blockieren.
• Leistungsmetriken: Auf einem Apple M4 sind kalte S3-Lesevorgänge etwa 1,2-mal langsamer als natives HTTPFS, während lokale Schreibvorgänge aufgrund der Netzwerklatenz etwa 0,19-mal so schnell sind wie native lokale Disk-Schreibvorgänge.
• Keine zusätzlichen Dienste: Die Bereitstellung erfordert nur einen S3-Bucket. SlateDB übernimmt Koordination, Compaction und Garbage Collection innerhalb des Schreibprozesses, was externe Katalogdienste überflüssig macht.
• Integration mit Duckherder: Diese Speicherschicht dient als Grundlage für Duckherder, eine verteilte Ausführungsmaschine, die es mehreren Workern ermöglicht, partitionierte Daten aus demselben Bucket für parallele Abfrageverarbeitung zu lesen.

Warum es wichtig ist

Für Software-Ingenieure und Datenteams vereinfacht dieser Ansatz die Infrastruktur, indem er den operativen Aufwand für die Verwaltung von Datenbankservers, Backups und Hochverfügbarkeits-Clustern beseitigt. Der Bucket wird zur einzigen Quelle der Wahrheit (Single Source of Truth), was die Anzahl der Komponenten reduziert, die bereitgestellt, gesichert und überwacht werden müssen. Dies ist besonders wertvoll für selbst gehostete Anwendungen oder kleine Teams, die die Leistungsfähigkeit einer relationalen Datenbank ohne die Komplexität der traditionellen Datenbankadministration nutzen möchten.

Allerdings beinhalten die Kompromisse Latenz und Schreibdurchsatz. Da jeder Commit eine Hin- und Rückreise zum Objektspeicher erfordert, werden schreiblastige Workloads deutlich langsamer sein als Operationen auf lokalen Disks. Ingenieure müssen ihre Anwendungen so gestalten, dass sie kleine Schreibvorgänge bündeln und akzeptieren, dass schreibgeschützte Replikate bis zu zehn Sekunden zurückliegen können. Dieses Modell ist ideal für analytische Workloads, bei denen Daten selten angehängt oder aktualisiert, aber häufig von mehreren Benutzern oder Diensten abgefragt werden.

Was Sie tun können

• Workload-Eignung bewerten: Bestimmen Sie, ob Ihre Anwendung die Latenz von S3-Schreibvorgängen und die zehnsekündige Leselatenz tolerieren kann. Dieses Modell eignet sich besser für analytische Dashboards als für hochfrequente transaktionale Systeme.
• Schreiboperationen bündeln: Gruppieren Sie kleine Aktualisierungen in größere Transaktionen, um die Anzahl der Hin- und Rückreisen zum Objektspeicher-Bucket zu minimieren und den allgemeinen Schreibdurchsatz zu verbessern.
• Schreibgeschützte Anhänge verwenden: Skalieren Sie die Abfragekapazität horizontal, indem Sie mehrere schreibgeschützte Prozesse an dieselbe Datenbank anhängen. Dies ermöglicht gleichzeitige Analysen, ohne den Schreibprozess zu beeinträchtigen.
• IO-Statistiken überwachen: Verwenden Sie die bereitgestellten Funktionen duckdb_objfs_io_stats() und duckdb_objfs_cache_stats(), um Anzahlen von Anfragen, Latenzen und Cache-Leistung für Debugging und Optimierung zu verfolgen.
• Migration planen: Da der Bucket SlateDB-Objekte anstelle einer Standard-.duckdb-Datei enthält, sollten Sie dies bei der Planung Ihrer Migration berücksichtigen.