Je n’ai vu qu’une partie aussi, d’où ma question
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 !
@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.
My bad !
La différence est telle que j’avais cru avoir mal entendu (ou que @pierre-gilles avait mal lu ) et que c’était 330Mo
Ça résoudrait tous les problèmes liés aux petits hardwares… Stockage, sauvegarde, génération de graphiques…
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
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 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).
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
@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 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 ?
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
) et que c’était 330Mo 
Je suis très motivé pour le faire, mais ça me va prendre du temps.
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.