Dolt: Isso faz o SQL parecer com o Git

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

컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00seu código tem git, seus dados têm o quê exatamente? Esse é o problema, um CSV ruim, uma linha de configuração

00:00:07uma edição em planilha e agora seu aplicativo está quebrado. Não há diff limpo, não há branch, pull request, não há

00:00:13rollback óbvio. Isto é o Dolt, um banco de dados SQL que funciona exatamente como o git. Você pode criar branches de tabelas,

00:00:20editar linhas, ver diff das alterações, fazer commit e merge. Controle de versão real para dados reais. Vou

00:00:26te mostrar como configurar isso e como começar nos próximos minutos.

00:00:35Sabemos que na maior parte do tempo os bancos de dados são ótimos em ser bancos de dados. Eles armazenam dados, permitem

00:00:41consultas SQL, mas não são ótimos nos fluxos de trabalho que usamos todo dia, que envolvem branches,

00:00:47revisão, diff, merge, rollback, ver exatamente quem mudou o quê. Então, muitas vezes escolhemos

00:00:54uma de duas opções ruins. Opção um: manter os dados em um banco de dados real. Você obtém índices SQL,

00:01:00restrições e estrutura, mas quando os dados mudam, o processo de revisão geralmente não existe.

00:01:07Opção dois: colocar os dados em um CSV, JSON ou YAML para que o git possa rastreá-los. Agora você tem

00:01:13commits e pull requests, mas perde coisas em que os bancos de dados são bons: sem SQL real, sem

00:01:20aplicação de esquema, diffs e merges dolorosos. E quando alguém pergunta quem mudou este registro, bem, a resposta

00:01:27é basicamente a mesma: alguém com acesso ao banco de dados. Isso não é nenhum tipo de

00:01:32fluxo de trabalho real. Mas imagine isto: e se você pudesse rodar um comando de branch, "dolt branch, corrigir dados",

00:01:39dolt diff, dolt commit, dolt merge. Esses são comandos que já usamos, mas estamos usando-os

00:01:46contra suas tabelas de banco de dados reais. É isso que o Dolt faz, é controle de versão para nossos bancos de dados.

00:01:52Se você gosta de ferramentas de codificação para acelerar seu fluxo de trabalho, inscreva-se, temos vídeos saindo

00:01:57o tempo todo. Chega de conversa, temos opções, existe o Dolt para SQLite, Postgres, você escolhe. Vamos fazer a

00:02:04versão rápida disso. Vou acessar a pasta e clonar o banco de dados inicial do Dolt Hub do GitHub.

00:02:10Vou entrar na pasta, clonar um banco de dados Dolt público e rodar "dolt sql". Agora estamos

00:02:18dentro do SQL, então posso rodar comandos SQL aqui no terminal. Ok, legal, vou fazer uma pequena alteração

00:02:27e vamos rodar "dolt diff". Este é o primeiro momento de "espere, o que acabou de acontecer?"

00:02:34O Dolt não diz que algum arquivo mudou, ele mostra o diff real da tabela, qual linha mudou, qual coluna

00:02:43mudou, o valor antigo e o novo valor. Posso ver agora. Podemos fazer o commit com "dolt add"

00:02:50e depois rodar "dolt commit -m", adicionando um comentário. Posso criar um branch inteiro usando

00:02:56"checkout -b", dê um nome ao seu branch. Se eu fizer outra alteração aqui, posso

00:03:03ver o diff de novo com "dolt diff", posso fazer o commit novamente e depois adicionar. Agora se eu voltar e

00:03:10fizer o merge, posso dar checkout na main e rodar "dolt merge". Todos esses comandos já conhecemos, estamos apenas fazendo

00:03:17isso com SQL agora. No final, você pode rodar "dolt log". Agora seu banco de dados tem um histórico de commits, não um backup,

00:03:24não um arquivo de dump e não uma edição de planilha, mas um registro. Um banco de dados de versão real, essa é a ideia central aqui.

00:03:31Fluxos de trabalho do git, mas para tabelas. Agora vamos analisar como tudo isso funciona.

00:03:37De início, o Dolt parece familiar de propósito. Você tem comandos como "dolt status", "diff", "add", "commit", "branch",

00:03:44checkout. Se você conhece git, seu cérebro já entende a lógica de todo este fluxo de trabalho.

00:03:48O objetivo do Dolt não é rastrear arquivos, é rastrear tabelas relacionais. Você pode usar pela

00:03:55linha de comando ou rodar "dolt sql-server". Ao fazer isso, você pode conectar usando clientes

00:04:01compatíveis com MySQL, ORMs, ferramentas de BI ou código de aplicação. Assim, seu app pode tratar o Dolt como um banco de dados SQL normal, mas você

00:04:09obtém controle de versão sobre os dados. Essa é a parte importante, você não está escolhendo entre um banco de dados real

00:04:14e um fluxo de trabalho do git, você obtém ambos no mesmo lugar. O Dolt usa algo chamado Prolly Tree. A versão

00:04:22simples de Prolly Tree é: um banco de dados normal usa estruturas de árvore para tornar as leituras e gravações

00:04:29rápidas. O Dolt usa uma estrutura de árvore que também é boa em versionamento, então, em vez de copiar todo o

00:04:36banco de dados toda vez que você faz um commit, o Dolt pode compartilhar as partes que permaneceram iguais e rastrear as partes que

00:04:42realmente mudaram. Agora não estamos apenas perguntando coisas como "qual é o valor atual?", podemos perguntar

00:04:47coisas como "como essa linha estava antes de algo acontecer?". Esse é o grande ponto aqui,

00:04:52porque quando algo quebra, não queremos ter que adivinhar. Você quer inspecionar o histórico. Agora posso

