Antes de comenzar
Caracterizarás una clave de partición con SQL real, formularás una hipótesis sobre distribución y disponibilidad, configurarás un clúster simulado, fallarás nodos a propósito y decidirás qué factor de replicación recomendarías para producción.
Producirás una evidencia de aprendizaje con tu hipótesis, tus mediciones de skew/disponibilidad y tu decisión justificada. Tiempo orientativo: 30–40 minutos.
¿Distribución equilibrada o disponibilidad garantizada?
- Contexto
- Un nodo del clúster de NexoRetail 360 falló el mes pasado durante una campaña y algunos pedidos quedaron temporalmente inaccesibles.
- Problema
- Dirección técnica pregunta: ¿cuántos nodos y qué factor de replicación se necesitan para que un fallo aislado no vuelva a bloquear operaciones, sin gastar en réplicas que no se justifiquen?
- Misión
- Pregunta central: ¿cómo afecta la elección de clave de partición, factor de replicación y número de nodos a la distribución y disponibilidad de los datos?
- Decisión esperada
- Recomendar una clave de partición y un factor de replicación para producción, justificados con la disponibilidad, el skew y el riesgo observados.
Objetivos de la sesión
- Diferenciar particionado (dónde vive un dato) de replicación (cuántas copias tiene).
- Medir disponibilidad y riesgo de pérdida ante fallos de nodo.
- Comparar el costo de almacenamiento y la latencia aproximada entre consistencia fuerte y eventual.
- Justificar un factor de replicación con evidencia, no por defecto.
Identidad, partición y replicación
Cada registro tiene una identidad lógica (recordId) y, por separado, un valor de partición (partitionValue) que una función hash convierte en el nodo donde vive originalmente. Ese es el particionado. La replicación es un concepto distinto: cuántas copias adicionales de ese mismo dato se guardan para tolerar un fallo de nodo. Ambos se miden por separado en este laboratorio.
El resto de los conceptos (skew, disponibilidad, fallo de nodo, rebalancing) se irán introduciendo justo antes de que los uses, en las secciones de Experimento y Análisis — no hace falta memorizarlos todos ahora. DuckDB-Wasm (Laboratorio de datos) caracteriza el dato real; el particionado/replicación/fallos los calcula el modelo del clúster de esta semana, no DuckDB.
Pasos del laboratorio
- Inspecciona filas reales en el Laboratorio de datos (abajo).
- Elige o inspecciona una clave de partición candidata.
- Predice cómo se distribuirá entre nodos.
- Formula tu hipótesis antes de ver resultados.
- Configura nodos y factor de replicación.
- Distribuye filas reales en el clúster simulado.
- Observa el skew y las copias físicas.
- Falla un nodo a propósito.
- Analiza el efecto sobre la disponibilidad.
- Rebalancea/re-replica y decide.
Laboratorio de datos: caracteriza antes de particionar
El laboratorio procesa una muestra manejable localmente y utiliza esa muestra para estudiar decisiones arquitectónicas aplicables a sistemas de mucha mayor escala. DuckDB-Wasm calcula realmente cardinalidad y filas por clave; el particionado/replicación/fallos que ves en las secciones siguientes los sigue calculando el modelo del clúster de esta semana, no DuckDB — DuckDB caracteriza el dato, no simula el almacenamiento distribuido.
Los datos que selecciones aquí se procesan en este navegador y no se envían al servidor del curso ni a ninguna API externa.
Inicializando motor local de datos…
Fuente: —
Filas (consulta real): —
Esquema
Clave de partición candidata consulta real ejecutada por DuckDB-Wasm
Consulta ejecutada localmente mediante DuckDB-Wasm — datos reales, no inventados por JavaScript.
Enviar muestra al clúster simulado
La clave de partición determina dónde se ubica un registro, pero no necesariamente identifica de forma única al registro. Muchos registros pueden compartir la misma clave de partición y permanecer como registros independientes.
Por eso cada fila importada se conserva como un registro lógico separado, aunque varias filas compartan el mismo valor de partición (p. ej. varias filas con region = "Norte"). En sistemas reales, qué campo(s) forman la primary key depende de la tecnología (Cassandra, DynamoDB, etc.); aquí solo se ilustra el concepto general.
Hipótesis
Una hipótesis es tu predicción antes de observar los resultados. Regístrala ahora: una vez bloqueada, no podrás cambiarla, solo reformularla después de ver el resultado.
Completa las tres preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear el clúster.
Antes de operar el clúster
Mientras almacenas registros y fallas nodos, observa especialmente:
- Filas reales — cuántas se enviaron al clúster desde el Laboratorio de datos.
- Valores de partición — cuántos valores distintos hay y qué tan repetidos están.
- Distribución entre nodos — si los registros primarios quedan equilibrados o concentrados.
- Factor de replicación — cuántas copias físicas existen por cada registro lógico.
- Nodos fallados — qué ocurre con la disponibilidad cuando fallas uno a propósito.
- Disponibilidad — cómo cambia según el modelo de consistencia elegido.
Antes de fallar un nodo: ¿qué registros crees que quedarán en riesgo, y por qué esos y no otros?
Clúster distribuido
Pulsa "Fallar" en cualquier nodo para comprobar si las réplicas mantienen disponibles los datos. Cada bloque muestra "identificador de registro · valor de partición"; "primaria" es la copia que determina el hash (según el valor de partición), "réplica" son copias adicionales. Registros distintos con el mismo valor de partición aparecen como bloques separados.
Particionado vs. replicación
Particionado: una función hash decide en qué nodo vive originalmente cada dato. Cambia solo si cambia el número de nodos.
Replicación: cuántas copias adicionales de ese mismo dato se guardan en otros nodos para tolerar fallos. Cambia solo si cambia el factor de replicación. No son el mismo concepto ni resuelven el mismo problema.
El modelo de almacenamiento (Semana 2) define cómo representamos los datos; el particionado define cómo los distribuimos físicamente. No son el mismo nivel de decisión.
Métricas
Skew de partición
Registros PRIMARIOS por nodo (solo el efecto del hashing/particionado, sin contar réplicas). Una clave de alta cardinalidad no garantiza automáticamente una distribución perfecta: compáralo con lo que predijiste.
Sin registros aún.
Almacena registros y falla un nodo para ver un resumen basado en tus resultados reales.
Aquí verás la relación entre la clave de partición, el factor de replicación y lo observado.
Aquí verás qué implicaría este resultado para el clúster real de NexoRetail 360.
Registro de eventos
¿Qué recomendarías para producción?
Responde con base en la disponibilidad, el skew y el riesgo observados, no en un valor por defecto.
Cierre conceptual
Lo que descubriste: cómo la clave de partición determina la distribución (skew) y cómo el factor de replicación determina la disponibilidad ante fallos de nodo — dos decisiones independientes.
Concepto para recordar: una clave de alta cardinalidad no garantiza equilibrio por sí sola, y más réplicas no son gratis: cuestan almacenamiento y latencia de coordinación.
Conexión con la próxima semana: en la Semana 4 distribuirás también el procesamiento, no solo el almacenamiento.
Genera tu evidencia
Esta evidencia resume tu caracterización de datos, tu hipótesis, tus mediciones del clúster y tu decisión. Puedes utilizarla para discusión, entrega o reflexión posterior.
Continuidad curricular
Antes: en la Semana 2 elegiste el modelo de almacenamiento y la ruta de ingesta/procesamiento para tu fuente de datos. El modelo de almacenamiento seleccionado define cómo representamos los datos; el particionado define cómo los distribuimos físicamente.
Después: ya distribuimos los datos entre nodos. En la Semana 4 distribuiremos también el procesamiento, no solo el almacenamiento.