Llegamos a ustedes gracias a:



Reportajes y análisis

MySQL se revela: Amazon supera a Google

Amazon Aurora y Google Cloud SQL

[14/11/2016] Muchas aplicaciones web se han construido sobre una pila de código abierto que incluye a MySQL. A pesar de sus limitaciones, MySQL logró convertirse en el RDBMS de código abierto más utilizado del mundo. ¿Qué limitaciones tiene? Fuera de la caja, MySQL no escala del todo bien y, en particular, no puede manejar una gran cantidad de clientes simultáneos en comparación con las bases de datos comerciales.

Amazon Aurora y Google Cloud SQL fueron desarrollados para ofrecer a los clientes de alto rendimiento, escalabilidad de bases de datos MySQL como servicio. Cada uno funciona mejor como parte de una pila de aplicaciones que residen no solo en el mismo proveedor de nube, sino también en la misma zona de disponibilidad, para minimizar la latencia entre los servicios y maximizar el rendimiento de la red dentro de la pila.

Comparé y revisé Amazon Aurora hace aproximadamente un año. Más recientemente, di una pre visualización a Google Cloud SQL. En este artículo, le explicaré qué pasó cuando hice un benchmarking de Google Cloud SQL con Amazon Aurora utilizando una carga transaccional con un número variable de subprocesos de cliente.

Benchmarking de SQL en la nube

Los benchmark son realmente difíciles de realizar correctamente. Son fáciles de hacer mal, lo que lleva a la expresión "mentiras, malditas mentiras y benchmarks". Y se pueden hacer de manera que carezcan de sentido, pero suenan impresionantes en su discurso comercial.

Para mi revisión de Amazon Aurora, reproduje más o menos los propios benchmarks de Amazon, con cierta dificultad. Inicialmente registré la mitad de las cifras que Amazon informó de sus pruebas de solo lectura y escritura de Sysbench. Después de trabajar con uno de los ingenieros de Amazon para diagnosticar las diferencias entre mi configuración y la suya, cambié la zona de disponibilidad de los clientes para que coincida con la zona de disponibilidad de la base de datos, y realmente registró cifras de escritura más altas que Amazon. Como resultado, las tasas de escritura de Aurora tienden a empezar altas; a continuación, bajan de nivel, a pesar de que estaba ejecutando una prueba más pequeña que la que Amazon tenía.

Había varias otras sutilezas de la configuración que me preocupaban, pero en realidad se hizo bien, principalmente un controlador de red mejorado y las modificaciones a la configuración de enrutamiento de red de Linux.

En mi primer vistazo a Google Cloud SQL, sentí que no tenía tiempo ni recursos para reproducir las pruebas transaccionales de Sysbench de Google de su propia base de datos Cloud SQL, Amazon RDS para MySQL y Amazon RDS para Aurora, por lo que imprimí los resultados de Google con la salvedad de que aún no habían sido replicados por InfoWorld. También califiqué cualquier conclusión que planteé sobre la comparación de rendimiento diciendo "según resultados de Google".

Ahora he intentado replicar los resultados de Google. También he probado una configuración diferente que sentía que sería más representativa de la forma en que la gente podría tratar de utilizar bases de datos de alto rendimiento como Google Cloud SQL y Amazon Aurora. Entré en el proceso de benchmark pensando que tomaría una semana de trabajo; en realidad tomó dos semanas y necesité ayuda de ingenieros de Google y de Amazon para asegurarme de que estaba probando cada una de sus bases de datos correctamente.

En el camino aprendí mucho sobre cómo administrar los servicios de base de datos. En comparación a luchar contra una gran base de datos en un servidor local físico, Google Cloud SQL y Amazon Aurora son sueños hechos realidad, al menos una vez que los datos se han cargado.

Figura 1. Tasa de transacción de disco por hilo por subprocesos de Sysbench simultáneos para dos ejecuciones, contra el mayor tipo de instancia de Google Cloud SQL Second Generation disponible (db-n1-highmem-16) y los dos tipos de instancias de Amazon Aurora más grandes, 4xlarge (comparable al db-n1-highmem-16 de Google) y 8xlarge (dos veces más potente y caro). Las tasas de transacción más altas son mejores.
Amazon Aurora y Google Cloud SQL

Los benchmarks que Google y yo ejecutamos miden el procesamiento de transacciones en línea (OLTP) usando Sysbench, una herramienta de benchmarking favorita de la comunidad MySQL, y variando el número de subprocesos de cliente como un proxy para variar el número de clientes reales. En ambos casos creamos una réplica de conmutación por error única. Tenga en cuenta que cuando se utiliza el terminal de clúster Amazon Aurora, la base de datos principal toma la función de escritor y la réplica toma un rol de lector.

Me tomó varios intentos y ayuda de ingenieros de Google y Amazon para ejecutar los benchmarks completos. Tenga en cuenta que mi primera ejecución, codificada en azul, termina con 256 hilos. La carga de la base de datos tardó unas cinco horas; la ejecución de las pruebas OLTP tomó una media hora por recuento de hilos.

