Live Coding: Découverte de DuckDB le jeudi 20 juin à 10h!

Salut à tous :slight_smile:

J’en ai déjà parlé sur le forum, DuckDB, c’est une base de donnée OLAP révolutionnaire qui vient de passer en 1.0.

Côté Gladys, cette base de donnée est très prometteuse car elle répond exactement à nos besoins pour la partie « graphique » :

  • Extrêmement performante sur des données analytiques
  • Base de donnée fichier, comme SQLite
  • Compression importante pour réduire l’espace occupé sur le disque

Je vous propose un atelier en direct sur YouTube où je testerais DuckDB avec vous, afin de voir ensemble si ça peut répondre à nos problématiques.

Cela se déroulera demain à 10h ici :

https://www.youtube.com/live/EtEfyS6uHoE?si=pwiTbXfGvI6395KA

A demain !

6 Likes

Je serai pas dispo mais je trouve super l’initiative !!! :grin:

1 Like

On se retrouve dans 20 minutes sur YouTube !

https://www.youtube.com/live/EtEfyS6uHoE?si=pwiTbXfGvI6395KA

Merci à tous d’être venu, le replay est disponible à la même adresse :slight_smile:

En résumé, DuckDB tient-il ses promesses ?
Taille de DB, vitesse d’accès, etc. ?
Verdict et impressions ?

TRES impressionnant la vitesse d’affichage du graph sur l’année !!! :expressionless:

@GBoulvin je ne saurai pas etre précis car j’ai regardé juste un petit coup, mais pour afficher des données (environ 1000) sur une période de 1 an :

  • avec sqlite on est sur 6 sec de latence
  • avec duckdb on est sur 0.12 sec

Bref… c’est du rapide !!!

2 Likes

Je n’ai vu qu’une partie aussi, d’où ma question :wink:
Niveau stockage, j’ai cru entendre un rapport d’environ 1/3… Juste ?
Du coup, si c’est plus rapide et nécessite moins de stockage, qu’est-ce qu’on attend ?
Développements et tests ou il y a encore des questions techniques (migration ?) ?

Et je ne l’ai pas dit mais… Merci pour ce Live coding !

1 Like

@guim31 : À ce moment là, il testait avec 3 ans de données car sur 1 an avec 300 données, on voyait pas trop la différence.
C’est pour ça qu’il a voulu envoyer 10 millions de données pour mieux voir.

@GBoulvin : Non, la différence est très importante,
au début de la vidéo c’était un facteur 12,
à la fin on a 1.4go pour SqlLite et 33mo pour Duck…
C’est un gros morceau de dev mais Pierre-Gilles est intéressé et s’y mettra sûrement, mais il dit pas qu’il ne faut rien attendre avant plusieurs mois.

3 Likes

My bad !
La différence est telle que j’avais cru avoir mal entendu (ou que @pierre-gilles avait mal lu :innocent:) et que c’était 330Mo :joy:
Ça résoudrait tous les problèmes liés aux petits hardwares… Stockage, sauvegarde, génération de graphiques…

Tu m’as mis le doute, du coup :
image
on est donc à 1 328mo contre 33mo.

1 Like

Petit post bilan :slight_smile:

Le bilan du live est très positif :

  • En fin de live, la DB faisait 1.3GB pour l’implémentation actuelle vs 33 Mo sur DuckDB
  • DuckDB est extrêmement performant à calculer des données agrégées “en live” directement sur la donnée brute. On pourra lâcher le process d’agrégation toutes les heures.
  • Une limite néanmoins dans DuckDB: max 1 client par DB. Pas de possibilité de lire une DB déjà ouverte, peut-être pas pratique pour développer mais pas un souci Gladys.

Il reste des choses à tester néanmoins :

  • Est-ce que DuckDB supporte le même volume d’écriture que SQLite ? DuckDB n’est pas le meilleur en écriture, c’est fait pour lire/analyser des gros volumes, mais pas forcément fait pour des gros volumes d’écriture. Peut-être qu’il faudra passer par une écriture “périodique” par batch (ex: 1 write/seconde au max)
  • Est-ce que DuckDB est aussi stable/robuste que SQLite ? SQLite est un des programme les plus robustes de la terre (Leur méthodologie de testing est assez impressionnante, pour ceux que ça intéresse : How SQLite Is Tested). De son côté, DuckDB vient de sortir en 1.0 la semaine dernière. Je pense qu’il faut faire nos propres tests en réel et laisser un peu de temps à DuckDB pour fixer tous les petits bugs qui vont être découvert avec ce passage en 1.0. Il y aura probablement une 1.0.1. Pour l’instant, la stabilité de Gladys semble “acquise”, mais un passage prématuré à DuckDB pourrait mettre en péril cette stabilité, pour moi il faut être très rigoureux sur cette étape. On n’est pas pressé, pour l’utilisateur final il y aura peu de différence de toute façon :slight_smile:
  • Se renseigner sur le système de connexion, est-ce qu’il vaut mieux une connexion par client DuckDB, ou une connexion écriture/une connexion lecture, ou un pool de N connexion ? Test en réel avec des écritures/lectures concurrentes.
  • Se renseigner sur le process de sauvegarde/restoration ? Sans downtime ou avec interruption ?