00:04:56revisar o diff, você pode ver a alteração e, se necessário, fazer rollback. Isso é controle de versão

00:05:02para dados estruturados: branches, commits, diffs, merges, históricos para linhas e colunas. Então, onde o Dolt

00:05:10realmente se encaixa no fluxo de coisas? Porque tudo isso parece ótimo, mas é aqui que pode ficar

00:05:15confuso. Você pode ouvir "git para dados" e provavelmente pensa: "ok, bem, veja, já temos

00:05:21ferramentas para isso". Sim, meio que temos ferramentas para isso, mas elas resolvem problemas diferentes. Você pode colocar CSVs

00:05:28e arquivos JSON no git; isso funciona quando os dados são minúsculos e simples. O git não entende seu esquema,

00:05:35não conhece sua chave primária e não vai aplicar restrições, não pode rodar joins nos seus CSVs

00:05:41a menos que você adicione mais ferramentas. Então, o git lhe dá controle de versão, mas não é realmente para um banco de dados.

00:05:47Aí temos o DVC. O DVC é ótimo para fluxos de trabalho de ML, especialmente grandes conjuntos de dados e artefatos de modelo, mas

00:05:53não tenta ser seu banco de dados relacional ao vivo. Sim, temos o lakeFS que traz ideias tipo git para

00:06:00armazenamento de objetos e data lakes, muito útil em escala de lake, mas novamente, essa é uma camada totalmente diferente. Não

00:06:07é a mesma coisa que dizer "crie uma branch da tabela SQL, altere algumas linhas, rode um diff e faça o merge de volta".

00:06:13Bancos de dados tradicionais também possuem ferramentas de histórico: tabelas temporais, logs de auditoria, CDC, mas a maioria deles

00:06:20não parece um fluxo de trabalho normal. Eles não oferecem o ciclo limpo de branch, alterar, diff, merge, rollback.

00:06:27Eu não colocaria o Dolt cegamente em todos os sistemas de produção, não é esse o ponto. O ponto é este:

00:06:33se seu trabalho envolve dados estruturados que mudam ao longo do tempo e essas mudanças podem realmente quebrar coisas,

00:06:40acho que vale a pena tentar o Dolt. Na primeira vez que ele te salvar de uma mudança de dados ruim e silenciosa, o fluxo de trabalho

00:06:46começa a parecer um pouco mais óbvio. Temos o git, por que não temos algo para dados? Agora temos. Se

00:06:52você gosta de ferramentas de codificação como esta, certifique-se de se inscrever no canal Better Stack. Nos vemos em outro

00:06:57vídeo.

Key Takeaway

O Dolt traz o controle de versão do Git para bancos de dados SQL, permitindo gerenciar alterações, realizar merges e aplicar rollbacks em dados estruturados com a mesma lógica usada em código-fonte.

Highlights

O Dolt permite aplicar fluxos de trabalho do Git, como branches, diffs, merges e commits, diretamente em bancos de dados SQL.
Bancos de dados tradicionais falham em fornecer histórico de mudanças, enquanto o armazenamento de dados em arquivos CSV ou JSON no Git sacrifica a integridade do esquema e recursos SQL.
A tecnologia Prolly Tree permite que o Dolt versionar bancos de dados sem duplicar o conjunto inteiro de dados a cada commit, compartilhando apenas as partes inalteradas.
O Dolt oferece compatibilidade com clientes MySQL, ferramentas de BI e ORMs ao rodar o comando 'dolt sql-server'.
O histórico de um banco de dados Dolt permite visualizar mudanças exatas em nível de linha e coluna, facilitando rollbacks precisos após edições indevidas.

Timeline

O problema da gestão de dados

A ausência de controle de versão em bancos de dados tradicionais dificulta a reversão de erros.
O armazenamento de dados em arquivos como CSV ou JSON no Git perde recursos essenciais de bancos de dados, como esquemas e restrições.

Edições em planilhas ou erros de configuração frequentemente quebram aplicações sem deixar um rastro claro de quem realizou a alteração. O dilema entre utilizar bancos de dados SQL reais, sem fluxo de revisão, ou arquivos estáticos rastreáveis pelo Git, mas sem performance, cria uma lacuna operacional que impede o controle de dados eficaz.

Fluxo de trabalho operacional com Dolt

O Dolt utiliza comandos familiares do Git, como branch, diff, commit, checkout e merge, diretamente sobre tabelas SQL.
O comando 'dolt diff' exibe mudanças reais em nível de linha e coluna, mostrando valores antigos e novos simultaneamente.
O histórico gerado pelo Dolt não é um dump de arquivo, mas um registro sequencial de mudanças versionáveis.

Ao clonar um banco de dados, o usuário pode realizar alterações via SQL e identificar exatamente o que mudou com o comando 'dolt diff'. O processo permite criar branches para isolar mudanças, realizar o commit do trabalho e mesclar de volta, mantendo um log completo acessível via 'dolt log'.

Funcionamento técnico e posicionamento

A estrutura Prolly Tree permite o versionamento eficiente de dados ao compartilhar partes estáticas entre commits em vez de replicar o banco inteiro.
O Dolt pode atuar como um servidor SQL compatível com MySQL, integrando-se a aplicações e ORMs existentes.
Ferramentas como DVC ou lakeFS servem a propósitos distintos, como fluxo de machine learning ou data lakes, não substituindo a funcionalidade de um banco relacional vivo.

O Dolt se posiciona como uma solução para dados estruturados que sofrem mudanças constantes e críticas ao longo do tempo. Ele preenche a lacuna deixada pelo Git, DVC e tabelas temporais, oferecendo um fluxo de trabalho de versionamento completo para bancos de dados ativos sem a necessidade de abandonar o SQL.

Community Posts

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

Write about this video