Como se puede ver al observar la figura anterior con la primera figura en el blog de Google, comparando Google Cloud SQL con Amazon RDS para MySQL y Amazon RDS para Aurora, ahora podría haber una conclusión diferente a la cual llegar acerca del rendimiento relativo de Google Cloud SQL y Amazon Aurora.

En la figura de Google, Google Cloud SQL Segunda Generación supera a Amazon RDS para Aurora, así como a Amazon RDS para MySQL para transacciones con disco por subproceso por debajo de 16 subprocesos. En una de mis ejecuciones (codificada en azul), eso es cierto; en la otra (codificada en amarillo), Amazon Aurora 4xlarge (comparable a la mayor instancia de Google Cloud SQL) y 8xlarge (el doble de potencia) superan a Google Cloud SQL para todos los conteos de hilos.

Sé lo que sucedió para arruinar la primera ejecución a 512 hilos, gracias a la ayuda de un ingeniero de Google: la máquina virtual de cliente se quedó sin control de archivos. Lo arreglé antes de la segunda ejecución, pero aparentemente algo más estaba pasando para aumentar la latencia y disminuir la tasa de transacción a principios de la segunda ejecución. Sospecho que la réplica leída todavía estaba alcanzando la base de datos primaria, basada en mis instantáneas de la consola tomadas durante la ejecución, pero eso no es una conclusión firme.

No comparé Amazon RDS para MySQL -pensé que era irrelevante. Los ingenieros de Google no evaluaron una instancia de Amazon Aurora 8xlarge porque Google no tiene un tamaño de instancia comparable.

Variaciones sobre un tema

Utilizando la misma secuencia de benchmark que los ingenieros de Google, mis mediciones de Amazon Aurora 4xlarge fueron más altas que las suyas para todos los conteos de hilos. Esto me hace preguntarme si los ingenieros de Google han dejado de lado una o más de las configuraciones recomendadas para el benchmarking de Aurora, tal vez el controlador de red mejorado de Amazon, que se instaló de forma predeterminada en el cliente AMI de Amazon (Red Hat) Linux que ejecuté, pero que no instalé de forma predeterminada en el cliente de Ubuntu Trusty AMI que sospecho que Google ejecutó.

Mi evidencia para esta sospecha es que la escritura publicada de Google es para Ubuntu Trusty, y utiliza la versión de cliente de MySQL enviada con versiones finales de Trusty. Tuve que modificar primero la parte de configuración del script para ejecutar sobre Ubuntu Xenial en la nube de Google y de nuevo para ejecutar sobre Red Hat en la nube de Amazon.

La necesidad de utilizar el controlador de red mejorado y las otras condiciones recomendadas para la evaluación comparativa de Amazon Aurora se discuten en el documento de referencia de Amazon.

Para completar, veamos también las tasas de transacción reales:

Figura 2. Tasa de transacción relacionada con el disco por subprocesos de Sysbench simultáneos para dos ejecuciones contra el tipo de instancia de Google Cloud SQL Second Generation disponible (db-n1-highmem-16) y los dos tipos de instancia de Amazon Aurora más grandes, 4xlarge Comparable al db-n1-highmem-16 de Google) y 8xlarge (dos veces más potente y caro). Las tasas de transacción más altas son mejores.
Amazon Aurora y Google Cloud SQL

Y las latencias medidas:

Figura 3. Latencias relacionadas con el disco por subprocesos de Sysbench simultáneos para dos ejecuciones contra el tipo de instancia de Google Cloud SQL Second Generation disponible (db-n1-highmem-16) y los dos tipos de instancias de Amazon Aurora más grandes, 4xlarge (comparable A Google db-n1-highmem-16) y 8xlarge (dos veces más potente y caro). La latencia más baja es mejor.
Amazon Aurora y Google Cloud SQL

Las tasas de transacción cuentan la misma historia que las tasas de transacción por hilo, como deberían, ya que se basan en los mismos números sin procesar. Las latencias son consistentes con lo que Google midió, aunque las gráficas parecen diferentes debido a la enorme variación de latencia en Amazon RDS para MySQL que se muestra en el gráfico de Google.

Tenga en cuenta que, en el conteo más alto de hilos de clientes, la base de datos de Amazon Aurora 8xlarge todavía tenía al menos un 20% de capacidad de CPU de reserva: Esta prueba en particular estaba limitada en la red en el cliente, lo cual es consistente con la necesidad de usar varias VM cliente con sus propias conexiones de red para saturar Aurora, como Amazon siempre ha mencionado en su asesoramiento de benchmarking.

En mi primer vistazo a Google Cloud SQL, dije (citando el consejo de Google, así como la percepción de mi propia experiencia) que, si desea que su base de datos sea rápida, haga que el tamaño máximo de la tabla se ajuste a la memoria. En las pruebas anteriores, las tablas tenían 20 millones de filas, lo que las hacía (deliberadamente) cinco veces más grandes que la capacidad de memoria de las bases de datos Google Cloud SQL y Amazon Aurora 4xlarge, y dos veces más grande que la capacidad de memoria de la base de datos Aurora 8xlarge de Amazon.

