Exécuter une base de données DuckDB complète directement sur S3 sans services supplémentaires

Des ingénieurs ont développé une méthode pour exécuter une base de données DuckDB complète directement sur un stockage objet tel qu'Amazon S3, éliminant ainsi le besoin de serveurs de bases de données séparés ou de catalogues complexes de lacs de données. Publiée en octobre 2026, cette approche utilise une extension personnalisée appelée duckdb_objfs pour mapper le moteur de stockage interne de DuckDB à SlateDB, un magasin clé-valeur embarqué conçu pour les objets cloud.

Ce qui s'est passé

L'innovation centrale est une extension DuckDB qui permet à la base de données de traiter un bucket S3 comme son disque principal. Contrairement aux solutions existantes telles que Iceberg ou DuckLake, qui se concentrent sur le partage de tables Parquet entre différents moteurs, cette méthode préserve l'ensemble des fonctionnalités de DuckDB. Cela inclut les index avancés, les contraintes, les vues, les macros et les types de données spécifiques qui sont souvent perdus ou mal mappés lors de la conversion vers des formats de tables ouvertes.

Le système permet à un processus d'écriture unique de mettre à jour la base de données tandis que plusieurs autres processus s'y connectent en mode lecture seule. Ces lecteurs peuvent exécuter des requêtes SQL complexes, y compris des jointures et des agrégations, directement sur les données du bucket. L'architecture garantit que les lecteurs voient toujours un état cohérent de la base de données, même s'ils sont légèrement en retard par rapport à la dernière écriture, évitant ainsi les lectures partielles ou corrompues pendant les mises à jour.

Comment cela fonctionne

L'extension fonctionne en remplaçant la couche de disque sous-jacente plutôt qu'en modifiant le moteur de stockage de DuckDB lui-même. Elle enregistre un gestionnaire de système de fichiers personnalisé pour le schéma duckdb_objfs://. Lorsque DuckDB tente de lire ou d'écrire des fichiers, la demande est transmise via une interface C à un noyau Rust qui gère SlateDB. SlateDB agit comme un adaptateur, traduisant les opérations de fichiers en appels au stockage objet à l'aide d'Apache OpenDAL, qui prend en charge divers backends tels que S3, MinIO et les répertoires locaux.

Pour gérer le décalage entre les mises à jour de fichiers en place de DuckDB et la nature immuable du stockage objet, le système aligne précisément les blocs de données. Chaque bloc de 256 KiB de DuckDB correspond à un seul chunk de 256 KiB dans SlateDB, commençant après un en-tête de 12 KiB. Cette géométrie garantit que l'écriture d'un bloc nécessite une seule opération put, et sa lecture une seule opération get, évitant ainsi les cycles coûteux de lecture-modification-écriture. La durabilité est maintenue en regroupant les chunks sales et les métadonnées dans un seul lot d'écriture qui est vidé dans le bucket avant que l'appel de synchronisation de fichier ne revienne.

Détails clés

• Prise en charge SQL complète : La solution conserve toutes les fonctionnalités de DuckDB, y compris les index ART, les R-trees spatiaux et les index vectoriels HNSW expérimentaux, qui ne sont pas pris en charge dans les formats de tables standard basés sur Parquet.
• Modèle mono-écriture : Un seul processus peut écrire dans la base de données à la fois. Le fencing de l'écrivain empêche les conflits en garantissant que les anciens écrivains reçoivent des erreurs d'E/S si un nouvel écrivain prend le relais.
• Lectures cohérentes : Les connexions en lecture seule utilisent des lecteurs non-fencing qui mettent à jour leur vue du manifeste toutes les dix secondes, garantissant la cohérence sans bloquer l'écrivain.
• Métriques de performance : Sur un Apple M4, les lectures froides depuis S3 sont environ 1,2 fois plus lentes que HTTPFS natif, tandis que les écritures locales sont environ 0,19 fois la vitesse des écritures natives sur disque local en raison de la latence réseau.
• Aucun service supplémentaire : Le déploiement ne nécessite qu'un bucket S3. SlateDB gère la coordination, la compaction et le ramassage des ordures au sein du processus d'écriture, éliminant le besoin de services de catalogue externes.
• Intégration avec Duckherder : Cette couche de stockage sert de fondation à Duckherder, un moteur d'exécution distribué qui permet à plusieurs workers de lire des données partitionnées depuis le même bucket pour un traitement parallèle des requêtes.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de données, cette approche simplifie l'infrastructure en supprimant la charge opérationnelle liée à la gestion des serveurs de bases de données, des sauvegardes et des clusters à haute disponibilité. Le bucket devient la source unique de vérité, réduisant le nombre de composants nécessitant provisionnement, sécurisation et surveillance. Ceci est particulièrement précieux pour les applications auto-hébergées ou les petites équipes qui souhaitent la puissance d'une base de données relationnelle sans la complexité de l'administration traditionnelle de bases de données.

Cependant, les compromis concernent la latence et le débit d'écriture. Comme chaque commit nécessite un aller-retour vers le stockage objet, les charges de travail intensives en écritures seront considérablement plus lentes que les opérations sur disque local. Les ingénieurs doivent concevoir leurs applications pour regrouper les petites écritures et accepter que les répliques en lecture seule puissent avoir jusqu'à dix secondes de retard. Ce modèle est idéal pour les charges de travail analytiques où les données sont ajoutées ou mises à jour peu fréquemment mais interrogées fréquemment par plusieurs utilisateurs ou services.

Ce que vous pouvez faire

• Évaluer l'adéquation de la charge de travail : Déterminez si votre application peut tolérer la latence des écritures S3 et le retard de lecture de dix secondes. Ce modèle convient mieux aux tableaux de bord analytiques qu'aux systèmes transactionnels à haute fréquence.
• Regrouper les opérations d'écriture : Regroupez les petites mises à jour dans des transactions plus importantes pour minimiser le nombre d'aller-retours vers le bucket de stockage objet, améliorant ainsi le débit global d'écriture.
• Utiliser des connexions en lecture seule : Étendez la capacité de requête en connectant plusieurs processus en lecture seule à la même base de données, permettant une analyse concurrente sans impact sur l'écrivain.
• Surveiller les statistiques d'E/S : Utilisez les fonctions fournies duckdb_objfs_io_stats() et duckdb_objfs_cache_stats() pour suivre le nombre de requêtes, la latence et les performances du cache afin de déboguer et d'optimiser.
• Planifier la migration : Puisque le bucket contient des objets SlateDB plutôt qu'un fichier .duckdb standard, utilisez COPY FROM DATABASE pour déplacer les données entrantes et sortantes, assurant la compatibilité avec d'autres outils si nécessaire.