Construcción de base de datos en memoria durable con Amazon MemoryDB for Redis - Integración de caché y almacén de datos primario
Se explica la operación de base de datos en memoria compatible con Redis con MemoryDB, el mecanismo de durabilidad y la diferenciación con ElastiCache.
Descripcion general de MemoryDB
MemoryDB for Redis es un servicio de base de datos en memoria con durabilidad compatible con Redis 7.x, capaz de almacenar hasta 500 nodos y cientos de TB de datos. Mientras ElastiCache for Redis se especializa en cache (datos volatiles), MemoryDB garantiza la durabilidad de las escrituras con log de transacciones Multi-AZ y se puede usar como almacen de datos primario. La latencia de lectura es del orden de microsegundos y la de escritura de milisegundos de un solo digito. En modo cluster, escala hasta 500 shards, cada uno con un primario y hasta 5 replicas.
Mecanismo de durabilidad
MemoryDB registra sincronicamente las escrituras en un log de transacciones Multi-AZ, sin perder datos en caso de fallo de nodo. Las operaciones de escritura devuelven ACK al cliente solo despues de completar la persistencia en el log de transacciones, garantizando consistencia fuerte (strong consistency). En el reinicio de nodo, los datos se restauran completamente desde el log de transacciones, resultando en cero perdida de datos comparado con la recuperacion basada en snapshots. La replicacion a nodos replica es asincrona, por lo que las lecturas desde replicas son eventualmente consistentes. Ademas de los snapshots automaticos diarios (retenidos hasta 35 dias), se pueden tomar snapshots manuales como base para recuperacion point-in-time.
Casos de uso y diferenciacion con ElastiCache
MemoryDB es adecuado para almacenes de sesion, perfiles de usuario, tablas de clasificacion y analisis en tiempo real donde se necesita velocidad en memoria sin perder datos. Soporta todas las estructuras de datos de Redis (Sorted Set, Hash, Stream) y se posiciona como capa de datos complementaria a DynamoDB o RDS. ElastiCache es la opcion cuando la perdida de datos es aceptable, como cache frontal de RDS o DynamoDB. ElastiCache utiliza replicacion asincrona, por lo que puede perder escrituras recientes durante failover. Criterio de seleccion: si los datos pueden re-obtenerse de la fuente (como RDS), elija ElastiCache; si los datos en Redis son la unica fuente de verdad, elija MemoryDB. Usar MemoryDB como cache es sobredimensionamiento y mas costoso, debe evitarse. Para profundizar en diseno de bases de datos, libros especializados en Amazon pueden ser un recurso valioso.
Estructuras de datos Redis y procesamiento del lado del servidor
MemoryDB soporta completamente el conjunto de comandos de Redis 7.x, incluyendo Strings, Hashes, Lists, Sets, Sorted Sets, Streams, HyperLogLog e indices Geospatial. Los Sorted Sets son efectivos para implementar tablas de clasificacion y timelines con recuperacion de ranking en O(log N). Los Streams sirven como logs de eventos o colas de mensajes con soporte de consumer groups para procesamiento paralelo. Los scripts Lua permiten procesamiento atomico del lado del servidor, Redis Functions permite registrar logica reutilizable, Pub/Sub proporciona notificaciones en tiempo real y las transacciones (MULTI/EXEC) soportan operaciones atomicas. ACL v2 permite control de acceso granular por usuario y por comando, con capacidad de separar permisos de lectura y escritura por patron de clave. En modo cluster, los datos se distribuyen basandose en hash slots siguiendo el protocolo Redis Cluster, y los clientes se conectan automaticamente al shard correcto via redirecciones MOVED. Claves grandes (varios MB o mas) concentradas en un solo shard pueden causar hot spots, por lo que la uniformidad en el tamano de claves es una consideracion importante en el diseno del modelo de datos.
Mejores practicas de diseno y consideraciones
Con MemoryDB es critico que el tamano de datos se ajuste a la memoria del nodo. Una utilizacion de memoria alta causa swap o eviccion que degrada el rendimiento, por lo que se recomienda planificar la capacidad para mantener la utilizacion por debajo del 75%. Los cambios en el numero de shards (resharding) se ejecutan en linea, pero la latencia de escritura aumenta temporalmente durante la redistribucion de datos. Se soporta cifrado en reposo (KMS) y en transito (TLS), y las ACLs proporcionan control de autorizacion a nivel de comando Redis. La arquitectura basica coloca MemoryDB en una VPC con security groups que restringen las conexiones de origen. Multi-AZ esta habilitado por defecto, proporcionando alta disponibilidad sin configuracion adicional.
Precios y consideraciones de limites
El precio del nodo MemoryDB db.r7g.large es de aproximadamente 0,463 USD por hora (aproximadamente 333 USD/mes). Es aproximadamente un 20% mas caro que el nodo equivalente de ElastiCache, pero incluye el almacenamiento del log de transacciones para durabilidad. La transferencia de datos dentro de la region es gratuita, y entre regiones se aplican las tarifas estandar. El almacenamiento de snapshots mas alla de la capa gratuita (equivalente al tamano de memoria del nodo) cuesta aproximadamente 0,085 USD por GB al mes. Los nodos reservados (1 ano/3 anos) pueden reducir costos hasta aproximadamente un 55%. Limites clave: maximo 500 shards por cluster, 5 replicas por shard, y comportamiento de eviccion configurable mediante la configuracion maxmemory-policy del parameter group.
Resumen
MemoryDB es una base de datos en memoria compatible con Redis que garantiza durabilidad. Logra la persistencia de escrituras con log de transacciones Multi-AZ y, mientras ElastiCache es para uso de cache, se puede usar como base de datos primaria. Con latencia de lectura de microsegundos, es ideal como capa de datos para almacenes de sesion, tablas de clasificacion y analisis en tiempo real. El principio clave de diseno es una separacion clara: ElastiCache para cache, MemoryDB cuando los datos almacenados son la unica fuente de verdad.