Ce clone Git répare votre base de données

Votre code vit en toute sécurité dans Git, mais qu'en est-il de vos données ? Pendant trop longtemps, les ingénieurs ont été confrontés à deux mauvais choix. Ils pouvaient conserver les données dans une véritable base de données, bénéficiant de SQL, d'index et de l'intégrité du schéma, mais sacrifiant tout workflow de contrôle de version significatif. Ou bien, ils pouvaient suivre des fichiers plats – CSV, JSON ou YAML – dans Git, obtenant des commits et des pull requests au prix d'une interrogation puissante, d'une application robuste du schéma et de diffs de données simples. Ce faux dilemme force un compromis entre l'utilité des données et le workflow du développeur.

Les journaux d'audit traditionnels et les tables temporelles n'offrent que peu de réconfort. Ils fonctionnent comme un enregistrement statique, non comme un workflow dynamique. Ces systèmes ne parviennent pas à fournir des diffs propres au niveau des lignes et des colonnes, manquent la capacité de créer des branches expérimentales, ou de faciliter des fusions simples. Sans ces capacités, l'historique de la base de données reste un registre opaque, incapable de prendre en charge les pratiques de développement collaboratif modernes.

Les conséquences de ce déficit sont graves. Un seul changement incorrect dans une feuille de calcul, une ligne mal configurée ou une mauvaise édition de CSV peut instantanément paralyser une application entière. Sans diff clair, sans branche et sans chemin de rollback évident, le débogage devient un jeu de devinettes frénétique. Identifier le coupable et inverser les dégâts est souvent un processus manuel et chronophage, manquant de la précision et de la confiance d'un rollback de code alimenté par Git.

Dolt apporte le workflow Git familier directement aux tables SQL, changeant fondamentalement la façon dont les développeurs gèrent les données structurées. Au lieu de se débattre avec des fichiers plats, les utilisateurs exécutent des commandes comme `dolt branch`, `dolt diff`, `dolt commit` et `dolt merge` sur des tables de base de données en direct et leurs schémas. Cette intégration robuste fournit un véritable contrôle de version pour les données, intégrant les pratiques de développement modernes – comme la revue collaborative et les rollbacks – dans la couche de la base de données elle-même, là où les données vivent réellement.

Au-delà de la simple détection des modifications de fichiers, Dolt fournit des diffs de données sémantiques et granulaires. Il identifie précisément quelle ligne et quelle colonne ont changé, présentant une vue côte à côte claire des anciennes et nouvelles valeurs. Cette perspicacité détaillée est inestimable pour l'audit, le débogage et la compréhension de l'évolution complète des données au fil du temps, dépassant de loin le contexte limité du versionnement traditionnel basé sur les fichiers ou des journaux d'audit génériques. Vous voyez ce qui a changé, pas seulement que quelque chose a changé.

De manière cruciale, Dolt fonctionne comme un remplacement direct de MySQL, utilisant le protocole filaire et le dialecte de requête MySQL standard. Cela signifie que les applications existantes, les ORMs et les outils de business intelligence peuvent se connecter à un serveur Dolt de manière transparente, sans nécessiter de modifications de code ou de refactoring extensif. Les équipes obtiennent ainsi de puissantes capacités de versionnement, de branchement et de fusion de données pour leurs bases de données de production, tout en maintenant la compatibilité avec leur pile technologique actuelle et en tirant parti de leurs investissements existants dans les outils MySQL.

Dolt réalise ses capacités de type Git grâce à un moteur de stockage personnalisé construit autour des Prolly Trees. Cette structure de données avancée permet un stockage efficace et adressable par contenu. Contrairement aux bases de données traditionnelles qui pourraient copier des ensembles de données entiers lors d'un commit, les Prolly Trees de Dolt partagent les blocs de données inchangés, ne stockant que les deltas. Cette conception réduit radicalement la surcharge de stockage et assure des opérations de commit rapides.

Cette architecture sous-jacente se traduit directement par des performances supérieures. Des benchmarks récents démontrent que Dolt 2.0 non seulement égale mais souvent surpasse MySQL sur les opérations de lecture et d'écriture. Associé à cette vitesse, Dolt affiche une empreinte de stockage 30 à 50 % plus petite que son homologue traditionnel, ce qui en fait un choix plus économique pour les données versionnées.

Au-delà des performances brutes, Dolt repousse les limites avec des fonctionnalités uniques. C'est la première base de données à offrir un versionnement natif pour les AI embeddings et les données vectorielles. Cette innovation cruciale fournit un historique auditable pour les opérations d'apprentissage automatique, garantissant des workflows MLOps reproductibles et améliorant la fiabilité des agents d'IA. Pour des informations techniques plus approfondies, consultez la Base de données versionnée | Documentation Dolt.

Dolt redéfinit radicalement le versionnement des données, allant au-delà des limitations des outils existants. Il n'est pas conçu pour le stockage d'objets volumineux comme lakeFS, ni ne se contente de suivre des pointeurs de fichiers comme DVC. Au lieu de cela, Dolt cible les données relationnelles structurées et en direct, offrant un véritable contrôle de version de style Git directement sur les tables SQL, avec application du schéma et des diffs efficaces au niveau des lignes. Cela élève la gestion des données d'un suivi basé sur les fichiers à un workflow de base de données entièrement intégré.

Cette capacité débloque de nouveaux workflows puissants dans divers domaines. Dolt excelle dans la gestion des ensembles de données ML, garantissant la reproductibilité et l'auditabilité pour l'entraînement et l'expérimentation des modèles. Il rationalise les pipelines CI/CD pour les données de test, permet le développement collaboratif de configurations de jeux et donne aux ingénieurs les moyens de créer des outils internes auditables avec un historique complet des modifications. Même les migrations de données de production complexes deviennent significativement plus sûres, permettant un retour instantané à tout état antérieur.

L'adoption de Dolt présente une voie sans risque pour les organisations déjà dépendantes de MySQL. Les utilisateurs peuvent déployer Dolt comme une réplique MySQL, reflétant une base de données de production existante sans la remplacer. Cela fournit immédiatement un historique complet et versionné de manière granulaire de toutes les modifications de données, offrant des informations puissantes et des options de récupération. Vos applications continuent d'interagir avec la base de données principale, tandis que Dolt construit discrètement une lignée de données inestimable et versionnée en arrière-plan.

Qu'est-ce que Dolt ?

Dolt est une base de données SQL qui intègre les fonctionnalités de contrôle de version de Git, vous permettant de brancher, committer, diff, fusionner et restaurer des tables de données comme du code source.

En quoi Dolt est-il différent de l'utilisation de Git avec des fichiers CSV ?

Dolt comprend les schémas SQL, applique les contraintes et fournit des diffs granulaires au niveau des lignes et des colonnes. Git traite les CSV comme de simples fichiers texte, n'offrant aucune de la structure, de la puissance de requête ou du diff détaillé d'une véritable base de données.

Dolt est-il un remplacement direct pour MySQL ou PostgreSQL ?

Cela peut l'être. Dolt est compatible filaire MySQL, et son homologue Doltgres est compatible PostgreSQL. Dolt peut même surpasser MySQL dans certains benchmarks et peut fonctionner comme une réplique non intrusive d'une base de données MySQL en direct.

Quels sont les principaux cas d'utilisation de Dolt ?

Il est idéal pour le versionnement des ensembles de données ML, la gestion de la configuration des applications, la création d'historiques de données auditables, la curation collaborative de données et la mise en place d'environnements sûrs et isolés pour tester les modifications de données.