MODELOS DE DATOS · ESCALA · GARANTÍAS
La base de datos
no es un logo.
Es el lugar donde convertís reglas del negocio en estructura, acceso y garantías. Elegir bien no empieza comparando productos: empieza escribiendo qué preguntas debe responder el sistema, qué estados jamás puede aceptar y cómo debería fallar.
- 01PREGUNTASqué leemos y escribimos ↓
- 02MODELOcómo se conectan los datos ↓
- 03GARANTÍASqué debe seguir siendo verdad ↓
- 04MOTORqué operación aceptamos
PRODUCTSTORAGE
01 / EMPEZAR POR LAS PREGUNTAS
Diseñá las consultas
antes que las tablas.
El mismo conjunto de entidades admite modelos completamente distintos. La forma correcta depende de cómo entra, cambia y sale la información.
QUERY-FIRST DESIGN
Un workload, no una lista de features.
Antes de elegir tecnología, escribí los caminos críticos como contratos observables. Cada uno debería tener volumen, latencia, consistencia y patrón de fallo esperados.
- 01 · IDENTIDAD
get_order(order_id) - 02 · LISTADO
list_orders(customer_id, created_at DESC) - 03 · ESCRITURA CRÍTICA
reserve_stock(sku, quantity) - 04 · BÚSQUEDA
search_products(text, filters)
El canvas mínimo de decisión
Acceso
Qué se lee, qué se escribe, con qué filtros, orden y cardinalidad.
Invariantes
Qué debe ser único, atómico, ordenado o referencialmente válido.
Carga
Volumen actual y pico, ratio lectura/escritura, crecimiento y tamaño por ítem.
Distribución
Regiones, residencia, partición natural, hot keys y tolerancia a latencia.
Fallos
Qué devuelve el sistema si un nodo, una región o una proyección queda atrasada.
Operación
Backups, restore, migraciones, observabilidad y experiencia real del equipo.
02 / CUATRO MODELOS, NO CUATRO MARCAS
Cada modelo optimiza
una forma de preguntar.
Relacional, documental, clave–valor y grafo no son niveles de madurez. Son representaciones que vuelven naturales algunas operaciones y costosas otras.
Relacional
- BRILLA CUANDO
- Las invariantes y relaciones importan, y las preguntas cambian.
- CONSULTA NATURAL
- JOIN, filtro, agregación y transacción entre entidades.
- PAGA CON
- Esquema y migraciones explícitas; coordinar distribución tiene costo.
Documental
- BRILLA CUANDO
- Los datos se leen juntos y su forma varía por tipo o versión.
- CONSULTA NATURAL
- Obtener un agregado completo por identidad y navegar campos.
- PAGA CON
- Duplicación y updates multi-documento; flexibilidad no elimina el diseño.
Clave–valor
- BRILLA CUANDO
- La clave se conoce y el acceso debe ser predecible a gran escala.
- CONSULTA NATURAL
- GET/PUT por partition key; rangos si existe sort key.
- PAGA CON
- Consultas ad hoc limitadas; una mala clave crea hot partitions.
Grafo
- BRILLA CUANDO
- La profundidad y el patrón de las relaciones son el producto.
- CONSULTA NATURAL
- Vecinos, caminos, comunidades y traversal variable.
- PAGA CON
- Otro lenguaje y operación; no mejora una relación simple por arte de magia.
03 / NORMALIZAR Y DESNORMALIZAR
La forma del dato
también es un trade-off.
Normalizar reduce duplicación y concentra las reglas. Desnormalizar acerca el dato a una lectura concreta. Lo importante es decidir cuál representación es autoridad y cuál es una proyección.
MODELO DE ESCRITURA · NORMALIZADO
Una regla vive en un solo lugar.
Cliente, pedido, producto y línea de pedido tienen identidad propia. Las claves y constraints protegen relaciones: cambiar el email no obliga a reescribir el historial de pedidos.
MODELO DE LECTURA · DESNORMALIZADO
Una pantalla se resuelve de una vez.
{
"order_id": "1042",
"customer": "Ana",
"total": 129.90,
"items": ["keyboard", "mouse"]
}Una proyección puede repetir nombre, total y productos para servir un detalle sin joins. Se reconstruye desde eventos o desde la fuente de verdad y acepta una frescura definida.
REGLA DE OWNERSHIPDuplicar datos puede ser correcto. Duplicar autoridad casi nunca lo es.
04 / ÍNDICES
Acelerá una pregunta,
no “la base”.
Un índice es otra representación que el motor mantiene para encontrar filas sin recorrer toda la tabla. Compra lecturas más rápidas con almacenamiento y trabajo adicional en cada escritura.
Table scan
El costo crece con las filas examinadas.
B-tree lookup
El motor recorre una estructura ordenada hasta el rango útil.
query + selectividad + plan + frecuenciaDiseñá desde WHERE, JOIN y ORDER BY
El orden de columnas en un índice compuesto cambia qué prefijos puede aprovechar el planner.
Contá el costo de escritura
INSERT, UPDATE y DELETE también mantienen índices. Un índice sin uso es deuda activa.
Leé el plan real
EXPLAIN y métricas de producción muestran si el índice reduce trabajo o si un scan es más barato.
05 / ESCALAR SIN ATAJOS
Más nodos cambian
las garantías.
Escalar no es una propiedad binaria. Replicar, particionar y distribuir mueven el límite, pero también introducen lag, coordinación y nuevos estados intermedios.
Escala vertical
Más CPU, RAM o I/O para una instancia.Simple y efectiva hasta el límite físico o económico; no resuelve por sí sola disponibilidad.
Réplicas
Copias para lecturas, failover o cercanía regional.Aumentan capacidad de lectura, pero obligan a definir lag y read-after-write.
Sharding
Cada partición es dueña de un subconjunto de claves.Distribuye storage y escrituras; complica joins, transacciones, rebalanceo y hot keys.
06 / CAP, SIN EL ESLOGAN
No es elegir
dos letras para siempre.
CAP describe qué puede prometer un sistema replicado cuando existe una partición de red. En ese intervalo, una operación no puede ofrecer simultáneamente consistencia linealizable y respuesta exitosa desde ambos lados.
Preservar consistencia
Una parte queda temporalmente no disponible antes que aceptar estados divergentes.
Preservar disponibilidad
Se aceptan versiones concurrentes o datos atrasados y luego hay reconciliación.
La partición es la condición, no una feature que se descarta. Fuera de ella, consistencia y disponibilidad pueden convivir. La elección puede variar por operación, dato y momento.
07 / UN SISTEMA, VARIAS VISTAS
Polyglot persistence,
con una sola verdad.
Usar más de un motor es válido cuando los workloads realmente difieren. El diseño sostenible asigna una responsabilidad a cada storage y hace explícita la propagación.
Autoridad transaccional. Un pedido y su pago respetan invariantes juntos.
Proyección descartable. Puede vencer o perderse sin perder la verdad.
Proyección eventualmente consistente, optimizada para texto y filtros.
08 / MÉTODO DE DECISIÓN
De la pregunta
a una elección defendible.
Una tecnología es una conclusión. Este orden mantiene la conversación conectada con el producto y permite revisar la decisión cuando cambie la carga.
- 01
Escribí los access patterns
Queries, comandos, frecuencia, cardinalidad, orden, filtros y objetivo de latencia.
- 02
Definí invariantes y autoridad
Qué estados son inválidos y qué sistema decide la versión aceptada.
- 03
Estimá carga y crecimiento
Picos, ratio lectura/escritura, bytes por entidad, retención y distribución geográfica.
- 04
Elegí el modelo más simple
El que resuelve el camino crítico sin proyecciones o coordinación prematuras.
- 05
Diseñá índices y partición
Con consultas reales, distribución de claves y planes observados.
- 06
Probá fallos y operación
Restore, lag, nodo caído, partición, migración, hot key y degradación visible al usuario.
DESIGN REVIEW
Preguntas para el design review
- 01¿Cuál es la fuente de verdad?
- 02¿Qué consulta define el modelo?
- 03¿Qué inconsistencia es inaceptable?
- 04¿Qué dato puede estar atrasado y cuánto?
- 05¿Cuál es la clave de partición y puede calentarse?
- 06¿Cómo se restaura y se prueba ese restore?
- 07¿Qué señal demuestra que necesitamos otro motor?
LA DECISIÓN EN UNA LÍNEA
Primero las preguntas.
Después el modelo. Al final, el motor.
El diseño de datos durable no memoriza una tabla comparativa: conecta comportamiento de producto, invariantes, volumen y fallos. Cuando esa cadena está escrita, elegir tecnología deja de ser una discusión de preferencias.
09 / FUENTES Y PRÓXIMOS PASOS
Para seguir
profundizando.
- 01VideoTodo lo que necesitas saber sobre Bases de Datos en 25 minutos
El video que disparó esta nota · BettaTech ↗
- 02PostgreSQLConstraints
Constraints, claves e integridad referencial ↗
- 03PostgreSQLIndexes: Introduction
Índices, planner y costo de escritura ↗
- 04MongoDBData Modeling
Modelar desde access patterns ↗
- 05AWSDynamoDB Data Modeling
Particiones y claves de distribución ↗
- 06Neo4jGraph Data Modeling
Nodos, relaciones y casos de uso ↗
- 07Eric BrewerCAP Twelve Years Later
Por qué “2 de 3” simplifica demasiado ↗