Dolt : rendez le SQL aussi simple que Git

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00votre code utilise git, mais vos données ont quoi exactement ? C'est ça le problème : un mauvais CSV, une ligne de configuration,

00:00:07une modification dans un tableur, et voilà votre application en panne. Pas de diff propre, pas de branche, pas de pull request,

00:00:13pas de retour en arrière évident. Voici Dolt : c'est une base de données SQL qui fonctionne comme git. Vous pouvez créer des branches de tables,

00:00:20modifier des lignes, comparer les changements, les valider et les fusionner. Un vrai contrôle de version pour de vraies données. Je vais

00:00:26vous montrer comment mettre ça en place en quelques minutes.

00:00:35On sait que la plupart du temps, les bases de données sont excellentes dans leur rôle : elles stockent des données, elles vous permettent

00:00:41d'interroger avec SQL. Mais elles ne sont pas géniales pour les flux de travail que nous utilisons au quotidien, comme la création de branches,

00:00:47la révision, la comparaison, la fusion, le retour en arrière, savoir exactement qui a modifié quoi. Alors, souvent, on choisit

00:00:54l'une des deux mauvaises options. La première : vous gardez les données dans une vraie base de données, vous avez les index SQL,

00:01:00les contraintes et la structure, mais quand les données changent, le processus de révision n'est généralement pas au point.

00:01:07L'option deux : on met les données dans un CSV, un JSON ou un YAML pour que git puisse les suivre. Maintenant, vous avez

00:01:13des commits et des pull requests, mais vous perdez ce qui fait la force des bases de données : pas de vrai SQL, des contraintes

00:01:20faibles, des diffs et des fusions pénibles. Et quand quelqu'un demande qui a changé cet enregistrement, la réponse

00:01:27est essentiellement : quelqu'un avec un accès à la base de données. Ce n'est pas un vrai

00:01:32flux de travail. Mais imaginez plutôt ceci : et si vous pouviez exécuter une commande de branche, "dolt branch fix this data",

00:01:39dolt diff, dolt commit, dolt merge ? Ce sont des commandes que nous utilisons déjà, mais nous les utilisons

00:01:46sur vos vraies tables de base de données. C'est ce que fait Dolt : c'est du contrôle de version pour nos bases de données.

00:01:52Si vous aimez les outils de développement pour accélérer votre travail, abonnez-vous, nous publions des vidéos

00:01:57constamment. Assez parlé, nous avons des options. Il y a Dolt pour SQLite, Postgres, et bien d'autres. Faisons la

00:02:04version rapide. Je vais naviguer ici et cloner la base "dolt hub" de démarrage depuis GitHub.

00:02:10Je vais dans le dossier. D'abord, cloner une base de données Dolt publique et exécuter "dolt sql". Maintenant, nous sommes

00:02:18dans le SQL, donc je peux exécuter des commandes SQL ici dans le terminal. OK, cool, je vais faire un petit changement

00:02:27et nous allons exécuter "dolt diff". C'est le moment de se dire : "Attends, que vient-il de se passer ici ?"

00:02:34Dolt ne dit pas juste qu'un fichier a changé, il montre la différence réelle dans la table : quelle ligne a changé, quelle colonne

00:02:43a changé, l'ancienne valeur et la nouvelle valeur. Je peux voir ça ici. Maintenant, on peut valider ça avec "dolt add",

00:02:50puis je peux exécuter "dolt commit -m" et ajouter un commentaire. Je peux créer une branche entière de ceci en utilisant

00:02:56"checkout -b" suivi du nom de votre branche. Si je fais un autre changement par-dessus, je peux

00:03:03le comparer avec "dolt diff", je peux le valider à nouveau, puis l'ajouter. Maintenant, si je reviens et

00:03:10que je fusionne, je peux repasser sur "main" et exécuter "dolt merge". Toutes ces commandes que nous connaissons déjà, nous les appliquons

