Clave-valor y columnares
Clave-valor
El modelo más simple: una clave opaca apunta a un valor, que puede ser un string, una lista o un hash. No hay consultas por contenido, solo por clave, y de ahí su velocidad. Redis lo explota en memoria con estructuras ricas y caducidad automática.
Caché y sesiones
Su puesto natural es delante de una base lenta: guardar resultados caros, contadores, colas ligeras y sesiones con expiración. La volatilidad se tolera porque lo almacenado es recreable o de vida corta.
Orientación a columnas
Una base columnar almacena juntas las valores de cada columna en vez de las filas completas. Así comprime muy bien datos repetidos y lee solo las columnas que una agregación necesita, ideal para series temporales y telemetría.
Cassandra y escritura
Cassandra reparte datos entre nodos sin único punto de fallo y está afinada para escribir muchísimo y leer por clave de partición. Su modelo consiste en tablas pensadas por y para la consulta, con desnormalización aceptada.
Diseñar por la consulta
- Particionar mal concentra el peso de lectura y escritura en un solo nodo.
- Define primero la pregunta que harás y luego moldea la tabla para responderla barato.
- Acepta duplicar datos si eso elimina uniones costosas a escala.
Consistencia configurable
Estas familias suelen dejar elegir cuántos replicas deben confirmar una escritura. Bajar el requisito gana velocidad y disponibilidad; subirlo gana garantías, en el mismo espíritu del reparto de CAP.
Cuándo no usarlas
Si necesitas transacciones ricas, uniones arbitrarias o consultas ad hoc sobre cualquier combinación de campos, estas familias se quedan cortas. Son especialistas brillantes en su patrón y torpes fuera de él.
Errores frecuentes
- Usar una caché clave-valor como origen de verdad, y perder las sesiones al reiniciar el nodo.
- Particionar una base columnar por una clave de baja cardinalidad que concentra toda la carga.
- Modelar tablas genéricas y luego descubrir que cada lectura exige filtrar campos dispersos.
Ejemplo resuelto: acelerar perfiles y medir telemetría
Una app sufre leyendo perfiles en su base lenta y además registra métricas masivas. La decisión:
- Separar patrones: lecturas de perfil por identificador, y escrituras masivas de métricas con consultas agregadas.
- Delante de los perfiles, poner Redis clave-valor con caducidad corta y datos recreables.
- Para las métricas, elegir un almacén columnar y partir por dispositivo y tramo de tiempo.
- Moldear cada tabla pensando en la agregación que se preguntará, aceptando desnormalizar.
- Calibrar los requerimientos de confirmación de escritura según lo que cueste perder un dato.
¿Para qué sirve en la realidad?
Sesiones y carritos en Redis, telemetría de flotas o sensores en columnares: son las familias que sostienen la escala de las apps modernas justo donde la base relacional generalista se rinde por coste o por latencia.
Necesitas acelerar la lectura de perfiles de usuario que hoy golpean una base relacional lenta, con accesos siempre por identificador y datos recreables. La opción más natural es:
Las bases orientadas a columnas guardan cada fila completa contigua en disco.
Familias
Ordena las decisiones al adoptar una base columnar para telemetría:
Pregunta
Partición
Esquema
Consistencia
Tipos de datos de Redis
Catálogo de estructuras clave-valor: cadenas, hashes, listas, conjuntos y caducidad.
Une cada familia o técnica con su terreno natural.
La familia sigue al patrón
# Clave-valor y columnares ## Clave-valor ### Redis en memoria ### caché y sesiones ## Columnar ### comprime por columna ### telemetría ## Partición ### repartir la carga ### diseñar por la consulta ## Encaje ### especialistas ### transacciones escasas
Documentación de Cassandra
Guía oficial de modelado por consultas, partición y consistencia configurable.
Una app de fitness registra latidos por segundo de miles de usuarios y luego pregunta medias por usuario y tramo. ¿Clave-valor o columnar? Justifica por patrón de escritura y lectura.