Reto de ingeniería
Un nodo del clúster de NexoRetail 360 falló el mes pasado durante una campaña y algunos pedidos quedaron temporalmente inaccesibles. 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?
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.
1 · 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 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.
2 · Hipótesis
Completa las tres preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear el clúster.
4 · 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.
5 · 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.
6 · 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.
7 · Registro de eventos
8 · Decisión de ingeniería
9 · Evidencia de aprendizaje
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.