D'après mon expérience, Amazon Aurora n'est pas adapté à l'exécution d'une base de données avec un trafic d'écriture important. Au moins dans sa mise en œuvre vers 2017. Peut-être que cela s'améliorera avec le temps.
Plus tôt en 2017, j'ai travaillé sur des tests de performances pour une application lourde en écriture, et nous avons constaté que RDS (non-Aurora) était de loin supérieur à Aurora en termes de performances d'écriture, compte tenu de notre application et de notre base de données. Fondamentalement, Aurora était deux ordres de grandeur plus lent que RDS. Les affirmations d'Amazon sur les hautes performances d'Aurora sont apparemment des conneries entièrement axées sur le marketing.
En novembre 2016, j'ai assisté à la conférence Amazon re:Invent à Las Vegas. J'ai essayé de trouver un ingénieur Aurora compétent pour répondre à mes questions sur les performances. Tout ce que j'ai pu trouver, ce sont des ingénieurs juniors qui avaient reçu l'ordre de répéter l'affirmation selon laquelle Aurora est magiquement 5 à 10 fois plus rapide que MySQL.
En avril 2017, j'ai assisté à la conférence Percona Live et j'ai vu une présentation sur la façon de développer une architecture de stockage distribué de type Aurora en utilisant MySQL standard avec CEPH pour une couche de stockage distribué open source. Il y a un webinaire sur le même sujet ici :https://www.percona. com/resources/webinaires/mysql-et-ceph , co-présenté par Yves Trudeau, l'ingénieur que j'ai vu parler à la conférence.
Ce qui est devenu clair à propos de l'utilisation de MySQL avec CEPH, c'est que les ingénieurs ont dû désactiver le Tampon de modification MySQL car il n'y a aucun moyen de mettre en cache les modifications apportées aux index secondaires, tout en répartissant également le stockage. Cela provoquait d'énormes problèmes de performances pour les écritures dans les tables qui avaient des index secondaires (non uniques).
Cela correspondait aux problèmes de performances que nous avons constatés lors de l'analyse comparative de notre application avec Aurora. Notre base de données comportait de nombreux index secondaires.
Donc, si vous devez absolument utiliser Aurora pour une base de données qui a un trafic d'écriture élevé, je vous recommande de commencer par supprimer tous vos index secondaires.
Évidemment, c'est un problème si les index sont nécessaires pour optimiser certaines de vos requêtes. Les deux requêtes SELECT bien sûr, mais aussi certaines requêtes UPDATE et DELETE peuvent utiliser des index secondaires.
Une stratégie peut consister à créer un réplica en lecture non-Aurora de votre cluster Aurora et à créer les index secondaires uniquement dans le réplica en lecture pour prendre en charge vos requêtes SELECT. Je n'ai jamais fait cela, mais apparemment c'est possible, selon https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Mais cela n'aide toujours pas les cas où vos instructions UPDATE/DELETE ont besoin d'index secondaires. Je n'ai aucune suggestion pour ce scénario. Vous n'aurez peut-être pas de chance.
Ma conclusion est que je ne choisirais pas d'utiliser Aurora pour une application lourde en écriture. Peut-être que cela changera à l'avenir.
Mise à jour avril 2021 :
Depuis que j'ai écrit ce qui précède, j'ai exécuté des benchmarks sysbench avec Aurora version 2. Je ne peux pas partager les chiffres spécifiques, mais je conclus que les améliorations actuelles d'Aurora sont meilleures pour les charges de travail lourdes en écriture. J'ai fait des tests avec beaucoup d'index secondaires pour m'en assurer. Mais j'encourage toute personne désireuse d'adopter Aurora à exécuter ses propres tests de performance.
Au moins, Aurora est bien meilleur qu'Amazon RDS classique pour MySQL utilisant le stockage EBS. C'est probablement là qu'ils prétendent qu'Aurora est 5 fois plus rapide que MySQL. Mais Aurora n'est pas plus rapide que certaines autres alternatives que j'ai testées, et ne peut en fait pas correspondre :
-
MySQL Server s'est installé sur des instances EC2 en utilisant un stockage local, en particulier des instances i3 avec NVMe connecté localement. Je comprends que le stockage d'instance n'est pas fiable, il faudrait donc exécuter des nœuds redondants.
-
MySQL Server s'est installé sur des hôtes physiques dans notre centre de données, en utilisant un stockage SSD à connexion directe.
La valeur de l'utilisation d'Aurora en tant que base de données cloud gérée n'est pas seulement une question de performances. Il a également une surveillance automatisée, des sauvegardes, un basculement, des mises à niveau, etc.
