Planear implementaciones de Azure Database for PostgreSQL para el rendimiento operativo

La informática en la nube ha rediseñado considerablemente el entorno de hospedaje de la base de datos. Proporciona a los equipos acceso a la escalabilidad, resistencia, alcance global y funcionalidades que anteriormente no eran accesibles. En lugar de incurrir en costos y sobrecargas considerables mediante la planeación de la mayor carga de trabajo posible (y llevar ese costo desde el primer día), los equipos ahora pueden optimizar en torno a la escala precisa que necesitan, cuando lo necesiten y ajustar a medida que cambien sus demandas.

Introducción

La flexibilidad para elegir el equilibrio adecuado de recursos es especialmente útil para las implementaciones de bases de datos de PostgreSQL. Las cargas de trabajo de base de datos PostgreSQL pueden empezar siendo pequeñas, crecer rápidamente, aumentar de forma estacional, cambiar de intensiva en lectura a intensiva en escritura o evolucionar desde cargas de trabajo transaccionales a sistemas híbridos operativos y analíticos en tiempo real. Azure Database for PostgreSQL garantiza que las soluciones alcancen sus objetivos al ofrecer una amplia gama de opciones en proceso, almacenamiento, disponibilidad, replicación, seguridad, copia de seguridad y administración operativa.

Pero con todo este poder viene una gran responsabilidad, especialmente al planificar tus implementaciones. Para lograr el mejor rendimiento posible, las decisiones de implementación deben coincidir con los requisitos generales de la carga de trabajo.

Una implementación de Azure Database for PostgreSQL correcta no es solo una cuestión de elegir "la mayoría de los núcleos y la memoria que necesitamos". En su lugar, el rendimiento operativo máximo proviene de comprender los comportamientos de la aplicación, los comportamientos del cliente, el proceso, el almacenamiento y las características de crecimiento de la base de datos, y cómo se intersecan e interactúan.

La mejor arquitectura es aquella en la que estas piezas se alinean intencionadamente.

El planeamiento del rendimiento en la nube es una responsabilidad compartida

Una de las principales ventajas de pasar a una plataforma en la nube de confianza es el modelo de responsabilidad compartida. Microsoft proporciona la infraestructura global, los servicios administrados, la innovación de hardware, la confiabilidad, la seguridad y la ingeniería operativa. Los equipos aportan la experiencia específica del contexto de la aplicación: importancia empresarial, comportamiento de la carga de trabajo, diseño del modelo de datos, perfil de tráfico de red, expectativas de crecimiento, objetivos de recuperación y requisitos de experiencia del usuario final.

Los resultados más fuertes surgen cuando estas dos fuerzas están unificadas.

Azure proporciona una infraestructura de Postgres altamente escalable, pero el equipo debe aportar información a estas áreas:

• ¿Cuántos usuarios simultáneos se esperan durante períodos normales y picos?
• ¿Las operaciones más importantes son de lectura intensiva, de escritura intensiva o mixtas?
• ¿Se produce un pico de demanda durante las ventanas de fin de mes, trimestre, días festivos, lanzamientos o informes?
• ¿Con qué rapidez crece el conjunto de datos?
• ¿Qué operaciones son sensibles a la latencia?
• ¿Qué consultas o trabajos pueden tolerar tiempos de ejecución más largos?
• ¿La carga de trabajo es principalmente OLTP, OLAP o híbrida?
• ¿Los clientes se encuentran cerca de la región de la base de datos, distribuida globalmente o se concentran en una geografía?

Capture estos detalles antes de la implementación, no después de un incidente de producción. Las implementaciones en la nube facilitan el escalado, pero los diseños de mayor rendimiento y más rentables siguen empezando por la recopilación de requisitos sólidos y la planificación adecuada. En la mayoría de los casos, estas preguntas se pueden destilar a las relaciones entre las conexiones simultáneas, el número máximo de IOPS y el rendimiento necesario.

El rendimiento tiene varias capas

El rendimiento de la base de datos rara vez viene determinado por una única configuración. Las experiencias de implementación correctas dependen de varias capas que funcionan conjuntamente:

• Rendimiento de la capa de aplicación.
  Esta capa incluye código de aplicación, patrones de consulta, cobertura de índices, uso de desencadenadores, creación de particiones de datos, control de conexiones, almacenamiento en caché, lógica de reintento, agrupación, comportamiento de ORM, diseño de transacciones y comportamiento de trabajo en segundo plano.
• Rendimiento del cliente y de la capa de red.
  Esta capa incluye dónde se encuentran los clientes, cómo se conectan, si las solicitudes cruzan regiones y zonas de disponibilidad, latencia de red, sobrecarga TLS, rotación de conexiones y si la aplicación usa el pool de conexiones de forma eficaz.
