Bases de datos · Avanzado 4

Datos distribuidos, NoSQL y gobierno

Replicación, particionado, consistencia, elección de modelos no relacionales, linaje, calidad y ciclo de vida de los datos.

3
lecciones
3
ejercicios resueltos
CONTENIDO ORIGINAL

Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.

ANTES DE EMPEZAR

Ubícate antes de avanzar

01 / PUNTO DE PARTIDA

Conviene haber comprendido Migraciones, pruebas y observabilidad.

02 / META OBSERVABLE

Al terminar deberías poder relacionar Distribución con NoSQL y resolver un caso nuevo.

03 / TIEMPO SUGERIDO

Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.

04 / PREPARA EL LABORATORIO

Las primeras secciones se leen sin instalar nada. Para practicar SQL prepara PostgreSQL o un DBMS equivalente.

Abrir la guía de herramientas →
Diagnóstico rápido: ¿cómo se relacionan Distribución y NoSQL?

No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.

Ruta guiada · 3 lecciones

Aprende el tema paso a paso

Cerrarás la ampliación entendiendo decisiones que aparecen cuando los datos crecen, se reparten entre nodos y necesitan calidad, propiedad y ciclo de vida explícitos.

Al terminar podrás
  • Replicar mejora disponibilidad; particionar reparte capacidad
  • NoSQL ofrece formas distintas, no una sustitución universal de SQL
  • Un dato útil necesita definición, responsable, linaje y fecha de eliminación
01
Repartir datos

Replicar mejora disponibilidad; particionar reparte capacidad

Una réplica mantiene copias para lectura o recuperación. Un particionado distribuye subconjuntos por una clave. Ambos introducen latencia, fallos parciales y decisiones sobre qué versión puede leer cada operación.

01

Elige una clave que distribuya carga y preserve consultas frecuentes.

02

Define cuánto atraso de réplica tolera cada lectura.

03

Prueba qué ocurre al perder un nodo o una conexión.

Comprueba lo aprendido · 01

¿Añadir réplicas aumenta automáticamente la capacidad de escritura?

Mostrar respuesta

No. Cada escritura debe propagarse. Las réplicas suelen ampliar lectura y disponibilidad; escalar escrituras requiere particionado u otra arquitectura.

02
Elegir un modelo

NoSQL ofrece formas distintas, no una sustitución universal de SQL

Clave-valor favorece accesos directos; documentos agrupan datos que cambian juntos; grafos priorizan recorridos de relaciones; columnas anchas distribuyen grandes volúmenes por claves. El modelo relacional sigue siendo fuerte para integridad y consultas variadas.

01

Diseña desde patrones de acceso y reglas de consistencia.

02

Acepta duplicación solo con una estrategia de actualización.

03

Evalúa operación, respaldo y habilidades, no solo rendimiento.

Comprueba lo aprendido · 02

¿Un documento evita por completo las relaciones?

Mostrar respuesta

No. Puede incrustar datos o guardar referencias, pero las relaciones siguen existiendo en el dominio. Solo cambia dónde se resuelven y cómo se mantiene su consistencia.

03
Gobernar el ciclo de vida

Un dato útil necesita definición, responsable, linaje y fecha de eliminación

Un catálogo explica significado y propietario; el linaje muestra origen y transformaciones; reglas de calidad detectan degradación. Minimización y retención evitan conservar información sensible sin propósito.

01

Define métricas con unidad, población y momento de cálculo.

02

Registra quién puede acceder y con qué finalidad.

03

Elimina o anonimiza cuando termina la necesidad legítima.

Comprueba lo aprendido · 03

¿Respaldar para siempre es una buena política de conservación?

Mostrar respuesta

No. Aumenta exposición, costo y dificultad para cumplir eliminaciones. Los respaldos también necesitan una retención definida y segura.

Resumen de la sección

Tu recorrido en tres ideas

  1. Replicar mejora disponibilidad; particionar reparte capacidad
  2. NoSQL ofrece formas distintas, no una sustitución universal de SQL
  3. Un dato útil necesita definición, responsable, linaje y fecha de eliminación
PROFUNDIZACIÓN / LABORATORIO GUIADO

Separa catálogo, pagos y recomendaciones

Integra patrones de acceso, consistencia, partición, propiedad, linaje y eliminación de datos.

CASO

Una tienda necesita búsquedas globales, pagos correctos y recomendaciones que pueden aceptar algunos minutos de atraso.

Procedimiento

  1. Define reglas, lecturas, escrituras y tolerancia al atraso de cada dominio.
  2. Elige réplica, partición y modelo de datos desde esos accesos.
  3. Asigna propietario, origen, calidad, retención y procedimiento de eliminación.

Evidencia mínima

  • Reglas de consistencia explícitas.
  • Clave de partición y punto de fallo conocidos.
  • Linaje y ciclo de vida por conjunto de datos.
Mostrar razonamiento modelo

Pagos priorizan transacciones e idempotencia; recomendaciones pueden usar vistas atrasadas; catálogo necesita búsqueda y disponibilidad. No existe un único modelo ganador: cada decisión se justifica por su regla más costosa de romper.

Para ir más lejos

¿Qué datos deben desaparecer cuando una persona elimina su cuenta?

CIERRE DE LA SECCIÓN

Comprueba que puedes usarlo

Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.

ERROR 01

Elegir NoSQL porque “escala” sin definir accesos y consistencia.

ERROR 02

Conservar datos y respaldos indefinidamente sin finalidad.

DESAFÍO INTEGRADOR

Ahora hazlo sin guía

Diseña dónde almacenar catálogo, pagos y recomendaciones, y documenta réplica, partición, propietario y retención.

Mostrar pauta de corrección
Una respuesta sólida:
  • Justifica cada modelo desde las reglas.
  • Declara lecturas que toleran atraso y las que no.
  • Incluye linaje, acceso, calidad y eliminación.