J’ai decouvert cet outil qui permet de créer des tables indexées par colonnes à partir de fichiers .json ou .csv ou de serveurs PostgreSqL ou autre.
Une fois les données ingérées à la vitesse de l’éclair on peut faire des requêtes analytiques en SQL a la sauce BigData. Avec des temps de réponse digne de Elasticsearch.
Je me suis demandé si cet outil pouvait gérer des graphes pour le calcul de distance, et bien oui :
Il existe un module Python officiel pour DuckDB. Pour tout savoir sur ses forces, une vidéo :
Pas encore testé, mais cela ma semble interessant pour faire des analyses sur la base PostgreSQL de l’indexeur V2, et pourquoi pas du calcul de distance…
La seule application que je vois pour le calcul de distance est dans un index généraliste (càd servant aussi à autres choses que la distance, et que ces autres choses profitent réellement du modèle SQL) préexistant et persistant (qui n’est pas recalculé pour chaque calcul de distance) où le nombre de membres référents est déjà connu et où on veut calculer la distance de très peu de membres à la fois. Ainsi on évite le coût de parcourir toutes les données à chaque calcul.
Le module de calcul de distance utilise du clé-valeur (comme tout Duniter v2) donc pourra toujours surpasser une bdd SQL en performance. Cela dit il parcourt bêtement tout l’index des certifications de manière non optimale (certaines certifs ne sont pas nécessaire au calcul pour les identités demandeuses).
Je ne sais pas si ce sera nécessaire un jour, mais s’il faut optimiser ce dernier point : l’oracle de distance pourrait conserver un cache de communautés et ne télécharger les identités que par batch de communauté, ignorant le reste du graphe, inutile. Le cache serait mis à jour de temps en temps. Il y a un compromis à trouver sur la taille et le recouvrement des communautés mais j’ai peur qu’avec la toile actuelle (beaucoup d’identités très centrales) ça fonctionne mal.
Que veux tu dire par bdd SQL? Je suppose que tu utilises une sinedocte pour évoquer une base de type Relationnelle. Mais DuckDB n’est PAS une bdd relationnelle. Ils utilisent une forme de stockage qui permet de faire des analyses de données sur de gros volumes. Le langage SQL nest là que pour ne pas effrayer les habitués des bdd relationnelles qui veulent traiter du big data. Et le SQL est enrichi pour faire des requêtes complexes plus simplement.
Je vois surtout une utilité pour l’indexeur.
Le choix de Postgresl, une base de données relationnelle pour l’indexeur est une erreur si on veut stocker des documents que l’on additionne sans les modifier.
Il faudrait utiliser un stockage clef/valeur, avec index génétique. PostgreSqL peut le faire avec le type jsonb. Mais les requêtes sont très sommaires et peu souples. Pour les avoir utilisé professionnellement.
Si le langage SQL de Postgresql ou l’API graphql de l’indexeur pêche sur certaines requêtes analytiques complexes, alors DuckDB peut être envisagé comme soutien.
Le calcul de distance sur l’indexeur, c’est pour moi la cerise sur le gâteau.
