Transcript
00:00:00tu código tiene git, pero tus datos, ¿qué tienen exactamente? ese es el problema: un CSV malo, una fila de configuración
00:00:07una edición en una hoja de cálculo y ahora tu aplicación está rota. sin diffs limpios, sin ramas, sin pull request, no
00:00:13hay una reversión obvia. esto es dolt, es una base de datos SQL que funciona igual que git. puedes ramificar tablas
00:00:20editar filas, ver diferencias, confirmarlas y fusionarlas. control de versiones real para datos reales. te
00:00:26mostraré cómo poner esto en marcha en los próximos minutos.
00:00:35sabemos que la mayoría de las veces las bases de datos son excelentes siendo bases de datos. almacenan información, te permiten
00:00:41consultar con SQL, pero no son geniales para los flujos de trabajo que usamos a diario, como ramificar,
00:00:47revisar, comparar, fusionar, revertir, ver exactamente quién cambió qué. así que a menudo elegimos
00:00:54una de dos malas opciones. la opción uno es mantener los datos en una base de datos real: tienes índices SQL,
00:01:00restricciones y estructura, pero cuando los datos cambian, el proceso de revisión suele fallar.
00:01:07luego, la opción dos es poner los datos en un CSV, JSON o YAML para que git pueda rastrearlos. ahora obtienes
00:01:13commits y pull requests, pero pierdes cosas en las que las bases de datos son buenas: nada de SQL real, débil
00:01:20cumplimiento de esquema, comparaciones y fusiones dolorosas. y cuando alguien pregunta quién cambió este registro, bueno, la respuesta
00:01:27básicamente será: alguien con acceso a la base de datos. eso no es ningún tipo de flujo
00:01:32de trabajo real. pero ahora imagina esto: ¿qué tal si pudieras ejecutar un comando de rama: dolt branch arreglar-datos
00:01:39dolt diff, dolt commit, dolt merge. estos son comandos que ya estamos usando, pero los estamos aplicando
00:01:46contra tus tablas de base de datos reales. eso es lo que hace dolt: es control de versiones para nuestras bases de datos.
00:01:52si disfrutas de herramientas de codificación para acelerar tu flujo de trabajo, asegúrate de suscribirte. tenemos videos saliendo
00:01:57todo el tiempo. basta de hablar, tenemos opciones: hay dolt para SQLite, Postgres, lo que sea. hagamos la
00:02:04versión rápida de esto. voy a entrar aquí y clonar la base de datos de inicio de DoltHub desde GitHub.
00:02:10entraré en la carpeta. ahora, primero, clona una base de datos dolt pública y ejecutaré dolt sql. ahora estamos
00:02:18dentro de SQL, así que puedo ejecutar comandos SQL aquí mismo en la terminal. bien, genial. voy a hacer un pequeño cambio
00:02:27y vamos a ejecutar dolt diff. y este es el primer momento de “espera, ¿qué acaba de pasar aquí?”
00:02:34dolt no dice que algún archivo cambió, muestra la diferencia real de la tabla: qué fila cambió, qué columna
00:02:43cambió, el valor antiguo y el nuevo valor. puedo verlo aquí mismo. ahora podemos confirmar eso, así que dolt add,
00:02:50luego puedo ejecutar dolt commit -m. agregaré un comentario. puedo crear una rama entera de esto usando
00:02:56checkout, y simplemente ejecutaremos checkout -b, nombra tu rama. si hago otro cambio sobre esto, puedo
00:03:03compararlo de nuevo con dolt diff, puedo confirmarlo otra vez y luego puedo agregarlo otra vez. ahora, si vuelvo y
00:03:10fusiono, puedo cambiar a main y ejecutar dolt merge. todos estos comandos ya los conocemos, solo que los estamos haciendo
00:03:17ahora con SQL. al final, podrías ejecutar dolt log. ahora tu base de datos tiene un historial de confirmaciones, no una copia de seguridad,
00:03:24no un archivo de volcado y no un registro de edición de hoja de cálculo. una base de datos de versión real, esa es la idea central aquí,
00:03:31flujos de trabajo de git pero para tablas. ahora, analicemos todo y veamos cómo funciona esto realmente.
00:03:37al principio, dolt se siente familiar a propósito: tienes comandos como dolt status, diff, add, commit, branch,
00:03:44checkout. si conoces git, tu cerebro ya entiende la forma de todo este flujo de trabajo.
00:03:48el objetivo de dolt no es rastrear archivos, es rastrear tablas relacionales. puedes usarlo desde la
00:03:55línea de comandos o puedes ejecutar dolt sql-server. al hacer eso, ahora puedes conectarlo usando clientes compatibles con MySQL,
00:04:01ORM, herramientas de BI o código de aplicación. así que tu aplicación puede tratar a dolt como una base de datos SQL normal, pero
00:04:09obtienes control de versiones sobre los datos. esa es la parte importante: no estás eligiendo entre una base de datos real
00:04:14y un flujo de trabajo de git, obtienes ambos en el mismo lugar. dolt utiliza algo llamado Prolly Tree. la versión
00:04:22fácil de Prolly Tree aquí es que una base de datos normal utiliza estructuras en forma de árbol para hacer que las lecturas y escrituras
00:04:29sean rápidas. dolt utiliza una estructura similar a un árbol que también es buena para el versionado, así que en lugar de copiar toda
00:04:36la base de datos cada vez que haces un commit, dolt puede compartir las partes que permanecieron iguales y rastrear las partes que
00:04:42realmente cambiaron. ahora no solo preguntamos cosas como, oye, ¿cuál es el valor actual? podemos preguntar realmente
00:04:47cosas como, ¿cómo se veía esta fila antes de que pasara algo? eso es lo más importante aquí,
00:04:52porque cuando algo se rompe no queremos tener que adivinar, quieres inspeccionar el historial. ahora puedo
00:04:56revisar la diferencia, puedes ver el cambio y, si es necesario, puedes revertirlo. esto es control de versiones
00:05:02para datos estructurados. tus ramas, confirmaciones, diferencias, fusiones, historiales para filas y columnas. entonces, ¿dónde encaja dolt
00:05:10realmente en el flujo de las cosas? porque todo esto suena genial, pero aquí es donde podría volverse
00:05:15confuso. podrías escuchar “git para datos” y probablemente estarías pensando, bueno, mira, ya tenemos
00:05:21herramientas para eso. sí, en cierto modo tenemos herramientas para eso, pero resuelven problemas diferentes. puedes poner CSV
00:05:28y archivos JSON en git; eso funciona cuando los datos son pequeños y simples. git no entiende tu esquema,
00:05:35no conoce tu clave principal y no va a hacer cumplir las restricciones. no puede ejecutar uniones en tu CSV
00:05:41a menos que agregues más herramientas, así que git te da control de versiones, pero no es realmente para una base de datos.
00:05:47luego está DVC. DVC es genial para flujos de trabajo de ML, especialmente para conjuntos de datos grandes y artefactos de modelos, pero
00:05:53no intenta ser tu base de datos relacional en vivo. sí, tienes lakeFS, que trae ideas similares a git al
00:06:00almacenamiento de objetos y lagos de datos, muy útil a escala de lago, pero de nuevo, esa es una capa completamente diferente. no es
00:06:07lo mismo que decir: ramifica la tabla SQL, cambia algunas filas, ejecuta una comparación y fúndela de nuevo.
00:06:13las bases de datos tradicionales también tienen herramientas de historial: tablas temporales, registros de auditoría, CDC, pero la mayoría de ellas
00:06:20no se sienten como un flujo de trabajo normal. no te dan el ciclo limpio de rama, cambio, comparación, fusión, reversión.
00:06:27yo no pondría a dolt a ciegas en cada sistema de producción; ese no es el punto aquí. el punto es este:
00:06:33si tu trabajo involucra datos estructurados que cambian con el tiempo y esos cambios realmente pueden romper cosas,
00:06:40creo que vale la pena probar dolt. la primera vez que te salva de un cambio de datos malo y silencioso, el flujo de trabajo
00:06:46empieza a sentirse un poco más obvio. tenemos git, ¿por qué no tenemos algo para los datos? ahora, en cierto modo, sí.
00:06:52si disfrutas de herramientas de codificación como esta, asegúrate de suscribirte al canal de Better Stack. nos vemos en otro
00:06:57video.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video