• Rendimiento de la plataforma de base de datos.
  Esta capa incluye configuración de implementación de Postgres, tamaño de proceso, memoria, CPU, tipo de almacenamiento, tamaño de almacenamiento, IOPS de almacenamiento, rendimiento de almacenamiento, alta disponibilidad, réplicas y operaciones de mantenimiento.

Este artículo se centra principalmente en la tercera capa: planear la implementación de base de datos de Postgres Azure para que las opciones de proceso y almacenamiento admitan el perfil de rendimiento necesario.

Azure Database for PostgreSQL ofrece flexibilidad, pero la planificación es esencial

Azure Database for PostgreSQL servidor flexible proporciona una amplia gama de opciones de implementación, entre las que se incluyen:

Esta flexibilidad es eficaz porque las diferentes cargas de trabajo requieren diferentes funcionalidades. Un sistema transaccional con mucha escritura no necesita el mismo perfil que un sistema de informes pesado. Una aplicación SaaS global no necesita el mismo diseño que una aplicación regional interna. Una base de datos que crece un 5% por año no necesita el mismo plan de almacenamiento que otra que crece un 200% cada mes.

El objetivo de planeación es identificar las necesidades del perfil de rendimiento de la carga de trabajo y, a continuación, implementar las opciones adecuadas en las opciones de proceso y almacenamiento para ofrecer las soluciones de un extremo a otro correctamente.

Comience con el perfil de carga de trabajo

Antes de elegir el proceso o el almacenamiento, defina la carga de trabajo. Entre las dimensiones de planificación útiles se incluyen:

El objetivo no es predecir el futuro perfectamente. El objetivo es evitar diseñar ciegamente.

Descripción de los tres conceptos básicos de rendimiento del almacenamiento

Azure planeamiento del rendimiento del almacenamiento suele reducirse a tres conceptos relacionados, pero distintos: IOPS, rendimiento y latencia. Estos factores son clave para el planeamiento del rendimiento de las aplicaciones.

IOPS

IOPS significa operaciones de entrada y salida por segundo. Mide cuántas operaciones de lectura o escritura puede enviar la base de datos al almacenamiento cada segundo.

IOPS es especialmente importante para las cargas de trabajo OLTP. Estos sistemas suelen realizar muchas lecturas y escrituras pequeñas y aleatorias, como inserciones, actualizaciones, búsquedas de índices, lecturas puntuales y transacciones cortas. Una carga de trabajo transaccional con miles de usuarios simultáneos podría necesitar un número elevado de IOPS incluso si cada operación individual es pequeña.

Entre los escenarios comunes sensibles a IOPS se incluyen:

• Procesamiento de pedidos de gran volumen
• Actualizaciones de perfil de usuario
• Sistemas de inventario
• Procesamiento de eventos
• Sistemas de pago o facturación
• Aplicaciones SaaS altamente simultáneas

Capacidad de procesamiento

El rendimiento, a veces denominado ancho de banda, mide la cantidad de datos que se pueden leer o escribir en el almacenamiento a lo largo del tiempo. Se expresa en MB/s.

El rendimiento es importante cuando las operaciones mueven grandes cantidades de datos. Las consultas analíticas, las copias de seguridad, las restauraciones, los trabajos por lotes, las compilaciones de índices, los exámenes de tabla y los flujos de trabajo de ETL pueden necesitar un alto rendimiento incluso si no requieren el IOPS más alto.

Entre los escenarios comunes sensibles al rendimiento se incluyen:

• Informes de consultas sobre tablas grandes
• Importaciones o exportaciones masivas
• Escaneos estilo almacén de datos
• Operaciones de copia de seguridad y restauración
• Operaciones de creación o recompilación de índices grandes
• Procesamiento por lotes

Latencia

La latencia es el tiempo necesario para que se complete una única solicitud de E/S. La latencia baja es esencial para las operaciones de base de datos orientadas al usuario, especialmente cuando muchas operaciones pequeñas se encadenan en una transacción.

Un sistema puede tener un IOPS teórico alto, pero sigue sintiendo lento si la latencia es alta. En el caso de las cargas de trabajo de Postgres, la latencia de almacenamiento puede afectar directamente a los tiempos de respuesta de las consultas, el comportamiento de confirmación de transacciones, el comportamiento del punto de control y la capacidad de respuesta general de las aplicaciones.

Las IOPS, el rendimiento y la latencia deben tenerse en cuenta conjuntamente

Las IOPS y el rendimiento están conectados. Una carga de trabajo que emite varias operaciones pequeñas de 8 KiB podría impulsar IOPS elevadas sin un alto nivel de rendimiento. Una carga de trabajo que emite operaciones de varios MB grandes podría impulsar un alto rendimiento con una IOPS menor.

Una manera sencilla de pensar en ello:

IOPS x tamaño de E/S = rendimiento

Para Postgres, la implicación práctica es que el planeamiento del almacenamiento de cargas de trabajo debe basarse en el comportamiento observado o estimado de la carga de trabajo, no solo en el tamaño de la base de datos. Por ejemplo:

• Un sistema OLTP de alta simultaneidad podría necesitar más IOPS y una menor latencia.
• Un sistema con mucha generación de informes podría necesitar más rendimiento.
• Un sistema híbrido puede necesitar ambos, especialmente durante los ciclos máximos.
• Un sistema OLTP de alta simultaneidad podría necesitar más IOPS y una menor latencia.
• Un sistema con mucha generación de informes podría necesitar más rendimiento.
• Un sistema híbrido puede necesitar ambos, especialmente durante los ciclos máximos.

Las opciones de implementación afectan directamente al rendimiento del almacenamiento.

Un error común es configurar el almacenamiento para alcanzar un objetivo de rendimiento sin considerar plenamente si la SKU de computación seleccionada puede impulsar los mismos niveles de rendimiento.

El rendimiento del almacenamiento de Azure tiene varias consideraciones. Estos detalles incluyen:

• El conjunto de funcionalidades de proceso (límites máximos de IOPS y rendimiento de proceso).
• Generación de almacenamiento (SSD v1, SSD v2, Disco Ultra).
• El tamaño del disco de almacenamiento (discos SSD v1 inferiores a 4096 GB incluyen el almacenamiento en caché del host, lo cual permite ráfagas de IOPS por encima de las líneas base estándar).
• Capacidad de IOPS de almacenamiento.
• Capacidad de rendimiento de almacenamiento.

En términos prácticos: el límite máximo de rendimiento efectivo es su límite más bajo relevante en la cadena.

Si la configuración de almacenamiento puede proporcionar 80 000 IOPS, pero la SKU de proceso solo puede impulsar 20 000 IOPS, la implementación no entrega 80 000 IOPS. Por el contrario, si la generación de máquinas virtuales admite IOPS elevadas, pero el nivel de almacenamiento seleccionado está limitado a un nivel inferior, el nivel de almacenamiento se convierte en el límite.

La planeación de proceso y almacenamiento debe realizarse conjuntamente.

SSD Prémium v1: rendimiento de línea base sólida con un comportamiento importante del almacenamiento en caché

SSD Premium v1 es una opción común para las cargas de trabajo de producción Azure Postgres que necesitan un rendimiento predecible y aprovisionado. El almacenamiento SSD v1 de Azure Postgres admite hasta 32 TB de espacio, 20 000 IOPS y 900 MB/s de rendimiento.

SSD Prémium v1 funciona bien para cargas de trabajo que se benefician del almacenamiento en caché del host. Azure Postgres admite el almacenamiento en caché del host para tamaños de disco SSD v1 menores de 4096 GB. Cualquier disco aprovisionado hasta 4095 GB puede beneficiarse del almacenamiento en caché del host. Una vez que el almacenamiento se aprovisiona en 4096 GB o superior, no se admite el almacenamiento en caché del host. Ese límite importa. En el caso de las implementaciones de SSD Prémium v1 en menos de 4 TB, el almacenamiento en caché puede mejorar el rendimiento de lectura y reducir la latencia de lectura. Este almacenamiento en caché crea una excelente eficiencia de costo a rendimiento para cargas de trabajo de lectura intensivas o mixtas que caben por debajo del umbral de almacenamiento en caché.

¿Por qué importa el límite de 4 TB?

Cuando una implementación premium de SSD v1 crece más allá del intervalo admitido por el almacenamiento en caché, el perfil de rendimiento puede cambiar:

• Las lecturas ya no se benefician de la memoria caché del host.
• Más operaciones de lectura proceden directamente del disco subyacente.
• Las lecturas cuentan contra los límites de IOPS y rendimiento del disco.
• Es posible que las cargas de trabajo de lectura sensibles a la latencia vean un comportamiento diferente.
• Una configuración que era eficaz anteriormente podría necesitar más IOPS aprovisionadas, más rendimiento, escalado de proceso, ajuste de consultas o una opción de almacenamiento diferente.

Cruzar por encima de 4 TB no es malo, pero debe planearlo .

Si espera que una base de datos crezca más allá de 4 TB, considere el estado futuro durante el diseño de la arquitectura. Un diseño que funciona bien en 2 TB con almacenamiento en caché puede necesitar un plan de rendimiento diferente a 5 TB sin almacenamiento en caché.

La ráfaga ayuda con picos, pero no reemplaza la capacidad sostenida

Azure Postgres Premium SSD v1 asignaciones de almacenamiento bajo 4 TB admiten picos de almacenamiento en caché del host, lo que puede ayudar en escenarios como:

• Actividad de inicio
• Trabajos por lotes cortos
• Picos de tráfico
• Procesamiento de final de mes
• Aumentos de carga de trabajo temporales

Mientras la expansión es útil, úsela cuidadosamente. La expansión puede absorber picos temporales, pero no debe ser la base para la demanda sostenida de volumen de trabajo. Si la carga de trabajo se ejecuta con frecuencia por encima de la línea base, es mejor aprovisionar un nivel de rendimiento superior, ajustar la configuración de rendimiento del almacenamiento, escalar el proceso o rediseñar el patrón de carga de trabajo.

Una buena pregunta de planeación es: ¿Se trata de un pico temporal o es la nueva normalidad?

Los picos temporales pueden ser buenos candidatos para la explosión. Controle la demanda sostenida con el planeamiento deliberado de la capacidad.

SSD premium v2 desacopla la capacidad, las IOPS y el rendimiento

SSD Prémium v2 cambia el modelo de planeamiento desacoplando el tamaño del disco, las IOPS y el rendimiento. Azure Database for PostgreSQL admite SSD Premium v2 en servidores flexibles:

• Capacidad de 32 GB a 64 TB.
• Hasta 80 000 IOPS.
• Rendimiento de hasta 1.200 MB/s.
• Ajustes granulares de capacidad en incrementos de 1 GB.
• Configuración flexible de IOPS y rendimiento.
• Menor latencia que ssd prémium v1.
• Sin caché del host.

Este cambio es un cambio importante. Con SSD Premium v1, el rendimiento está más estrechamente acoplado al tamaño del disco. Con SSD Premium v2, puede configurar el rendimiento más directamente en torno a las necesidades de carga de trabajo.

Por ejemplo, una base de datos con gran cantidad de transacciones podría necesitar un número elevado de IOPS sin necesidad de una gran cantidad de almacenamiento. Azure Postgres proporciona IOPS de línea base y rendimiento sin costo adicional, con IOPS adicionales y rendimiento disponibles para cargos adicionales. Ofertas de SSD Prémium v2:

• Los discos de hasta 399 GB reciben una línea base de 3000 IOPS y 125 MB/s.
• Los discos de 400 GB o más reciben una línea base de 12 000 IOPS y 500 MB/s.
• Los discos pueden alcanzar hasta 80 000 IOPS cuando tienen un tamaño de al menos 160 GB de espacio disponible.
• El rendimiento puede escalar hasta 1200 MB/s.

Ssd Premium v2 suele ser atractivo cuando se necesita un control más preciso sobre el costo y el rendimiento. En lugar de escalar la capacidad de almacenamiento solo para desbloquear el rendimiento, puede aprovisionar el rendimiento de forma más intencionada.

Disco Ultra (versión preliminar): la clase de rendimiento de disco Azure de gama alta

Ultra Disk es la opción de disco de mayor rendimiento. Azure Ultra Disk ofrece niveles de rendimiento hasta:

• 400 000 IOPS
• Rendimiento de 10 000 MB/s
• Capacidad de 64 TB
• Objetivos de diseño de latencia submilisegundo
• Capacidad, IOPS y rendimiento configurables de forma independiente

El almacenamiento en disco Ultra está diseñado para potenciar cargas de trabajo intensivas de E/S para bases de datos de nivel superior, SAP HANA y sistemas con alto volumen de transacciones. Esta nueva oferta de almacenamiento proporciona un rendimiento de primera categoría para sus cargas de trabajo críticas. Sin embargo, el equipo debe tener en cuenta algunas funcionalidades clave de implementación, restricciones de disponibilidad regional y opciones de configuración al planear una implementación:

• El crecimiento automático del almacenamiento no se admite para los servidores que usan disco Ultra
• El cifrado de datos con claves administradas por el cliente no se admite para servidores con disco Ultra
• Los discos Ultra no admiten el almacenamiento en caché de discos

Es importante comprender las funcionalidades de Disco Ultra como parte del entorno de rendimiento de almacenamiento de Azure más amplio. Sin embargo, debe validar la disponibilidad del servicio y la compatibilidad con la carga de trabajo específica de Azure Postgres. Consulte con su representante de Microsoft si la versión preliminar del disco Ultra está disponible para la implementación de Azure Postgres.

La conclusión práctica: Ultra Disk representa el extremo superior del rendimiento de almacenamiento de Azure, pero el diseño de Postgres de un extremo a otro debe incluir combinaciones compatibles de forma comparable para la SKU de proceso, la región y el nivel de versión seleccionados.

La generación de máquinas virtuales es importante: los límites de almacenamiento de proceso V5 y V6 son diferentes

La generación de procesos puede afectar materialmente al rendimiento del almacenamiento. Al explorar el extremo más alto del rendimiento de almacenamiento de Azure, evite el malentendido de que "gran procesamiento" significa automáticamente "almacenamiento máximo". Debe validar la SKU de cómputo seleccionada contra el nivel de almacenamiento previsto. Vamos a ilustrar este punto considerando dos generaciones de computación de tamaño similar, Ddsv5 y Ddsv6:

La serie Ddsv5 admite Premium Storage (con almacenamiento en caché), SSD Premium v2 y Disco Ultra en el nivel de familia de máquinas virtuales. Sin embargo, los límites de almacenamiento remoto agregado de la máquina virtual siguen definiendo el límite máximo para lo que esa máquina virtual puede controlar. Ddsv5-series proporciona un rendimiento de almacenamiento de hasta 80 000 IOPS y 2600 MB/s.

La serie Ddsv6 proporciona una capacidad de almacenamiento superior, que abarca hasta 400 000 IOPS y 12 000 MB/s. El proceso de la serie V6 también ofrece mayor escalabilidad que las generaciones anteriores, con hasta 192 vCPU y memoria de 768 GiB.

Ese cambio generacional es importante para el diseño de Postgres de alto rendimiento. Si la arquitectura de destino requiere un alto rendimiento de almacenamiento, elegir una generación de proceso con un límite de almacenamiento agregado inferior puede impedir que la implementación use la funcionalidad de almacenamiento completa.

Ejemplo: por qué importa la alineación de un extremo a otro

Considere una carga de trabajo de PostgreSQL con un destino de almacenamiento aspiracional de 400 000 IOPS.

En la capa de disco, Azure Disco Ultra admite hasta 400 000 IOPS por disco. SSD Prémium v2 admite hasta 80 000 IOPS por disco, y es posible que los diseños agregados superiores requieran varios discos o abstracción de nivel de plataforma en función de la compatibilidad con el servicio.

Pero la capacidad de almacenamiento por sí sola no es suficiente.

Una configuración de la serie V5 puede tener un límite máximo de almacenamiento inferior al destino. Como se mencionó anteriormente, las SKU de la serie V5 admiten hasta 260 000 IOPS para el rendimiento del disco remoto SSD Premium. En este caso, elegir la capa de cómputo de la serie V5 para este destino se convierte en el factor limitante antes de alcanzar un objetivo de 400.000 IOPS.

Por el contrario, la documentación de la serie Ddsv6 ofrece hasta 400 000 IOPS y 12 000 MB/s. Esto hace que la serie V6 y las generaciones más recientes sea estratégicamente importante para los diseños que necesitan alinear el proceso y el almacenamiento en torno a las clases de rendimiento de almacenamiento más altas.

La lección es sencilla: el rendimiento máximo de la base de datos es una propiedad de un extremo a otro, no una propiedad de solo almacenamiento.

Planear ciclos de negocio, no solo estado estable

Muchos sistemas no tienen un único perfil de rendimiento. Tienen varias:

Una base de datos dimensionada para un uso promedio podría tener problemas en los momentos más críticos. Por el contrario, una base de datos de tamaño permanente para un pico de una vez al mes podría ser innecesariamente costosa.

La flexibilidad de Azure permite a los equipos tomar decisiones más matizadas. Por ejemplo:

• Use SSD Premium v2 para ajustar las IOPS y el rendimiento a medida que evolucionan las necesidades de carga de trabajo.
• Use réplicas de lectura para aliviar cargas de trabajo intensivas de lectura cuando corresponda.
• Aumente la capacidad de computación para los períodos máximos conocidos.
• Ajuste las consultas, los índices y la agrupación de conexiones antes de escalar la infraestructura.
• Use la observabilidad para identificar si el cuello de botella es CPU, memoria, IOPS, ancho de banda, contención de bloqueos, saturación de conexiones o diseño de consultas.

La mejor implementación no siempre es la implementación más grande. Es el diseño que coincide con la carga de trabajo y puede evolucionar de forma segura.

La observabilidad forma parte de la arquitectura