00:03:17maintenant avec SQL. À la fin, vous pouvez exécuter "dolt log". Désormais, votre base de données a un historique de commits, pas une sauvegarde,

00:03:24pas un fichier dump, ni un simple log de modifications de tableur. Une vraie base de données de version, c'est toute l'idée.

00:03:31Des flux de travail git, mais pour des tables. Maintenant, prenons du recul et voyons comment tout cela fonctionne.

00:03:37Au début, Dolt semble familier, et c'est voulu. Vous avez des commandes comme "dolt status", "diff", "add", "commit", "branch",

00:03:44et "checkout". Si vous connaissez git, votre cerveau comprend déjà la forme de tout ce flux de travail.

00:03:48L'objectif de Dolt n'est pas de suivre des fichiers, mais des tables relationnelles. Vous pouvez l'utiliser en

00:03:55ligne de commande ou exécuter "dolt sql-server". En faisant cela, vous pouvez vous y connecter en utilisant des clients compatibles MySQL,

00:04:01des ORM, des outils BI ou du code applicatif. Ainsi, votre application peut traiter Dolt comme une base de données SQL normale, mais vous

00:04:09obtenez le contrôle de version pour les données. C'est la partie importante : vous ne choisissez pas entre une vraie

00:04:14base de données et un flux de travail git, vous obtenez les deux au même endroit. Dolt utilise quelque chose appelé "crawly tree".

00:04:22La version simple de "crawly tree" ici est qu'une base de données normale utilise des structures en arbre pour rendre les lectures et les écritures

00:04:29rapides. Dolt utilise une structure en arbre qui est également douée pour le versionnage. Donc, au lieu de copier toute la

00:04:36base de données à chaque commit, Dolt peut partager les parties qui sont restées les mêmes et suivre celles qui

00:04:42ont réellement changé. Maintenant, nous ne demandons pas seulement : "Quelle est la valeur actuelle ?" Nous pouvons demander

00:04:47des choses comme : "À quoi ressemblait cette ligne avant que quelque chose n'arrive ?" C'est le point majeur.

00:04:52Parce que quand quelque chose casse, on ne veut pas avoir à deviner. Vous voulez inspecter l'historique.

00:04:56Je peux maintenant passer en revue le diff, voir le changement, et si nécessaire, annuler. C'est du contrôle de version

00:05:02pour des données structurées. Vos branches, commits, diffs, fusions, historiques pour les lignes et colonnes. Alors, où Dolt

00:05:10s'intègre-t-il réellement dans le flux de travail ? Parce que tout cela semble génial, mais c'est là que ça peut devenir

00:05:15confus. Vous pouvez entendre "git pour les données" et vous pensez probablement : "D'accord, mais nous avons déjà

00:05:21des outils pour ça." Oui, nous avons des outils, mais ils résolvent des problèmes différents. Vous pouvez mettre des CSV

00:05:28et des fichiers JSON dans git, ça marche quand les données sont petites et simples. Mais git ne comprend pas votre schéma,

00:05:35il ne connaît pas votre clé primaire et n'appliquera pas de contraintes. Il ne peut pas exécuter de jointures sur vos CSV

00:05:41sauf si vous ajoutez d'autres outils. Git vous donne du contrôle de version, mais ce n'est pas vraiment pour une base de données.

00:05:47Ensuite, il y a DVC. DVC est excellent pour les flux de travail ML, en particulier les grands ensembles de données et les artefacts de modèle, mais

00:05:53il n'essaie pas d'être votre base de données relationnelle en direct. Oui, vous avez LakeFS qui apporte des idées de type git au

00:06:00stockage objet et aux lacs de données, très utile à l'échelle du lac, mais c'est encore une couche différente. Ce n'est

00:06:07pas la même chose que de dire : "Crée une branche de la table SQL, change quelques lignes, exécute un diff et fusionne le tout."

00:06:13Les bases de données traditionnelles ont aussi des outils d'historique : tables temporelles, journaux d'audit, CDC, mais la plupart d'entre eux