Ensuite, niveau développement :

  • Coder proprement tout le système d’écriture/lecture (le live de ce matin n’était qu’un poc pour tester, rien de sérieux)
  • Coder la sauvegarde et la restauration de la base de donnée via Gladys Plus. Comment faire pour rester rétro-compatible avec les sauvegardes existantes ?
  • Coder la migration de toute la donnée existante vers DuckDB, et suppression de la donnée dans SQLite. Comment faire pour imposer un VACUUM sans non plus couper Gladys trop longtemps chez les utilisateurs existants ? Objectif interruption de service minimale.

Bref, c’est très prometteur tout ça mais il y a du vrai boulot :muscle: Je suis très motivé pour le faire, mais ça me va prendre du temps.

J’aurais néanmoins besoin de vous assez vite pour m’aider à tester avec votre data (en dehors de vos prod bien-entendu).

3 Likes

Autre test assez impressionnant ce matin, j’ai créé un CSV de 50 millions de lignes sur 5 capteurs sur les 3 dernières années avec des valeurs randoms.

Le fichier fait exactement 3.0 GB:

pierregilles  staff 3.0G Jun 21 10:33 output.csv

J’ai fais un petit script qui importe le CSV avec l’API d’import de CSV de DuckDB :

CREATE TABLE device_feature_state AS
    SELECT * FROM read_csv('output.csv');

Le CSV est ingéré en 3.34s :

[ { Count: 50000000n } ]
start: 3.348s

Le fichier DuckDB fait 75 Mo !

pierregilles  staff 75M Jun 21 10:34 imported_from_csv.duckdb

Et contient bien les 50 millions de lignes :

3 Likes

C’est ouf cette différence :sunglasses:

1 Like

Mais comment c’est possible de passer de 3go à 75mo…?!
C’est ouf cette compression…

@Hizo Dans le CSV il y a beaucoup de redondance, sur les 50 millions de lignes, il y a seulement 5 UUIDs différents de capteur qui sont répétés du coup chacun 10 millions de fois.

N’importe quel algo de compression voit ce genre de pattern, et élimine la plupart du poids en ne gardant qu’une seule fois chaque UUID. De 50 millions à 5 lignes :smiley: Le reste, c’est des DOUBLE (8 bytes) et des DATETIME, il y a peut-être de la redondance aussi dans les valeurs générées.

Ouais c’est pas faux,
en gros, il construit une table d’UUID et fait le lien entre les 2 tables ?
Et il pourrait faire la même chose pour les valeurs ?

Tout est expliqué sur cette page :

Dans notre cas, c’est cette partie qui doit avoir le plus d’impact sur ce fichier en particulier :

1 Like

@GBoulvin @Terdious (ou autre) Si jamais vous voulez me passer vos DB, je commence à faire des tests de migration :slight_smile:

Est-ce que vous pouvez me les envoyer en MP ? (via ce que vous voulez comme lien)

2 Likes

Merci @GBoulvin pour ta base de donnée.

Pour l’instant, elle fait 13GB avec un peu plus de 13 millions d’états de capteurs.

J’ai testé mon code de migration vers DuckDB, qui s’est effectué en 12 minutes chez moi (je pense qu’il y a encore de l’optimisation à faire).

En passant à DuckDB, ta DB SQLite ne fait plus que 7,7MB et ta DB DuckDB fait 68.2 MB, soit un total de 75,9 Mo !

2 Likes

Vraiment très impressionnant !
Sur un RPi, on doit estimer quel facteur de temps pour la transcription ? Temps pendant lequel j’imagine que Gladys serait inaccessible… Prévoir un bouton pour migrer manuellement si/quand l’utilisateur le décide ?
Je vais peut-être attendre avant de redimensionner mes partitions du coup :innocent: