Comparación de instancias cloud

La misma forma en tres nubes, y por qué no es el mismo trato

Elegir una instancia de base de datos suele empezar por una forma — tantas vCPU, tanta memoria — y acabar en el nombre más barato por encima de ese suelo dentro de la lista del proveedor. Esta herramienta hace esa búsqueda a la vez en AWS RDS, Google Cloud SQL y Azure Flexible Server, y añade el número que esas listas omiten: cuántas conexiones te dejará abrir realmente cada una.

Cómo funciona

• Toma un mínimo de vCPU y un mínimo de memoria y encuentra, por nube, la instancia más pequeña que cumple ambos.
• Muestra dos opciones mayores al lado, para ver qué cuesta en recursos el siguiente escalón.
• Imprime el límite de conexiones de cada instancia junto a su forma, calculado con la regla de ese proveedor.
• Marca explícitamente la coincidencia más pequeña, porque la primera fila de la tabla de un proveedor rara vez es la que quieres.

coincidencia más pequeña = mínimo entre instancias donde
    vcpu >= tu_mínimo  Y  memoria >= tu_mínimo
  ordenadas por vcpu, luego por memoria

las conexiones salen de la regla publicada por cada
proveedor, no de un estándar común del sector

Ejemplo resuelto

Un servicio que necesita al menos 8 vCPU y 32 GiB, comparado en las tres nubes.

1. AWS: db.m5.2xlarge — 8 vCPU, 32 GiB, unas 3.324 conexiones
2. Azure: B8ms — 8 vCPU, 32 GiB, 3.437 conexiones
3. Google Cloud SQL: db-custom-8-53248 — 8 vCPU, 52 GiB, 600 conexiones
4. las formas casi coinciden en dos nubes; los límites de conexiones no coinciden en absoluto

AWS y Azure aterrizan en hardware prácticamente idéntico con techos de conexión prácticamente idénticos. Cloud SQL te da 20 GiB más de memoria y en torno a una quinta parte de las conexiones. Si tu servicio pesa en conexiones y no en memoria, ahí está toda la decisión.

Cómo leer el resultado

• Cloud SQL admite formas de máquina personalizadas arbitrarias, así que la coincidencia más pequeña que se muestra para Google es la más pequeña de este catálogo, no la más pequeña que existe. Allí hay disponible una forma de exactamente 8 vCPU y 32 GiB; la columna lo advierte, y la cifra de Google debe leerse como una muestra.
• La coincidencia más pequeña a veces es de tipo burstable, y burstable no equivale. La serie B de Azure y la clase t de AWS acumulan créditos de CPU en reposo y estrangulan cuando se agotan: válido para una base de desarrollo o una herramienta interna irregular, malo para cualquier cosa con carga de fondo sostenida.
• Las cifras de vCPU no se comparan entre nubes sin cuidado. Las instancias AWS Graviton cuentan núcleos físicos mientras las clases x86 cuentan hilos, así que 8 vCPU de Graviton y 8 vCPU de x86 no son la misma potencia. Compara con confianza dentro de una nube y solo a grandes rasgos entre nubes.
• Esto compara forma y techo de conexiones, no precio. La capacidad reservada, los descuentos por compromiso de uso y los planes de ahorro mueven el coste real por múltiplos grandes, y lo mueven distinto en cada nube, así que comparar formas inicia una decisión, no la cierra.
• Para la mayoría de bases la memoria pesa más que las vCPU, porque determina tanto la caché que mantiene las consultas fuera del disco como, en AWS y Azure, el propio techo de conexiones. Si dudas qué suelo subir, sube la memoria.

Preguntas frecuentes

¿Por qué Google muestra más memoria de la que pedí?

Porque el catálogo aquí muestrea formas comunes de Cloud SQL en lugar de enumerarlas todas, y la forma muestreada más cercana por encima de tu suelo puede pasarse. Cloud SQL admite formas personalizadas, así que normalmente puedes pedir la memoria exacta que quieres: toma la columna de Google como orientativa.

¿La coincidencia más pequeña es siempre la elección correcta?

Es lo más barato que supera tu suelo, lo cual solo acierta si el suelo acierta. Fija el suelo a partir del uso medido más margen para el crecimiento y para la conmutación por error, no del pico actual: una instancia dimensionada exactamente al pico de hoy no tiene sitio para el de mañana.

¿Por qué difieren tanto los límites de conexiones con la misma memoria?

Porque los fijan reglas distintas con intenciones distintas. AWS y Azure derivan el límite de la memoria y caen en el mismo rango. Google lo fija por tramos de memoria con valores mucho más bajos, suponiendo que las cargas con muchas conexiones usan un pooler. Ninguna de las tres se equivoca; se aplican de forma distinta y eso es lo que te afecta.