¿Qué es Azure Managed Redis (versión preliminar)?
Azure Managed Redis (versión preliminar) proporciona un almacén de datos en memoria basado en el software Redis Enterprise. Redis Enterprise mejora el rendimiento y la fiabilidad de la edición comunitaria de Redis, al tiempo que mantiene la compatibilidad. Microsoft opera el servicio, que se hospeda en Azure, y todas las aplicaciones, tanto si están dentro como fuera de Azure, pueden usarlo. Para obtener más información sobre cómo se ha creado Azure Managed Redis, consulte Arquitectura de Azure Managed Redis.
Importante
Azure Managed Redis se encuentra actualmente en VERSIÓN PRELIMINAR. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Azure Managed Redis puede mejorar el rendimiento y la escalabilidad de una aplicación que utilice en gran medida almacenes de datos backend. Es capaz de procesar grandes volúmenes de solicitudes de aplicación al mantener los datos a los que se accede con frecuencia en la memoria del servidor, donde se pueden realizar operaciones rápidas de lectura y escritura.
Redis incorpora una solución crítica de almacenamiento de datos de baja latencia y alto rendimiento en las aplicaciones modernas. Además, Redis se utiliza cada vez más para aplicaciones distintas del almacenamiento en caché, como la ingesta de datos, la desduplicación, la mensajería, las tablas de clasificación, el almacenamiento en caché semántico y como base de datos vectorial.
Azure Managed Redis se puede implementar de forma independiente o junto con otros servicios de base de datos o aplicaciones de Azure, como Azure Container Apps, Azure App Service, Azure Functions, Azure SQL o Azure Cosmos DB.
Escenarios principales
Azure Managed Redis mejora el rendimiento de las aplicaciones al admitir patrones de arquitectura de aplicaciones comunes. Estos son algunos de los más comunes:
| Patrón | Descripción |
|---|---|
| Caché de datos | Las bases de datos suelen ser demasiado grandes para cargarlas directamente en una caché. Es habitual usar el patrón cache-aside para cargar datos en la caché solo cuando es necesario. Cuando el sistema realiza cambios en los datos, también puede actualizar la caché, que se distribuye luego a otros clientes. Además, el sistema puede establecer una fecha de expiración en los datos o usar una directiva de expulsión para desencadenar las actualizaciones de los datos en la memoria caché. |
| Caché de contenido | Muchas páginas web se generan a partir de plantillas que usan contenido estático como encabezados, pies de página y banners. Estos elementos estáticos no deberían cambiar a menudo. El uso de una caché en memoria proporciona acceso rápido a contenido estático en comparación con los almacenes de datos de back-end. Este patrón reduce el tiempo de procesamiento y la carga del servidor, lo que permite que los servidores web tengan mayor capacidad de respuesta. Puede permitirle reducir el número de servidores necesarios para administrar las cargas. Azure Managed Redis proporciona Redis Output Cache Provider para soportar este patrón con ASP.NET. |
| Almacén de sesión | Este patrón se utiliza normalmente con carros de la compra y otros datos del historial de los usuarios que una aplicación web podría asociar con las cookies del usuario. El almacenamiento de demasiados datos en una cookie puede tener un efecto negativo en el rendimiento, ya que aumenta su tamaño y no hay que olvidar que se pasa y se valida con cada solicitud. Una solución habitual usa la cookie como clave cuando se consultan datos en una base de datos. Cuando se utiliza una caché en memoria, como Azure Managed Redis, asociar información a un usuario es más rápido que interactuar con una base de datos relacional completa. |
| Búsqueda de similitud de vectores | Un caso de uso común de la IA es generar incrustaciones vectoriales utilizando un gran modelo de lenguaje (LLM). Estas incrustaciones vectoriales deben almacenarse en una base de datos vectorial y luego compararse para determinar la similitud. Azure Managed Redis cuenta con funciones integradas para almacenar y comparar incrustaciones vectoriales en un alto rendimiento. |
| Almacenamiento en caché semántico | El uso de LLM suele introducir un alto grado de latencia (debido al tiempo de generación) y coste (debido al precio por token) en una aplicación. El almacenamiento en caché puede ayudar a resolver estos problemas almacenando los resultados anteriores de un LLM para poder recuperarlos rápidamente. Sin embargo, dado que los LLM utilizan un lenguaje natural, puede resultar difícil de manejar para las cachés típicas. Las cachés semánticas como Azure Managed Redis son capaces de almacenar en caché no solo una consulta específica, sino el significado semántico de una consulta, lo que permite utilizarla de forma mucho más natural con los LLM. |
| Desduplicación | A menudo, es necesario determinar si una acción ya se ha producido en un sistema, como determinar si se ha tomado un nombre de usuario o si ya se ha enviado un correo electrónico a un cliente. En Azure Managed Redis, se pueden utilizar filtros de proliferación para determinar rápidamente los duplicados y evitar problemas. |
| Tablas de clasificación | Redis ofrece un soporte sencillo y potente para desarrollar tablas de clasificación de todo tipo utilizando la estructura de datos de conjuntos ordenados. Además, el uso de la replicación geográfica activa puede permitir que una tabla de clasificación se comparta en todo el mundo. |
| Almacenamiento en cola de trabajos y mensajes | Las aplicaciones agregan a menudo tareas a una cola cuando las operaciones asociadas a la solicitud tardan tiempo en ejecutarse. Las operaciones con ejecuciones más largas se ponen en cola para procesarse en secuencia, a menudo por parte de otro servidor. Este método de aplazar trabajo se denomina puesta en cola de tareas. Azure Managed Redis proporciona una cola distribuida para habilitar este patrón en su aplicación. |
| Aceleración de PowerBI/Analytics | Puede usar el controlador ODBC de Redis para usar Redis para BI, informes y casos de uso de análisis. Dado que Redis suele ser mucho más rápido que las bases de datos relacionales, el uso de Redis de esta manera puede aumentar drásticamente la capacidad de respuesta de las consultas. |
| Distributed transactions | A veces, las aplicaciones requieren una serie de comandos en un almacén de datos de back-end para ejecutarse como una única operación atómica. El resultado de todos los comandos debe ser satisfactorio, o todos deben revertirse al estado inicial. Azure Managed Redis admite la ejecución de un lote de comandos como una única transacción. |
Versión de Redis
Azure Managed Redis es compatible con la versión 7.4.x de Redis. Para obtener más información, consulte Cómo actualizar la versión de su instancia de Azure Managed Redis.
Elección del nivel correcto
Hay cuatro niveles de Azure Managed Redis disponibles, cada uno con diferentes características de rendimiento y niveles de precio.
Tres niveles son para los datos en memoria:
- Optimizado para memoria Ideal para casos de uso intensivo de memoria que requieren una relación elevada de memoria a vCPU (8:1), pero no necesita el rendimiento más alto. Proporciona un punto de precio más bajo para escenarios en los que se necesita menos potencia de procesamiento o rendimiento, lo que lo convierte en una excelente opción para entornos de desarrollo y pruebas.
- Equilibrado (memoria y proceso) Ofrece una relación equilibrada de memoria a vCPU (4:1), lo que lo convierte en ideal para cargas de trabajo estándar. Este nivel proporciona un equilibrio correcto de la memoria y los recursos de proceso.
- Optimizado para proceso Diseñado para cargas de trabajo con un uso intensivo del rendimiento que requieren un rendimiento máximo, con una relación baja de memoria a vCPU (2:1). Es ideal para las aplicaciones que exigen el máximo rendimiento.
Un nivel almacena datos tanto en memoria como en disco:
- Optimizado para Flash Permite que los clústeres de Redis muevan automáticamente los datos a los que se accede con menos frecuencia desde la memoria (RAM) al almacenamiento NVMe. Esto reduce el rendimiento, pero permite el escalado rentable de cachés con grandes conjuntos de datos.
Nota:
Para obtener más información sobre cómo se diseña el nivel Optimizado para Flash, consulte Arquitectura de Azure Managed Redis
Importante
También puede usar la característica de persistencia de datos para almacenar datos en disco para los niveles en memoria. La persistencia de datos almacena una copia de seguridad de los datos en el disco para recuperarlos rápidamente en caso de interrupción inesperada. Esto es diferente del nivel optimizado para Flash, que está diseñado para almacenar datos en disco para operaciones típicas. El almacenamiento de algunos datos en disco mediante el nivel optimizado para Flash no aumenta la resistencia de los datos. También puede utilizar la persistencia de datos en el nivel optimizado para Flash.
Para obtener instrucciones sobre cómo escalar entre niveles y SKU, consulte Escalado de una instancia de Azure Managed Redis.
Niveles y SKU de un vistazo
Para obtener más información sobre precios, consulte los Precios de Azure Managed Redis
Comparación de características
La tabla siguiente le ayuda a describir algunas de las características que admite cada nivel:
| Descripción de la característica | Memoria optimizada | Equilibrada | Optimizada para proceso | Optimizado para Flash |
|---|---|---|---|---|
| Tamaño (GB) | 12 - 1920 | 0.5 - 960 | 3 - 720 | 250 - 4500 |
| Acuerdo de Nivel de Servicio (SLA) | Sí | Sí | Sí | Sí |
| Cifrado de datos en tránsito | Si (punto de conexión privado) | Si (punto de conexión privado) | Si (punto de conexión privado) | Si (punto de conexión privado) |
| Replicación y conmutación por error | Sí | Sí | Sí | Sí |
| Aislamiento de red | Sí | Sí | Sí | Sí |
| Autenticación basada en Microsoft Entra ID | Sí | Sí | Sí | Sí |
| Escalado | Sí | Sí | Sí | Sí |
| Persistencia de los datos | Sí | Sí | Sí | Sí |
| Redundancia de zona | Sí | Sí | Sí | Sí |
| Replicación geográfica | Sí (activo) | Sí (activo) | Sí (activo) | No |
| Registros de auditoría de conexión | Sí (basado en eventos) | Sí (basado en eventos) | Sí (basado en eventos) | Sí (basado en eventos) |
| Estructuras de datos JSON (es decir, Redis JSON) | Sí | Sí | Sí | Sí |
| Funciones de búsqueda (incluido el vector de búsqueda) | Sí | Sí | Sí | No |
| Estructuras de datos probabilísticas (es decir, Redis Bloom) | Sí | Sí | Sí | Sí |
| Capacidad de base de datos de series temporales (es decir, Redis TimeSeries) | Sí | Sí | Sí | Sí |
| Redis en Flash (también conocido como autotiering) | Sí | Sí | Sí | Sí |
| Import/Export | Sí | Sí | Sí | Sí |
| Actualización del canal y Programación de actualizaciones | No | N.º | N.º | No |
Importante
Las opciones de SKU B0 y B1 equilibradas no admiten la replicación geográfica activa.
Importante
SLA solo está disponible en GA, y no está disponible en la versión preliminar.
Nota:
La reducción en escala de ayuda es limitada en algunas situaciones. Para obtener más información, consulte Requisitos previos/limitaciones del escalado de Azure Managed Redis.
Otras consideraciones a la hora de elegir un nivel
- Rendimiento de la red: si tiene una carga de trabajo que requiere un alto rendimiento, es posible que el ancho de banda de la red le suponga un cuello de botella. Puede aumentar el ancho de banda pasando a un nivel de rendimiento superior o a una instancia de gran tamaño. Las instancias de mayor tamaño tienen más ancho de banda debido a la máquina virtual subyacente que aloja la caché. Los límites de ancho de banda más altos ayudan a evitar la saturación de la red que provocan tiempos de espera en la aplicación. Para obtener más información sobre el rendimiento del ancho de banda, consulte Pruebas de rendimiento
- Número máximo de conexiones de clientes: cada SKU tiene un número máximo de conexiones de cliente. Este límite aumenta con los niveles de rendimiento más altos y los tamaños de instancias más grandes. Para obtener más información sobre el límite de cada SKU, consulte Precios de Azure Managed Redis.
- Alta disponibilidad: Azure Managed Redis ofrece múltiples opciones de alta disponibilidad. El Acuerdo de Nivel de Servicio solo cubre la conectividad para los puntos de conexión de la memoria caché. El Acuerdo de Nivel de Servicio no cubre la protección frente a la pérdida de datos. Para más información sobre el SLA, consulte el SLA. Es posible deshabilitar la alta disponibilidad en una instancia de Azure Managed Redis. Esto abarata el coste, pero provoca pérdidas de datos y tiempos de inactividad. Solo recomendamos deshabilitar la alta disponibilidad para escenarios de desarrollo o prueba.
Otras consideraciones sobre precios
Importante
Azure Managed Redis Enterprise requiere una dirección IP para cada instancia de caché. Actualmente, el cargo por dirección IP es absorbido por Azure Managed Redis y no se repercute a los clientes. En el futuro, esto puede cambiar. Para obtener más información, consulte Precios de las direcciones IP.
Importante
El uso de la replicación geográfica activa producirá la transferencia de datos entre regiones Azure. Actualmente, Azure Managed Redis absorbe estos cargos por ancho de banda y no los repercute a los clientes. En el futuro, esto puede cambiar. Para obtener más información, consulte Precios del ancho de banda.
Disponibilidad por región
Azure Managed Redis se expande continuamente a nuevas regiones. Para ver la disponibilidad en su región consulte Productos disponibles por región.
Migraciones de Azure Cache for Redis
Para obtener más información sobre la migración de Azure Cache for Redis a Azure Managed Redis, consulte Migración de Azure Cache for Redis a Azure Managed Redis