El planeamiento del rendimiento no debe detenerse en la implementación. Las cargas de trabajo de Postgres cambian con el tiempo. Los datos crecen, los patrones de consulta cambian, se lanzan nuevas funciones, el tráfico de clientes cambia y los trabajos operativos se acumulan.

La documentación de Azure Database for PostgreSQL resalta la supervisión del consumo de E/S a través del portal de Azure o las métricas de CLI de Azure, incluidos el límite de almacenamiento, el porcentaje de almacenamiento, el almacenamiento usado y el porcentaje de E/S.

Estas métricas ayudan a responder a la pregunta operativa más importante: ¿qué capa limita realmente el rendimiento?

Sin observabilidad, los equipos podrían escalar de manera incorrecta. Un problema del plan de consulta podría parecerse a un problema de almacenamiento. Las tormentas de conexión pueden tener un aspecto similar a la presión de CPU. Un índice que falta podría ser similar a una IOPS insuficiente. Un problema de ubicación de cliente regional podría tener un aspecto similar a la latencia de la base de datos.

La supervisión ayuda a los equipos a realizar cambios específicos en lugar de adivinaciones costosas.

Lista de comprobación de planificación práctica

Antes de seleccionar la configuración de Azure Database for PostgreSQL de producción, capture la siguiente información.

Principios de diseño recomendados

Use los siguientes principios al planear las implementaciones de Azure Postgres para el rendimiento operativo.

• Ajuste el tamaño según la forma del trabajo, no solo el tamaño de los datos.
  Una base de datos de 500 GB puede necesitar más IOPS que una base de datos de 5 TB si es muy transaccional y sensible a la latencia. El tamaño es importante, pero el comportamiento de la carga de trabajo es más importante.
• Valide la capacidad de cómputo y el almacenamiento juntos.
  No elija almacenamiento solo en función de los límites de disco. Confirme que la SKU de proceso seleccionada puede impulsar las IOPS y el rendimiento necesarios.
• Trate el límite de almacenamiento en caché de SSD Premium de 4 TB como un hito de diseño.
  Las implementaciones de SSD Premium de menos de 4 TB pueden beneficiarse del almacenamiento en caché del host. A 4,096 GB y superiores, no se admite el almacenamiento en caché del host. Si el crecimiento superará ese umbral, planee el modelo de rendimiento futuro pronto.
• Considere la opción de SSD Premium v2 para ajustar el rendimiento de manera flexible.
  SSD Premium v2 permite un control más granular de la capacidad, las IOPS y el rendimiento. Puede ser una opción sólida cuando las necesidades de rendimiento no se ajustan claramente a los tamaños de disco fijos.
• Utiliza la expansión para los picos, no para la demanda sostenida.
  El rebasamiento puede ayudar con picos de corta duración, pero el rebasamiento frecuente o sostenido normalmente significa que se debe reconsiderar la configuración de línea base.
• Alinear la generación con la ambición.
  En el caso de los objetivos de rendimiento de alto nivel, las generaciones de proceso más recientes, como la serie v6, pueden exponer límites de almacenamiento remoto agregados más altos que las generaciones anteriores de uso general. Si el destino es una arquitectura de 400 000 IOPS, seleccione la generación de cálculo en consecuencia.
• Mida antes y después de los cambios.
  El escalado es más fácil en la nube, pero la medición es lo que hace que el escalado sea eficaz. Capture las métricas de línea de base, pico y posterior al cambio, por lo que las decisiones de rendimiento se basan en pruebas.

Prueba comparativa real: comparación de configuraciones de almacenamiento bajo carga

Los principios descritos en este artículo no son teóricos. Para demostrar cómo interactúan en la práctica el proceso, el almacenamiento y la carga de trabajo, en esta sección se resumen pgbench los puntos de referencia que comparan las configuraciones de almacenamiento y los niveles de proceso en condiciones controladas y medidas.

Configuración y metodología de pruebas comparativas

Las pruebas comparativas usan pgbench, la herramienta de pruebas comparativas de PostgreSQL estándar, para simular una carga de trabajo transaccional en cinco configuraciones de proceso y almacenamiento diferentes. La prueba comienza con 500 conexiones simultáneas y aumenta hasta 750 conexiones simultáneas después de un período inicial, manteniendo esta carga de conexión con privilegios elevados durante el resto de la ventana de prueba. Este patrón de rampa simula el número de aplicaciones reales que aumentan la carga a lo largo del tiempo a medida que crece el tráfico y mide cómo responde la base de datos tanto al pico inicial como a la alta simultaneidad sostenida.

