DuckDB 2.0 alpha offre des lectures S3 plus rapides et des requêtes récursives

L'équipe DuckDB a publié la version alpha de DuckDB 2.0, marquant une avancée significative en matière de performance pour les charges de travail analytiques. Cette mise à jour se concentre sur trois améliorations architecturales majeures : l'entrée/sortie asynchrone pour le stockage cloud, un moteur réécrit pour les expressions communes de table (CTE) récursives et un nouveau type de données natif pour gérer les données semi-structurées. Ces changements visent à réduire les temps de requête et les coûts de stockage pour les ingénieurs construisant des pipelines de données sur leurs ordinateurs portables ou dans le cloud.

Ce qui s'est passé

Le gain de performance le plus immédiat provient de la manière dont DuckDB 2.0 gère les données stockées à distance, comme sur Amazon S3. Dans les versions précédentes, les threads de travail devaient alterner entre le téléchargement de blocs de données et leur traitement, laissant les ressources CPU inactives pendant les attentes réseau. La nouvelle version introduit un pool de threads séparé dédié uniquement au téléchargement anticipé des données. Cela permet au système de maintenir simultanément la connexion réseau et le CPU occupés, réduisant considérablement le temps total nécessaire pour lire de gros fichiers Parquet ou CSV depuis le stockage objet.

Au-delà de la vitesse brute, cette version répond aux modèles de requêtes complexes impliquant des données hiérarchiques. Les expressions communes de table (CTE) récursives, souvent utilisées pour parcourir des organigrammes ou des arbres de dépendance, ont été entièrement repensées. Auparavant, chaque niveau de récursion nécessitait un scan complet de la table source, rendant les hiérarchies profondes prohibitivement lentes. Le nouveau moteur lit la table une seule fois et construit une structure de recherche interne, lui permettant d'accéder directement aux lignes pertinentes pour chaque niveau de récursion ultérieur. Ce changement transforme des opérations qui prenaient auparavant plusieurs secondes ou minutes en tâches inférieures à la seconde.

La troisième addition majeure est le type de données VARIANT, conçu pour gérer le JSON et d'autres formats semi-structurés plus efficacement. Au lieu de stocker le JSON sous forme de chaîne de texte simple, DuckDB 2.0 analyse les données lors des opérations d'écriture. Il identifie les champs qui apparaissent de manière cohérente avec le même type de données dans la plupart des lignes et les stocke sous forme de colonnes séparées et optimisées. Seuls les champs irréguliers ou rares restent dans un blob binaire. Ce processus, connu sous le nom de "shredding", réduit l'empreinte de stockage et accélère les requêtes qui filtrent ou agrègent ces champs cohérents.

Détails clés

• L'I/O asynchrone améliore les vitesses de lecture S3 par deux à trois fois sans nécessiter de modifications aux requêtes SQL existantes.
• Le paramètre read_ahead_depth contrôle le nombre de groupes de lignes récupérés à l'avance, avec une taille automatique par défaut basée sur le nombre de threads.
• La performance des CTE récursifs a été radicalement améliorée lors des tests, passant de jusqu'à 16 secondes à 0,10 seconde pour une traversée de l'historique git de 20 000 commits.
• Le nouveau type VARIANT réduit les besoins de stockage d'environ 2,7 fois par rapport au stockage du JSON sous forme de chaînes de texte.
• Les requêtes filtrant sur des champs VARIANT "shreddés" s'exécutent environ six fois plus vite que l'analyse de texte JSON et approchent la vitesse des colonnes typées natives.
• Les opérations sur les listes au sein des données VARIANT sont actuellement plus lentes que l'accès aux champs, suggérant aux utilisateurs d'éviter les conversions de listes dans les chemins critiques des requêtes.

Contexte

Pour comprendre ces améliorations, il est utile de savoir comment les bases de données analytiques traitent généralement les données. Les moteurs traditionnels considèrent souvent la latence réseau et le traitement CPU comme des étapes séquentielles. Lors de la lecture depuis le stockage cloud, la base de données doit attendre l'arrivée des données avant de commencer le calcul. L'I/O asynchrone découple ces tâches, permettant à la base de données de précharger les données tout en traitant simultanément les blocs précédemment récupérés. Cela est similaire à la façon dont un lecteur vidéo met en cache les scènes suivantes pendant que vous regardez la scène actuelle.

Les CTE récursifs sont une fonctionnalité SQL utilisée pour interroger des structures hiérarchiques, telles que les lignes de reporting des employés ou les arborescences de répertoires de fichiers. Dans les implémentations plus anciennes, la base de données scannait répétitivement toute la table pour trouver le niveau suivant de la hiérarchie. Si un arbre avait dix niveaux de profondeur, la table était scannée dix fois. La nouvelle approche construit une structure semblable à un index en mémoire après le premier scan, permettant à la base de données de localiser instantanément les enregistrements enfants sans relire les données sources. Cela déplace le coût d'une proportionnalité à la profondeur de l'arbre multipliée par la taille de la table, vers une proportionnalité uniquement au nombre de lignes réellement visitées.

Pourquoi c'est important

Pour les équipes gérant leur propre infrastructure de données, ces changements réduisent le besoin d'outils spécialisés. Auparavant, les requêtes hiérarchiques profondes pouvaient nécessiter l'exportation des données vers une base de données de graphes ou l'écriture de code applicatif personnalisé pour gérer la traversée. Avec DuckDB 2.0, ces opérations deviennent réalisables dans du SQL standard, simplifiant la pile technologique. De même, la performance améliorée de S3 signifie que conserver les données dans un stockage objet à faible coût est plus viable pour l'analyse interactive, réduisant la pression pour tout déplacer vers un stockage de bloc haute performance coûteux.

Le type VARIANT offre un compromis pratique pour gérer les données désordonnées du monde réel. Les ingénieurs ont souvent du mal à choisir entre des schémas rigides, qui cassent lorsque les formats de données changent, et des chaînes JSON flexibles, qui sont lentes à interroger. En optimisant automatiquement les parties cohérentes des données JSON tout en préservant la flexibilité pour le reste, DuckDB 2.0 permet aux équipes d'ingérer des logs semi-structurés ou des données d'événements sans sacrifier la performance des requêtes. Cela réduit l'effort d'ingénierie requis pour nettoyer et modéliser les données avant qu'elles ne puissent être analysées.

Cependant, ces avantages s'accompagnent de responsabilités en matière de modélisation. La performance du type VARIANT dépend fortement de la cohérence des données. Si un champ contient parfois un nombre et parfois une chaîne, il ne peut pas être "shredé" efficacement et restera dans le stockage binaire plus lent. Les équipes doivent s'assurer que leurs pipelines de données produisent des types cohérents pour les champs clés afin de réaliser les gains de performance. De plus, bien que l'I/O asynchrone aide avec les gros fichiers, il ne résout pas la latence inhérente à l'accès à des milliers de petits fichiers, renforçant la bonne pratique consistant à consolider les petits jeux de données dans des partitions plus grandes.

Ce que vous pouvez faire

• Testez la version alpha sur votre machine locale en utilisant le script d'installation fourni pour évaluer vos charges de travail spécifiques.
• Revoyez vos requêtes basées sur S3 pour vous assurer que vous lisez de gros fichiers Parquet plutôt que beaucoup de petits, afin de maximiser les bénéfices de l'I/O asynchrone.
• Identifiez les requêtes récursives dans votre base de code, telles que les traversées d'organigrammes ou les expansions de nomenclatures, et relancez-les pour mesurer la nouvelle référence de performance.
• Auditez vos tables riches en JSON pour identifier les champs avec des types de données cohérents et envisagez de les convertir au type VARIANT pour réduire le stockage et améliorer la vitesse de filtrage.
• Évitez de convertir les listes VARIANT en tableaux dans les requêtes critiques en termes de performance jusqu'à ce que les mises à jour futures optimisent cette opération.
• Surveillez le paramètre read_ahead_depth si vous rencontrez une pression mémoire, bien que la configuration automatique par défaut devrait convenir à la plupart des environnements.