Explicación de las opciones de implementación
Azure SQL Database, una plataforma como servicio (PaaS), ofrece una alta escalabilidad y un mantenimiento mínimo, lo que lo convierte en una solución excelente para cargas de trabajo específicas. Es adecuada para el nuevo desarrollo de aplicaciones, lo que proporciona a los desarrolladores una flexibilidad significativa para crear nuevos servicios y ofrecer opciones de implementación pormenorizadas a escala. Esta solución de bajo mantenimiento es ideal para varias cargas de trabajo, lo que garantiza un desarrollo de aplicaciones eficaz y eficaz.
Descripción de los modelos de implementación
Al implementar Azure SQL Database, hay dos modelos de implementación principales: base de datos única y grupos elásticos. En el modelo de grupos elásticos, los recursos se comparten entre varias bases de datos del mismo grupo, mientras que en el modelo de base de datos única, los recursos se administran de forma independiente para cada base de datos.
De forma similar a las máquinas virtuales, SQL Database se puede implementar mediante varios métodos, como PowerShell, la CLI de Azure o Azure Portal.
Base de datos única
El modelo de implementación de base de datos única es la manera más sencilla de usar Azure SQL Database. En este modelo, administrará cada base de datos individualmente en términos de escala y tamaño de datos. Cada base de datos tiene sus propios recursos dedicados, incluso si se implementan varias bases de datos en el mismo servidor lógico.
Puede supervisar el uso de recursos de cada base de datos a través de Azure Portal. Esta característica le permite realizar un seguimiento y evaluar fácilmente el rendimiento de las bases de datos.
Grupos elásticos
Los grupos elásticos permiten asignar recursos de almacenamiento y proceso a un grupo de bases de datos, lo que simplifica la administración en comparación con el control individual de cada base de datos. Son más fáciles de escalar que las bases de datos únicas, ya que los cambios en el grupo elástico ajustan automáticamente los recursos de todas las bases de datos incluidas.
Este modelo es rentable para las aplicaciones de software como servicio, ya que los recursos se comparten entre todas las bases de datos. Puede configurar recursos mediante el modelo de compra basado en DTU o basado en núcleo virtual.
Es importante supervisar continuamente los recursos para identificar los picos de rendimiento que podrían afectar a otras bases de datos del grupo. La revisión periódica de la estrategia de asignación garantiza recursos suficientes para todas las bases de datos.
Los grupos elásticos son ideales para arquitecturas multiinquilino con un uso medio y bajo, donde cada inquilino tiene su propia copia de base de datos.
Descripción de los modelos de compra
Una vez que haya elegido el modelo de implementación adecuado para SQL Database, el siguiente paso es seleccionar el modelo de compra que mejor se adapte a los requisitos de carga de trabajo y presupuesto. Azure SQL Database ofrece dos modelos de compra: el modelo de núcleo virtual y el modelo basado en DTU. Cada modelo tiene sus propias ventajas, por lo que es fundamental comprender cuál se alinea mejor con los requisitos de carga de trabajo y las consideraciones de costos.
Basado en núcleos virtuales
Este es el modelo de compra recomendado, donde los recursos de proceso y almacenamiento se desacoplan. Esto significa que puede escalar los recursos de almacenamiento y proceso de forma independiente entre sí. Esta flexibilidad garantiza que puede ajustar los recursos según sus necesidades específicas sin afectar a otros componentes.
En el modelo de compra basado en núcleo virtual, los costos dependen de varios factores, como el nivel de servicio, la configuración de hardware, el número de núcleos virtuales y la cantidad de memoria, el almacenamiento reservado de la base de datos y el almacenamiento de copia de seguridad real.
Nota:
Para obtener información detallada acerca de los precios, consulte la página de precios de Azure SQL Database.
Un nivel de servicio es una configuración predefinida que determina el rendimiento, el tipo de almacenamiento, la alta disponibilidad, las opciones de recuperación ante desastres y la disponibilidad de determinadas características de la base de datos.
El modelo de compra de núcleo virtual ofrece tres opciones de nivel de servicio:
| Nivel de servicio | Capacidad |
|---|---|
| Uso general | Este nivel de servicio está diseñado para operaciones menos intensivas y ofrece un equilibrio rentable de las opciones de proceso y almacenamiento. Incluye los niveles de proceso aprovisionados y sin servidor, lo que proporciona flexibilidad para satisfacer las distintas demandas de carga de trabajo al optimizar el presupuesto. |
| Crítico para la empresa | Este nivel es ideal para las aplicaciones que requieren baja latencia y almacenamiento de alto rendimiento. Admite OLTP en memoria e incluye una réplica integrada de solo lectura. Además, ofrece más memoria por núcleo y usa almacenamiento SSD local, por lo que es ideal para cargas de trabajo sensibles al rendimiento. |
| Hiperescala | Este nivel se adapta a las aplicaciones con bases de datos grandes y requisitos de alto rendimiento. La hiperescala presenta características avanzadas de escalado horizontal, lo que permite agregar nodos de proceso a medida que aumenta el tamaño de los datos. Se admite exclusivamente en bases de datos SQL únicas y permite un escalado significativo de los recursos de almacenamiento y proceso más allá de los límites de los niveles de servicio De uso general y Crítico para la empresa. |
Basado en DTU
En el modelo de DTU, hay tres niveles de servicio: Básico, Estándar y Premium. Los recursos de proceso y almacenamiento dependen del nivel de DTU, ofreciendo una variedad de funcionalidades de rendimiento con límites de almacenamiento fijos, retención de copia de seguridad y costos.
Por ejemplo, si la base de datos alcanza su límite máximo de almacenamiento, tendría que aumentar la capacidad de DTU, incluso si el uso del proceso es bajo. Además, las operaciones de escalado en Azure SQL Database pueden provocar interrupciones breves de conexión al final del proceso. Esto puede ocurrir en dos escenarios principales:
- Al iniciar una operación de escalado que necesita una conmutación por error interna.
- Al agregar bases de datos al grupo elástico, o quitarlas.
Nota:
Para controlar los errores de conexión, implemente la lógica de reintento adecuada en la aplicación.
Comprender la interacción entre los modelos de implementación y compra es fundamental para optimizar el rendimiento y la rentabilidad. Al seleccionar cuidadosamente la combinación correcta, puede asegurarse de que la implementación de Azure SQL Database satisface las demandas de la aplicación mientras se mantiene dentro del presupuesto.
Por ejemplo, si opta por el modelo de implementación de base de datos única, es posible que prefiera el modelo de compra de núcleo virtual por su flexibilidad en el escalado de los recursos de proceso y almacenamiento de forma independiente. Por otro lado, si elige el modelo de implementación del grupo elástico, el modelo de compra basado en DTU podría ser más rentable, ya que permite compartir recursos entre varias bases de datos dentro del grupo.
Realización de copias de seguridad y restauración
Azure proporciona funcionalidades de copia de seguridad y restauración sin problemas para SQL Database. Estas son algunas características clave:
Copia de seguridad continua
Azure SQL Database garantiza copias de seguridad periódicas y las copia continuamente en el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS). Se realizan copias de seguridad completas cada semana, copias de seguridad diferenciales cada 12-24 horas y copias de seguridad del registro de transacciones cada 5-10 minutos.
Restauración geográfica
Con las copias de seguridad con redundancia geográfica de forma predeterminada, puede restaurar fácilmente bases de datos en diferentes regiones, útiles para escenarios de recuperación ante desastres menos estrictos. El almacenamiento de copia de seguridad se factura por separado, pero se crea sin costo adicional con el tamaño máximo del nivel de datos seleccionado. La duración de la restauración geográfica depende del tamaño de la base de datos, los registros de transacciones y las solicitudes de restauración simultáneas.
Nota:
La restauración geográfica está disponible cuando la propiedad de redundancia de almacenamiento de copia de seguridad está establecida en almacenamiento de copia de seguridad con redundancia geográfica.
Restauración a un momento dado (PITR)
Permite configurar una directiva de retención a un momento dado específica para cada base de datos, que va de 1 a 35 días (el valor predeterminado es siete días). También puede restaurar bases de datos a un momento dado específico dentro del mismo servidor mediante Azure Portal, PowerShell, la CLI o la API de REST.
Retención a largo plazo (LTR)
La retención a largo plazo es útil para escenarios en los que es necesario establecer la directiva de retención más allá de lo que ofrece Azure. Puede establecer una directiva de retención durante un máximo de 10 años y esta opción está deshabilitada de forma predeterminada.
Para más información sobre las copias de seguridad automatizadas, vea Copias de seguridad automatizadas: Azure SQL Database y Azure SQL Managed Instance.
Habilitación del ajuste automático
El ajuste automático es una eficaz característica integrada que aplica el aprendizaje automático para optimizar el rendimiento de las consultas. Identifica automáticamente las oportunidades de optimización y las implementa para mejorar la eficacia de la base de datos.
Actualmente, el ajuste automático incluye las siguientes características:
- Identificación de consultas que consumen muchos recursos
- Forzar el último plan de ejecución bueno
- Adición de índices
- Eliminación de índices
Los servicios de Azure usan algoritmos avanzados para determinar los mejores índices de los patrones de consulta. Estos índices se prueban inicialmente en una copia de la base de datos antes de aplicarse al entorno activo, lo que garantiza una interrupción mínima.
Todas las bases de datos heredan su configuración del servidor primario y puede deshabilitar fácilmente esta característica si es necesario. Esta flexibilidad permite a los desarrolladores mantener el control al tiempo que se benefician de mejoras de rendimiento automatizadas.
Uso de consultas elásticas
La consulta elástica permite ejecutar consultas T-SQL en varias bases de datos de SQL Database. Esta característica es útil para las aplicaciones que usan nombres de tres y cuatro partes que no se pueden cambiar y mejora la portabilidad al facilitar la migración.
Las consultas elásticas admiten los siguientes escenarios de creación de particiones:
| Nivel de servicio | Capacidad |
|---|---|
| Particiones verticales | También conocido como consultas entre bases de datos. Los datos se particionan verticalmente entre varias bases de datos con esquemas diferentes. Por ejemplo, puede tener una base de datos para los datos del cliente y otra para obtener información de pago. La creación de particiones verticales permite ejecutar consultas entre bases de datos entre estas bases de datos. |
| Creación de partición horizontal | También conocido como particionamiento. Los datos se particionan horizontalmente para distribuir filas entre varias bases de datos escaladas horizontalmente y comparten el mismo esquema. Esta topología admite modelos de inquilino único y multiinquilino. |
Esta flexibilidad hace que las consultas elásticas sea una herramienta eficaz para administrar y consultar datos en varias bases de datos.
Configuración de trabajos elásticos
La característica de trabajo elástico sirve como reemplazo del Agente SQL Server para Azure SQL Database, similar a la característica Administración multiservidor en una instancia local de SQL Server.
Con los trabajos elásticos, puede ejecutar comandos de T-SQL en varias implementaciones de destino, incluidas bases de datos SQL, grupos elásticos de SQL Database y bases de datos SQL en mapas de particiones. Estos recursos de base de datos pueden abarcar diferentes suscripciones y regiones de Azure. La funcionalidad de ejecución en paralelo es útil para automatizar las tareas de mantenimiento de bases de datos, lo que garantiza la eficacia y la coherencia en las implementaciones.
Movimiento de datos mediante SQL Data Sync
SQL Data Sync permite la sincronización incremental de datos entre varias bases de datos, tanto si se ejecutan en SQL Database como en SQL Server local. Esta característica es útil para descargar cargas de trabajo de producción intensivas en una base de datos independiente para realizar análisis o operaciones no planeadas.
Data Sync funciona en una topología de concentrador, donde una base de datos del grupo de sincronización se designa como concentrador. El grupo de sincronización puede incluir varias bases de datos miembro y la sincronización se produce entre las bases de datos del centro y de miembros individuales. Se realiza un seguimiento de los cambios mediante desencadenadores de inserción, actualización y eliminación por medio de una tabla histórica creada en la base de datos de usuario.
Al crear un grupo de sincronización, debe especificar una base de datos para almacenar los metadatos del grupo de sincronización. Esta base de datos de metadatos puede ser nueva o existente, siempre y cuando resida en la misma región que el grupo de sincronización.
Para más información sobre cómo configurar SQL Data Sync, vea Tutorial: Configuración de SQL Data Sync entre bases de datos de Azure SQL Database y SQL Server.