Todas las pruebas comparativas se ejecutan en Azure Database for PostgreSQL servidor flexible en la misma región, dentro de la misma zona de disponibilidad, con el mismo perfil de carga de trabajo y base de datos de prueba. Al aislar el almacenamiento y el proceso como variables, se garantiza que las diferencias de rendimiento reflejen las funcionalidades reales de la plataforma en lugar de la variación de red, aplicación o carga de trabajo.

Detalles de configuración

Pruebe cinco configuraciones distintas, que varían tanto el nivel de almacenamiento como el tamaño de proceso para ilustrar los conceptos clave de planeamiento.

Observaciones clave del diseño de configuración:

• Configuración 1 frente a configuración 2: Estas configuraciones solo difieren en el tamaño de almacenamiento, 4095 GB frente a 4096 GB. Esta comparación prueba el límite de almacenamiento en caché del host para discos SSD Prémium v1.
• Configuración 2 frente a Configuración 3: Ambas configuraciones usan SSD v1, pero Config 3 escala a la capacidad de 32 TB para desbloquear mayores IOPS y rendimiento.
• Configuración 3 frente a Configuración 4: Ambas configuraciones usan el mismo cómputo, pero Configuración 4 demuestra las IOPS flexibles y el rendimiento del Premium SSD v2 independientemente de la capacidad.
• Configuración 4 frente a Configuración 5: La Configuración 5 duplica la SKU de computación para demostrar cómo la computación de nivel superior desbloquea más capacidad de rendimiento de almacenamiento.

Resultados de rendimiento

Configuración 1: 4.095 GB Premium SSD v1 con caché del host

La Configuración 1 utiliza el tamaño de 4,095 GB de SSD Premium v1, que se beneficia del almacenamiento en caché del host en SSD Premium v1. Durante la carga de trabajo, esta configuración se mantuvo:

• Número máximo de IOPS: 24 773, limitado por 7500 IOPS aprovisionados en SSD Premium v1, con almacenamiento en caché que amplía el rendimiento eficaz.
• Número máximo de IOPS de lectura: 21 330, que se beneficia de la memoria caché del host para las operaciones de lectura intensiva.
• IOPS de escritura máxima: 7610.

El almacenamiento en caché del host proporciona amplificación de lectura, por lo que las IOPS efectivas superan momentáneamente el límite de IOPS aprovisionado de 7500 del disco y alcanzan los límites de almacenamiento de proceso.

Configuración 2: SSD Premium v1 de 4,096 GB sin caché de host

La configuración 2 utiliza el tamaño de 4.096 GB del Premium SSD v1, superando el límite de almacenamiento en caché y perdiendo los beneficios del almacenamiento en caché del host. El impacto es visible:

• Número máximo de IOPS: IOPS efectivas inferiores en comparación con la configuración 1 debido a la pérdida de almacenamiento en caché.
• Número máximo de IOPS de lectura: Se ha reducido considerablemente sin la memoria caché del host.
• Número máximo de IOPS de escritura: 7610, sin cambios.

Esta configuración muestra la importancia práctica del límite de almacenamiento en caché de 4 TB. El cruce de 4095 GB a 4096 GB cambia el perfil de rendimiento quitando las lecturas almacenadas en caché. Para las bases de datos crecientes que se aproximan a este umbral, planee con antelación.

Configuración 3: SSD 32 TB Premium v1 con IOPS superiores

La configuración 3 aborda las IOPS superiores de SSD prémium v1 y los límites de rendimiento mediante el escalado a la capacidad de 32 TB. Esta configuración ha logrado:

• Número máximo de IOPS: 20 000.
• Número máximo de IOPS de lectura: Aproximadamente 12.000.
• Número máximo de IOPS de escritura: Aproximadamente 5.000.

Aumentar la capacidad de almacenamiento de SSD prémium v1 subyacente aumenta la IOPS y el rendimiento. Todavía puede alcanzar los límites superiores del rango de capacidad de cálculo para cargas de trabajo intensivas.

Configuración 4: SSD prémium v2 con 40 000 IOPS

La configuración 4 muestra la configuración de rendimiento flexible de SSD prémium v2, el aprovisionamiento de 40 000 IOPS y el rendimiento de 1200 MB/s en 4095 GB de capacidad:

• Número máximo de IOPS: Mayor uso efectivo debido a la latencia y la capacidad de rendimiento de SSD prémium v2.
• Número máximo de IOPS de lectura: Rendimiento mejorado en comparación con las configuraciones premium de SSD v1.
• Número máximo de IOPS de escritura: Mayor capacidad de escritura sostenida.

