La optimización de la asignación de recursos de proceso para lograr los objetivos de rendimiento y controlar al mismo tiempo los costos puede ser un equilibrio difícil de conseguir, especialmente para las cargas de trabajo de bases de datos con patrones de uso complejos. Para ayudar a abordar estos retos, nos complace anunciar la vista previa de Azure SQL Database sin servidor. SQL Database sin servidor (versión preliminar) es un nuevo nivel de proceso que optimiza la relación precio-rendimiento y simplifica la administración del rendimiento para las bases de datos con un uso intermitente e impredecible. Las aplicaciones de línea de negocio, las bases de datos de desarrollo/pruebas, la administración de contenido y los sistemas de comercio electrónico son solo algunos ejemplos en una gama de aplicaciones que a menudo se ajustan al patrón de uso ideal para SQL Database sin servidor. SQL Database sin servidor también es un nivel adecuado para nuevas aplicaciones con incertidumbre en el tamaño de los procesos o cargas de trabajo que requieren un reescalado frecuente para reducir costos. El nivel de proceso sin servidor disfruta de todas las ventajas de la inteligencia incorporadas y totalmente administradas de SQL Database y ayuda a acelerar el desarrollo de aplicaciones, minimizar la complejidad operativa y reducir los costos totales.

Escalado automático de procesos

SQL Database sin servidor escala automáticamente el proceso para bases de datos únicas en función de la demanda de la carga de trabajo y el proceso utilizado se factura por segundo. El nivel sin servidor contrasta con el nivel de proceso aprovisionado en SQL Database, que asigna una cantidad fija de recursos de proceso por un precio fijo y se factura por hora. En escalas de tiempo cortas, las bases de datos de proceso aprovisionadas tienen dos opciones: aprovisionar recursos en exceso, con el consiguiente costo, para hacer frente al uso máximo o aprovisionar de forma insuficiente y arriesgarse a un bajo rendimiento. En escalas de tiempo más largas, las bases de datos de proceso aprovisionadas se pueden volver a escalar, pero esta solución puede requerir la predicción de patrones de uso o escribir una lógica personalizada para activar las operaciones de reescalado en función de una programación o métricas de rendimiento. Esto se suma a la complejidad del desarrollo y operativa. En el nivel sin servidor, el servicio administra el escalado de proceso dentro de los límites configurables para dimensionar de forma correcta y continua los recursos. El nivel sin servidor da también la opción de pausar automáticamente la base de datos durante los períodos que no se utiliza y reanudarla cuando se recupera la actividad.

Pago solo por el proceso utilizado

En SQL Database sin servidor, el proceso solo se factura en función de la cantidad de CPU y memoria usada por segundo.  Mientras la base de datos está en pausa, solo se factura el almacenamiento, lo que proporciona una ventaja adicional de optimización de precios.

Por ejemplo, piense en una aplicación de línea de negocio o una base de datos de desarrollo/pruebas que está inactiva por la noche, pero que necesita una gran capacidad de uso máximo de varios núcleos durante todo el día. Suponga que la aplicación está utilizando una base de datos sin servidor configurada para permitir la pausa y el escalado automáticos de hasta cuatro núcleos virtuales y tiene el siguiente patrón de uso durante un período de veinticuatro horas:

Como se puede ver, el uso de la base de datos corresponde a la cantidad de proceso facturada, que se mide en unidades de segundos de núcleo virtual y suma alrededor de 46 000 segundos de núcleo virtual durante el período de veinticuatro horas. Suponga que el precio de la unidad de proceso para la base de datos sin servidor es de alrededor de 0,000073 USD/núcleo virtual/segundo. Por tanto, la factura de proceso para este período de un día es de menos de 3,40 USD. Esto se calcula multiplicando el precio de la unidad de proceso por el número total de segundos de núcleo virtual acumulados. Durante este período de tiempo, la base de datos se pausó automáticamente mientras estaba inactiva y disfrutó de la ventaja de episodios de uso máximo de hasta el 80 por ciento de cuatro núcleos virtuales sin intervención del cliente. En este ejemplo, el ahorro de precios al usar el nivel sin servidor es considerable en comparación con una base de datos de proceso aprovisionada configurada con el mismo límite de cuatro núcleos virtuales.  

Tenga en cuenta que los precios tienen descuento para la versión preliminar. En este ejemplo, los precios se basan en la región Este de EE. UU. en mayo de 2019 y están sujetos a cambios. Para conocer los precios más actualizados, visite la página de precios de Azure SQL Database.

Ventajas y desventajas de la relación precio-rendimiento

Cuando se utiliza el nivel SQL Database sin servidor, hay que tener en cuenta las ventajas y desventajas de la relación precio-rendimiento. Estas ventajas y desventajas están relacionadas con el precio de la unidad de proceso y el impacto en el rendimiento de la aplicación debido al calentamiento de proceso después de períodos de poco uso o de inactividad.

Precio de la unidad de proceso

El precio de la unidad de proceso es más alto para una base de datos sin servidor que para una base de datos de proceso aprovisionada, ya que el nivel sin servidor está optimizado para cargas de trabajo con patrones de uso intermitente. Si el uso de la CPU o memoria es lo bastante alto y sostenido durante el tiempo suficiente, el nivel de proceso aprovisionado puede ser menos costoso.

Calentamiento de proceso después de un uso bajo

Mientras una base de datos sin servidor está en línea, la memoria se recupera gradualmente si el uso de la CPU o la memoria es lo bastante bajo durante el tiempo suficiente. Cuando vuelve la actividad de la carga de trabajo, es posible que se requiera la E/S del disco para rehidratar las páginas de datos en el grupo de búferes de SQL o es posible que sea necesario volver a compilar los planes de consulta. Esta directiva de administración de memoria para reclamar la memoria caché basada en un bajo uso es única de SQL Database sin servidor y se hace para controlar los costos del cliente, pero puede afectar al rendimiento. La recuperación de memoria basada en un uso bajo no se produce en el nivel de proceso aprovisionado para bases de datos únicas o grupos elásticos donde se puede evitar este tipo de impacto.

Calentamiento de proceso después de una pausa

La latencia para pausar y reanudar una base de datos sin servidor suele ser de aproximadamente un minuto como máximo, tiempo durante el cual la base de datos está sin conexión. Una vez reanudada la base de datos, las memorias caché deben rehidratarse, lo que agrega latencia adicional antes de que se recuperen las condiciones de rendimiento óptimo. El período de inactividad que debe transcurrir antes de que ocurra la pausa automática se puede configurar para compensar este impacto en el rendimiento. Alternativamente, la pausa automática puede deshabilitarse para cargas de trabajo sensibles a este impacto y seguir beneficiándose del escalado automático. Independientemente del uso, se facturan los mínimos de proceso mientras la base de datos está en línea, por lo que deshabilitar la pausa automática puede aumentar los costos.

Más información

Azure SQL Database sin servidor es compatible con el nivel De uso general para bases de datos individuales.

• Obtenga más información sobre Azure SQL Database sin servidor (versión preliminar).
• Obtenga más información sobre los precios de Azure SQL Database para el nivel de proceso sin servidor (versión preliminar).