Según mi experiencia, Amazon Aurora no es adecuado para ejecutar una base de datos con mucho tráfico de escritura. Al menos en su implementación alrededor de 2017. Quizás mejore con el tiempo.
Trabajé en algunos puntos de referencia para una aplicación de escritura intensa a principios de 2017 y descubrimos que RDS (no Aurora) era muy superior a Aurora en el rendimiento de escritura, dada nuestra aplicación y base de datos. Básicamente, Aurora era dos órdenes de magnitud más lenta que RDS. Aparentemente, las afirmaciones de Amazon sobre el alto rendimiento de Aurora son una tontería totalmente impulsada por el marketing.
En noviembre de 2016, asistí a la conferencia Amazon re:Invent en Las Vegas. Traté de encontrar un ingeniero de Aurora con conocimientos para responder a mis preguntas sobre el rendimiento. Todo lo que pude encontrar fueron ingenieros junior a quienes se les ordenó repetir la afirmación de que Aurora es mágicamente 5-10 veces más rápida que MySQL.
En abril de 2017, asistí a la conferencia Percona Live y vi una presentación sobre cómo desarrollar una arquitectura de almacenamiento distribuido similar a Aurora utilizando MySQL estándar con CEPH para una capa de almacenamiento distribuido de código abierto. Hay un seminario web sobre el mismo tema aquí:https://www.percona. com/resources/webinars/mysql-and-ceph , copresentado por Yves Trudeau, el ingeniero al que vi hablar en la conferencia.
Lo que quedó claro sobre el uso de MySQL con CEPH es que los ingenieros tuvieron que deshabilitar el Búfer de cambio de MySQL porque no hay forma de almacenar en caché los cambios en los índices secundarios, mientras que también se distribuye el almacenamiento. Esto causó enormes problemas de rendimiento para escrituras en tablas que tienen índices secundarios (no únicos).
Esto fue coherente con los problemas de rendimiento que vimos al comparar nuestra aplicación con Aurora. Nuestra base de datos tenía muchos índices secundarios.
Entonces, si absolutamente tiene que usar Aurora para una base de datos que tiene un alto tráfico de escritura, le recomiendo que lo primero que debe hacer es descartar todos sus índices secundarios.
Obviamente, esto es un problema si se necesitan los índices para optimizar algunas de sus consultas. Ambas consultas SELECCIONAR, por supuesto, pero también algunas consultas ACTUALIZAR y ELIMINAR pueden usar índices secundarios.
Una estrategia podría ser hacer una réplica de lectura que no sea de Aurora de su clúster de Aurora y crear los índices secundarios solo en la réplica de lectura para admitir sus consultas SELECT. Nunca he hecho esto, pero aparentemente es posible, según https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Pero esto todavía no ayuda en los casos en los que sus declaraciones UPDATE/DELETE necesitan índices secundarios. No tengo ninguna sugerencia para ese escenario. Puede que no tengas suerte.
Mi conclusión es que no elegiría usar Aurora para una aplicación de escritura intensa. Tal vez eso cambie en el futuro.
Actualización de abril de 2021:
Desde que escribí lo anterior, he ejecutado los puntos de referencia de sysbench con la versión 2 de Aurora. No puedo compartir los números específicos, pero concluyo que las mejoras actuales de Aurora son mejores para la carga de trabajo de escritura intensa. Realicé pruebas con muchos índices secundarios para asegurarme. Pero animo a cualquiera que se tome en serio la adopción de Aurora para que ejecute sus propios puntos de referencia.
Al menos, Aurora es mucho mejor que el Amazon RDS convencional para MySQL con almacenamiento EBS. Probablemente ahí es donde afirman que Aurora es 5 veces más rápida que MySQL. Pero Aurora no es más rápida que otras alternativas que probé y, de hecho, no puede igualar:
-
MySQL Server me instalé en instancias EC2 usando almacenamiento local, especialmente instancias i3 con NVMe conectado localmente. Entiendo que el almacenamiento de instancias no es confiable, por lo que sería necesario ejecutar nodos redundantes.
-
Yo mismo instalé MySQL Server en hosts físicos en nuestro centro de datos, utilizando almacenamiento SSD de conexión directa.
El valor de usar Aurora como una base de datos en la nube administrada no se trata solo del rendimiento. También cuenta con monitoreo automatizado, copias de seguridad, conmutación por error, actualizaciones, etc.
