Dolt: Damit fühlt sich SQL an wie Git
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Dein Code ist versioniert, aber deine Daten? Genau das ist das Problem. Eine fehlerhafte CSV, eine Zeile in der Config,
00:00:07eine bearbeitete Tabelle und schon ist deine App kaputt. Es gibt keinen sauberen Diff, keinen Branch, keinen Pull Request,
00:00:13kein offensichtliches Rollback. Das hier ist Dolt, eine SQL-Datenbank, die genau wie Git funktioniert. Du kannst Tabellen verzweigen,
00:00:20Zeilen bearbeiten, Änderungen vergleichen, sie committen und wieder zusammenführen. Echte Versionskontrolle für echte Daten.
00:00:26Ich zeige dir in den nächsten paar Minuten, wie man das aufsetzt und loslegt.
00:00:35Wir wissen, dass Datenbanken meistens gut darin sind, Datenbanken zu sein. Sie speichern Daten und ermöglichen es,
00:00:41SQL-Abfragen zu machen, aber sie sind nicht gut in den Workflows, die wir täglich nutzen: Branching,
00:00:47Überprüfen, Diffs erstellen, Mergen, Rollbacks, genau sehen, wer was geändert hat. Also wählen wir oft
00:00:54eine von zwei schlechten Optionen. Option eins: Du behältst die Daten in einer echten Datenbank, du hast SQL-Indizes,
00:01:00Constraints und Struktur, aber wenn sich die Daten ändern, ist der Review-Prozess meist nicht wirklich vorhanden.
00:01:07Dann Option zwei: Wir speichern die Daten in CSV, JSON oder YAML, damit Git sie tatsächlich tracken kann. Jetzt hast du
00:01:13Commits und Pull Requests, aber du verlierst Dinge, die Datenbanken gut können: kein echtes SQL, schwache
00:01:20Schemadurchsetzung, schmerzhafte Diffs und Merges. Und wenn jemand fragt, wer diesen Datensatz geändert hat, lautet die Antwort
00:01:27eigentlich nur: jemand mit Datenbankzugriff. Das ist keine Art von echtem
00:01:32Workflow. Aber stell dir stattdessen das vor: Was wäre, wenn du einen Branch-Befehl ausführen könntest? Dolt branch, Daten fixen,
00:01:39Dolt diff, Dolt commit, Dolt merge. Das sind Befehle, die wir bereits verwenden, aber wir wenden sie
00:01:46auf deine tatsächlichen Datenbanktabellen an. Das ist es, was Dolt tut: Versionskontrolle für unsere Datenbanken.
00:01:52Wenn dir Coding-Tools gefallen, die deinen Workflow beschleunigen, abonniere den Kanal. Wir bringen ständig Videos raus.
00:01:57Genug geredet. Wir haben Optionen, es gibt Dolt für SQLite, Postgres, was auch immer. Lass uns die
00:02:04schnelle Version davon machen. Ich wechsle hierhin und clone den Dolt-Hub “Getting Started” von GitHub.
00:02:10Ich gehe in den Ordner, clone jetzt zuerst eine öffentliche Dolt-Datenbank und führe Dolt sql aus. Jetzt sind wir
00:02:18in SQL, also kann ich direkt hier im Terminal SQL-Befehle ausführen. Okay, cool, ich mache eine kleine Änderung
00:02:27und wir führen Dolt diff aus. Und das ist der erste “Moment mal, was ist gerade passiert?”-Moment.
00:02:34Dolt sagt nicht nur, dass sich eine Datei geändert hat. Es zeigt den tatsächlichen Tabellen-Diff: Welche Zeile hat sich geändert, welche Spalte
00:02:43hat sich geändert, der alte Wert und der neue Wert. Das kann ich hier direkt sehen. Jetzt können wir das committen: Dolt add,
00:02:50dann kann ich Dolt commit -m ausführen, ich füge einen Kommentar hinzu. Ich kann einen kompletten Branch davon erstellen, indem ich
00:02:56checkout verwende, und wir führen einfach checkout -b und den Namen deines Branches aus. Wenn ich darauf noch eine Änderung mache, kann ich
00:03:03es wieder vergleichen mit Dolt diff, ich kann es wieder committen und dann kann ich es wieder hinzufügen. Jetzt, wenn ich zurückspringe und
00:03:10merge, kann ich zu Main auschecken und Dolt merge ausführen. Alle diese Befehle kennen wir schon, wir machen
00:03:17das jetzt mit SQL. Am Ende kannst du Dolt log ausführen. Jetzt hat deine Datenbank eine Commit-Historie, kein Backup,
00:03:24keine Dump-Datei und kein Bearbeitungslog einer Tabelle, sondern eine echte Versionsdatenbank. Das ist die Kernidee hier,
00:03:31Git-Workflows, aber für Tabellen. Lass uns alles zusammenfassen und sehen, wie das alles funktioniert.
00:03:37Zuerst fühlt sich Dolt absichtlich vertraut an. Du hast Befehle wie Dolt status, diff, add, commit, branch,
00:03:44checkout. Wenn du Git kennst, versteht dein Gehirn schon die Form dieses gesamten Workflows.
00:03:48Was Dolt anstrebt: Es trackt keine Dateien, es trackt relationale Tabellen. Du kannst es von der
00:03:55Kommandozeile aus nutzen oder Dolt sql-server starten. Dadurch kannst du es jetzt mit MySQL-kompatiblen
00:04:01Clients, ORMs, BI-Tools oder Anwendungscode verbinden. Deine App kann Dolt also wie eine normale SQL-Datenbank behandeln, aber du
00:04:09erhältst Versionskontrolle für die Daten. Das ist der wichtige Teil. Du entscheidest dich nicht zwischen einer echten
00:04:14Datenbank und einem Git-Workflow, du bekommst beides am selben Ort. Dolt nutzt etwas namens “Crawl Tree”. Die einfache
00:04:22Version von Crawl Tree hier ist: Eine normale Datenbank nutzt baumartige Strukturen, um Lese- und Schreibvorgänge
00:04:29schnell zu machen. Dolt nutzt eine baumartige Struktur, die auch gut im Versionieren ist. Anstatt die ganze
00:04:36Datenbank bei jedem Commit zu kopieren, kann Dolt die Teile teilen, die gleich geblieben sind, und die Teile tracken, die sich
00:04:42tatsächlich geändert haben. Jetzt fragen wir nicht nur Dinge wie: “Was ist der aktuelle Wert?”, sondern können tatsächlich
00:04:47fragen: “Wie sah diese Zeile aus, bevor etwas passiert ist?”. Das ist die große Sache hier,
00:04:52denn wenn etwas kaputtgeht, wollen wir nicht raten müssen. Du willst die Historie untersuchen. Ich kann jetzt
00:04:56den Diff überprüfen, die Änderung sehen und falls nötig, ein Rollback durchführen. Das ist Versionskontrolle
00:05:02für strukturierte Daten. Deine Branches, Commits, Diffs, Merges und Historien für Zeilen und Spalten. Also, wo passt Dolt
00:05:10eigentlich in den Ablauf der Dinge? Denn das klingt alles großartig, aber hier könnte es verwirrend werden.
00:05:15Du hörst “Git für Daten” und denkst wahrscheinlich: “Okay, nun, wir haben doch schon
00:05:21Tools dafür.” Ja, irgendwie haben wir Tools dafür, aber sie lösen andere Probleme. Du kannst CSVs
00:05:28und JSON-Dateien in Git ablegen. Das funktioniert, wenn die Daten winzig und einfach sind. Git versteht dein Schema nicht,
00:05:35kennt nicht deinen Primärschlüssel und wird keine Constraints durchsetzen. Es kann keine Joins auf deiner CSV ausführen,
00:05:41es sei denn, du fügst weitere Tools hinzu. Also gibt Git dir Versionskontrolle, aber sie ist nicht wirklich für eine Datenbank.
00:05:47Dann gibt es DVC. DVC ist großartig für ML-Workflows, besonders für große Datensätze und Modell-Artefakte, aber
00:05:53es versucht nicht, deine live relationale Datenbank zu sein. Ja, du hast LakeFS, das Git-ähnliche Ideen in
00:06:00Objektspeicher und Data Lakes bringt. Sehr nützlich auf Lake-Skala, aber wieder: Das ist eine völlig andere Ebene.
00:06:07Es ist nicht dasselbe, wie zu sagen: “Branch die SQL-Tabelle, ändere ein paar Zeilen, führ einen Diff aus und merge es zurück”.
00:06:13Traditionelle Datenbanken haben auch Historien-Tools, temporale Tabellen, Audit-Logs, CDC, aber die meisten von ihnen
00:06:20fühlen sich nicht wie ein normaler Workflow an. Sie geben dir nicht den sauberen Kreislauf aus Branch, Ändern, Diff, Merge, Rollback.
00:06:27Ich würde Dolt nicht blind in jedes Produktionssystem werfen, das ist hier nicht der Punkt. Der Punkt ist dieser:
00:06:33Wenn deine Arbeit strukturierte Daten beinhaltet, die sich im Laufe der Zeit ändern, und diese Änderungen tatsächlich Dinge kaputtmachen können,
00:06:40glaube ich, dass Dolt einen Versuch wert ist. Das erste Mal, wenn es dich vor einer stillen, fehlerhaften Datenänderung bewahrt, beginnt der
00:06:46Workflow, sich etwas offensichtlicher anzufühlen. Wir haben Git, warum haben wir nichts für Daten? Jetzt haben wir es irgendwie.
00:06:52Wenn dir Coding-Tools wie dieses gefallen, abonniere den Better-Stack-Kanal. Wir sehen uns im nächsten
00:06:57Video.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video