00:06:20ne semblent pas être un flux de travail normal. Ils ne vous donnent pas cette boucle propre : branche, modification, diff, fusion, annulation.

00:06:27Je ne suggérerais pas d'intégrer aveuglément Dolt dans chaque système de production, ce n'est pas le but. Le but est le suivant :

00:06:33si votre travail implique des données structurées qui changent avec le temps et que ces changements peuvent casser des choses,

00:06:40je pense que Dolt mérite d'être essayé. La première fois qu'il vous sauve d'un mauvais changement de données silencieux, le flux de travail

00:06:46commence à sembler plus évident. Nous avons git, pourquoi n'avons-nous pas quelque chose pour les données ? Maintenant, c'est un peu le cas. Si

00:06:52vous appréciez les outils comme celui-ci, assurez-vous de vous abonner à la chaîne "better stack". On se voit dans une autre

00:06:57vidéo.

Key Takeaway

Dolt transforme la gestion des données en permettant d'appliquer les flux de travail Git (branche, fusion, historique) directement aux tables SQL pour éviter les erreurs de manipulation silencieuses.

Highlights

Dolt propose un contrôle de version complet (branche, diff, commit, merge) appliqué directement aux données de tables SQL.
L'utilisation de structures en arbre (“crawly tree”) permet de suivre les modifications de données sans dupliquer l'intégralité de la base à chaque commit.
Les commandes Dolt reprennent la syntaxe Git, telles que “dolt branch
dolt diff”, et “dolt merge”, rendant le flux de travail familier pour les développeurs.
Il est possible d'exécuter Dolt en mode “dolt sql-server” pour une compatibilité directe avec les clients MySQL, les ORM et les outils de BI.
Dolt résout le problème de gestion des données structurées en offrant à la fois les contraintes SQL et la capacité de suivi des modifications impossible avec de simples fichiers CSV ou JSON.

Timeline

La problématique du versionnage des données

Les bases de données SQL traditionnelles manquent de flux de travail de collaboration comparables à Git.
Le stockage des données dans des fichiers CSV ou JSON dans Git garantit un suivi, mais sacrifie les contraintes SQL et les performances.

Le recours aux bases de données standards empêche un retour en arrière clair ou une révision efficace des modifications. À l'inverse, l'utilisation de fichiers plats pour faciliter le versionnage via Git annule les avantages structurels, d'indexation et de contraintes offerts par les bases de données SQL.

Fonctionnement du contrôle de version avec Dolt

Dolt permet d'exécuter des commandes de versionnage comme “dolt diff” ou “dolt merge” sur de vraies tables SQL.
L'exécution de “dolt diff” affiche les changements précis au niveau de la ligne et de la colonne, avec les anciennes et nouvelles valeurs.
Le workflow inclut la création de branches, la validation de modifications via des commits et la fusion d'historiques.

L'implémentation consiste à cloner une base Dolt, utiliser l'interface SQL pour modifier les données, puis utiliser les commandes Git pour valider et fusionner ces changements. Chaque modification est tracée, permettant de consulter l'historique complet avec “dolt log” au lieu de dépendre de sauvegardes ou de dumps de fichiers.

Architecture et intégration dans les flux de travail

Dolt utilise une structure en arbre (“crawly tree”) pour partager les parties inchangées entre les versions et optimiser le stockage.
Le serveur SQL intégré permet d'utiliser Dolt avec des outils BI, des ORM et des applications existantes.
Dolt se distingue des outils comme DVC ou LakeFS en ciblant spécifiquement les bases de données relationnelles en direct plutôt que le stockage objet ou les grands jeux de données ML.

L'architecture permet de ne pas copier toute la base de données à chaque commit, ce qui rend l'historisation efficace. Bien que des outils de logs d'audit ou de CDC existent dans les bases traditionnelles, ils ne reproduisent pas la boucle complète de développement Git (branche, modification, fusion, annulation) offerte par Dolt.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video