Siguiendo el principio de "ajuste la tabla más grande a la memoria", volví a realizar los benchmarks utilizando tablas con 4 millones de filas, que encajan en la memoria de todas las bases de datos que probé.

Echemos un vistazo a las tasas de transacción, junto con las tasas de transacción por hilo:

Figura 4. Tasas de transacciones de tabla pequeña (tablas en la memoria) por subprocesos de Sysbench simultáneos para el tipo de instancia de Google Cloud SQL de segunda generación disponible (db-n1-highmem-16) y los dos tipos de instancias de Amazon Aurora más grandes, 4xlarge (comparable al db-n1-highmem-16 de Google) y 8xlarge (dos veces más potente y caro). Las tasas de transacciones más altas son mejores. En el conteo de hilos más alto para Amazon Aurora 8xlarge, el rendimiento estuvo limitado por la red en la VM cliente.
Amazon Aurora y Google Cloud SQL
Figura 5. Tasas de transacciones de tablas pequeñas (tablas que se ajustan a la memoria) por hilos Sysbench simultáneos para la instancia de tipo más grande disponible de Google Cloud SQL Second Generation (db-n1-highmem-16) y los dos tipos de instancia más grandes de Amazon Aurora, 4xlarge (comparable al db-n1-highmem-16 de Google) y 8xlarge (dos veces más potente y costoso). Las tasas más altas son mejores. En el conteo más alto de hilos para Amazon Aurora 8xlarge, el rendimiento estuvo limitado por la red en la VM del cliente.
Amazon Aurora y Google Cloud SQL

Y las latencias medidas:

Figura 6. Latencia de tablas pequeñas (tablas en la memoria) por hilos concurrentes de Sysbench para el tipo de instancia de Google Cloud SQL de segunda generación disponible (db-n1-highmem-16) y los dos tipos de instancias de Amazon Aurora más grandes, 4xlarge (comparable al db-n1-highmem-16 de Google) y 8xlarge (dos veces más potente y caro). La latencia más baja es mejor.
Amazon Aurora y Google Cloud SQL

No tenemos mediciones externas en comparación con las cuales compararlas, así que vamos a compararlas con las mediciones de disco. Básicamente, muestran tasas de transacción algo más altas y latencias más bajas en todo el tablero, lo que refleja el hecho de que la mayoría de las operaciones de lectura se almacenaron en caché en memoria, aunque las escrituras debían ser comprometidas con los discos de estado sólido.

Si está planeando hacer caber el tamaño máximo de la tabla dentro de la memoria, éstas son las nuevas cifras que debe esperar ver. En particular, si necesita que la latencia de la base de datos sea inferior a 500 ms (para elegir una restricción común pero holgada), entonces cualquiera de estas bases de datos hará el truco para usted en un máximo de 256 subprocesos.

Amazon Aurora servirá para conteos de 512 hilos y más altos, pero la latencia de Google Cloud SQL podría no ser ilimitada. Si su restricción de latencia es diferente, dibuje su propia línea en el gráfico y llegue a sus propias conclusiones. Puede consultar el gráfico TPS (figura 4) para encontrar la tasa de transacción esperada para el recuento de hilos que cumpla con la restricción de latencia que elija.

Sacando conclusiones

Como hemos visto, mis intentos de benchmarking de Google Cloud SQL y Amazon Aurora no soportan completamente la afirmación de superioridad de Google en un número bajo de subprocesos. La afirmación solo parece válida para las bases de datos con disco y quizás no siempre. Sin embargo, eso no significa que Amazon Aurora sea necesariamente una mejor opción que Google Cloud SQL.

Las conclusiones que no han cambiado desde mi primera mirada a Google Cloud SQL se repiten. En primer lugar, estas dos no son las únicas opciones para bases de datos compatibles con MySQL de alto rendimiento y alta escalabilidad. Tanto DeepSQL como ClustrixDB también merecen consideración. En segundo lugar, Amazon Aurora puede ampliarse e ir más allá de Google Cloud SQL, no solo en memoria y número de CPU, sino también en capacidad de almacenamiento (64TB frente a 10TB) y número de objetivos de failover (15 frente a 1). Para algunas aplicaciones, eso puede importar. Para otras no tanto.

En tercer lugar, las bases de datos funcionan mejor cuando están "cerca" de las aplicaciones que las utilizan. Si sus aplicaciones ya se encuentran en las nubes de Google o de Amazon, entonces tiene sentido mantener sus bases de datos no solo en la misma nube que las aplicaciones, sino también en la misma zona de disponibilidad. Por experiencia personal, puede perder fácilmente un factor de dos en el rendimiento máximo de la base de datos y más que eso en latencia poniendo el cliente y la base de datos en diferentes zonas, incluso si están en la misma región.

Por último, permítanme repetir el hecho más importante acerca de los benchmarks: No son su aplicación, y pueden o no tener ningún parecido con sus cargas. Realice sus propias pruebas utilizando sus perfiles de carga reales durante un período de horas, no minutos, antes de comprometerse con una base de datos como servicio u otro.

Martin Heller, InfoWorld (EE.UU.)