La principale fonctionnalité de DuckDB était aussi son principal goulot d’étranglement
DuckDB s’est forgé une réputation de base de données analytique puissante, centrée sur le fichier. Comme SQLite, elle s’exécute de manière intégrée au sein d’une application, ce qui élimine le besoin de configurer un serveur distinct. Cette conception l’a rendue particulièrement attrayante pour les charges analytiques légères exécutées dans le processus.
Cependant, ce caractère intégré s’accompagnait d’une contrepartie importante : la concurrence. Chaque processus d’application conserve en mémoire son propre état mis en cache de la base de données. Efficace pour un seul processus, cette architecture implique qu’un seul processus peut écrire dans un fichier de base de données à la fois. DuckDB ne pouvait pas synchroniser les états en cache de plusieurs processus.
Imaginez une équipe qui exploite plusieurs services, tableaux de bord et applications, tous devant accéder aux mêmes données analytiques et les mettre à jour. Avec DuckDB traditionnel, elle faisait face à un dilemme : soit construire elle-même une couche de partage complexe pour coordonner les écritures, soit choisir une tout autre base de données.
Ce goulot d’étranglement a contraint de nombreux utilisateurs à contourner les atouts essentiels de DuckDB. Certains ont même fini par exécuter DuckDB à l’intérieur de PostgreSQLQL pour obtenir un accès partagé. La caractéristique qui rendait DuckDB si accessible, à savoir sa nature intégrée et sans serveur, est devenue sa plus grande limitation dans les environnements collaboratifs.
Quack donne à DuckDB une porte d’entrée, pas un nouveau moteur de stockage
Quack, introduit à titre expérimental en mai, donne à DuckDB une porte d’entrée. Une instance DuckDB ouvre le fichier de base de données et fait office de serveur. D’autres instances DuckDB s’y connectent via HTTP simple, en envoyant leurs lectures et écritures. Cela permet à plusieurs applications d’interagir simultanément avec la base de données.
Point essentiel : le serveur reste le seul processus à accéder directement au fichier de base de données. Cette architecture évite les écueils de l’écriture non restreinte dans un fichier par plusieurs processus, où des caches concurrents pourraient entraîner une corruption. À la place, les clients partagent l’accès via un coordinateur, ce qui garantit l’intégrité des données tout en élargissant l’accessibilité.
L’équipe de DuckDB a constaté que de nombreux utilisateurs construisaient déjà des surcouches sur mesure, voire exécutaient DuckDB à l’intérieur de PostgreSQLQL, pour obtenir un accès partagé léger. Quack, désormais une fonctionnalité aboutie de DuckDB 2.0, offre une solution native et officiellement prise en charge pour ce cas d’usage courant. Elle permet aux développeurs d’activer l’accès multi-clients sans recourir à des solutions de contournement sur mesure, souvent fragiles.
Cette nouvelle capacité serveur ne change pas l’identité fondamentale de DuckDB en tant que base de données analytique centrée sur le fichier. Elle ajoute simplement une option native et robuste pour un accès coordonné. Par exemple, DuckDB peut transférer 60 millions de lignes entre deux machines en moins de 5 secondes avec Quack, surpassant nettement le protocole de PostgreSQLQL, qui a pris plus de 2,5 minutes pour la même tâche. Si les très petites écritures plafonnent autour de 5.500 par seconde avec 8 threads, cela reste largement suffisant pour plusieurs services partageant un tableau de bord.
Soixante millions de lignes en cinq secondes : le chiffre qui frappe
La démonstration la plus frappante de Quack concerne la vitesse de transfert des données. Dans une vidéo de Better Stack, l’équipe DuckDB a transféré 60 millions de lignes entre deux machines en moins de cinq secondes avec Quack. En comparaison, le protocole PostgreSQLQL a mis plus de deux minutes et demie (plus de 150 secondes) pour la même opération.
Ce benchmark met en évidence l’avantage de Quack pour les charges analytiques. Contrairement aux protocoles de bases de données traditionnels orientés lignes, Quack transfère directement via HTTP des charges utiles de vecteurs de colonnes natives de DuckDB. Cela évite le surcoût important lié à la conversion des données orientées colonnes en formats ligne par ligne, puis à leur reconversion, ce qui est courant dans de nombreux protocoles de bases de données.
Le gain de vitesse est significatif pour les transferts analytiques, où le déplacement efficace de grands jeux de données est essentiel. Bien qu’impressionnant, il s’agit d’un benchmark rapporté. Les performances réelles peuvent varier selon :
- Votre charge de travail spécifique
- Les conditions réseau
- Les configurations matérielles
- La forme des requêtes
Pour approfondir le fonctionnement de Quack, y compris ses principes de conception, vous pouvez consulter la documentation officielle Quack: The DuckDB Client-Server Protocol. Ce protocole change la donne, mais il est essentiel d’en comprendre les points forts et les limites pour votre cas d’usage.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Le plafond de 5.500 écritures indique quand s’arrêter
Quack excelle dans le déplacement de grands jeux de données analytiques, mais il est essentiel de comprendre ses limites pour les charges transactionnelles. Les benchmarks montrent que le mode serveur de DuckDB surpasse PostgreSQLQL pour les petites écritures jusqu’à environ huit threads concurrents. Au-delà, les performances plafonnent autour de 5.500 écritures par seconde.
Ce plafond existe parce que le serveur DuckDB, tout en permettant l’accès à plusieurs clients, repose toujours sur un seul processus pour gérer toutes les écritures dans le fichier. Imaginez un caissier unique et très efficace qui sert de nombreux clients : il ne peut traiter qu’un certain nombre de transactions par seconde.
Cette architecture convient parfaitement aux analyses partagées, aux tableaux de bord et aux services qui profitent d’un hub DuckDB central et simple, en particulier lorsque le déplacement rapide de données en masse est une priorité. Elle simplifie l’ingestion de données et les requêtes complexes entre applications.
En revanche, les systèmes transactionnels à haute fréquence, où chaque écriture doit être traitée instantanément et de manière concurrente, trouveront ce goulot d’étranglement à processus unique limitant. Pour ces scénarios OLTP (Online Transaction Processing) exigeants, PostgreSQLQL ou une autre base de données OLTP dédiée reste le choix le plus approprié. DuckDB 2.0 inclut également d’autres améliorations de stockage et de requêtes, mais la conception de Quack est l’élément clé à considérer pour les écritures concurrentes.
Foire aux questions
Qu’est-ce que Quack dans DuckDB 2.0 ?
Quack est le protocole client-serveur de DuckDB. Il permet à des instances clientes d’envoyer des requêtes et des écritures via HTTP à un processus DuckDB qui détient le fichier de base de données.
Plusieurs applications peuvent-elles écrire dans la même base de données DuckDB ?
Oui. Avec Quack, plusieurs clients peuvent envoyer des tâches à une même instance serveur, qui est le seul processus accédant directement au fichier de base de données.
DuckDB 2.0 remplace-t-il PostgreSQL ?
Non. Le mode serveur de DuckDB convient aux analyses partagées et aux charges d’écriture modestes ; PostgreSQL est généralement mieux adapté aux charges transactionnelles exigeantes et à forte concurrence.
Quelle est la vitesse de DuckDB Quack ?
La vidéo indique le transfert de 60 millions de lignes entre deux machines en moins de cinq secondes. Le débit des petites écritures plafonnerait, selon les mesures rapportées, autour de 5.500 écritures par seconde.