SSD Premium v2 permite aprovisionar altas IOPS sin necesidad de una gran capacidad de almacenamiento, lo que lo hace eficaz para cargas de trabajo con gran cantidad de transacciones.

Configuración 5: SSD premium v2 con 60 000 IOPS en D32ds_v5 computo

La Configuración 5 escala tanto el rendimiento del almacenamiento, con 60,000 IOPS, como la capacidad de procesamiento, con Standard_D32ds_v5 y 32 núcleos virtuales. Esta configuración muestra el principio de alineación de un extremo a otro:

• Número máximo de IOPS: Significativamente mayor que todas las configuraciones anteriores.
• Número máximo de IOPS de lectura: Una mejora significativa con capacidad de procesamiento adicional.
• Número máximo de IOPS de escritura: Capacidad de escritura mayor sostenida.

Al alinear tanto el proceso como el almacenamiento con niveles de rendimiento más altos, esta configuración logra el mejor rendimiento y la presión de CPU más baja. El límite superior de almacenamiento de D32ds_v5 permite que el disco SSD 2 Premium v2 de 60 000 IOPS sea más utilizado.

Lecciones de los puntos de referencia

Estas cinco configuraciones muestran los principios clave de este artículo:

• El límite de almacenamiento en caché de 4 TB es importante.
  La Configuración 1 frente a la Configuración 2 muestra que el almacenamiento en caché proporciona una amplificación medible del rendimiento de lectura por debajo de 4 TB, mientras que al cruzar los 4096 GB se elimina esa ventaja.
• La capacidad no es el rendimiento.
  La configuración 3 aprovisionó 32 TB, pero no entregó las IOPS más altas. La capacidad de almacenamiento por sí sola no determina el rendimiento de las transacciones.
• SSD Premium v2 proporciona un ajuste flexible del rendimiento.
  La configuración cuatro demostró un alto número de IOPS en una capacidad modesta, lo que valida el modelo desacoplado habilitado por SSD Premium v2.
• El proceso y el almacenamiento deben estar alineados.
  Config cinco muestra que maximizar el rendimiento del almacenamiento requiere una capacidad de cálculo suficiente. El límite superior de almacenamiento de D32ds_v5 era necesario para usar más completamente el aprovisionamiento de 60 000 IOPS.

Los resultados de la prueba comparativa validan el principio principal: el rendimiento máximo es una propiedad de un extremo a otro. Ninguna capa única, como el almacenamiento, el proceso o las redes, determina el resultado. El éxito requiere una alineación intencionada en todas las capas, la validación medida y la observación continua a medida que evolucionan las cargas de trabajo.

Conclusión

Azure Postgres proporciona una plataforma eficaz y flexible para crear soluciones modernas de bases de datos hospedadas en la nube. La ingeniería en Azure proceso, almacenamiento, redes, alta disponibilidad, replicación, seguridad y observabilidad permite algunas de las arquitecturas postgres más eficaces y resistentes disponibles.

El rendimiento máximo no sucede por accidente.

El rendimiento operativo máximo requiere comprender la aplicación, los clientes, la carga de trabajo, el perfil de crecimiento de datos, la combinación de lectura y escritura y los ciclos de negocio que dan forma a la demanda. También requiere alinear las opciones de proceso y almacenamiento para que los objetivos de IOPS, rendimiento y latencia se logren de un extremo a otro.

Premium SSD v1 puede proporcionar un rendimiento seguro y predecible, especialmente cuando la caché del host se aplica a datos situados por debajo del umbral de 4 TB. SSD Premium v2 agrega una configuración de rendimiento más flexible al desacoplar la capacidad, las IOPS y el rendimiento. Ultra Disk representa la clase de rendimiento de disco administrado más alta Azure, mientras que las generaciones de proceso más recientes proporcionan límites de almacenamiento remoto agregados considerablemente más altos para arquitecturas de gama alta.

Las mejores Azure implementaciones de Postgres combinan la funcionalidad de la plataforma con planeación deliberada, supervisión continua y clara propiedad operativa. Con los requisitos adecuados y la arquitectura adecuada, los equipos pueden ofrecer experiencias de Postgres de primera clase que proporcionan un rendimiento máximo.

Contenido relacionado

• Azure Premium Storage: diseño para alto rendimiento
• Azure aumento de rendimiento del disco
• Tamaños de VM de las series Ddv5 y Ddsv5
• Tamaños de máquina virtual de la serie Ddsv6
• Opción de Almacenamiento Premium SSD en Azure Database for PostgreSQL
• Opción de almacenamiento SSD v2premium en Azure Database for PostgreSQL
• Tipos de discos administrados de Azure
• Supervisión de métricas en Azure Database for PostgreSQL