Aus meiner Erfahrung ist Amazon Aurora ungeeignet, um eine Datenbank mit hohem Schreibverkehr zu betreiben. Zumindest in seiner Implementierung um 2017. Vielleicht wird es im Laufe der Zeit besser.
Ich habe Anfang 2017 an einigen Benchmarks für eine schreibintensive Anwendung gearbeitet, und wir haben festgestellt, dass RDS (nicht Aurora) Aurora in Bezug auf die Schreibleistung angesichts unserer Anwendung und Datenbank weit überlegen war. Grundsätzlich war Aurora zwei Größenordnungen langsamer als RDS. Die Behauptungen von Amazon über die hohe Leistung von Aurora sind anscheinend völliger Marketing-Bullshit.
Im November 2016 nahm ich an der Amazon re:Invent-Konferenz in Las Vegas teil. Ich habe versucht, einen sachkundigen Aurora-Ingenieur zu finden, der meine Fragen zur Leistung beantwortet. Alles, was ich finden konnte, waren Junior-Ingenieure, denen befohlen wurde, die Behauptung zu wiederholen, dass Aurora auf magische Weise 5-10x schneller als MySQL ist.
Im April 2017 nahm ich an der Percona Live-Konferenz teil und sah eine Präsentation über die Entwicklung einer Aurora-ähnlichen verteilten Speicherarchitektur unter Verwendung von Standard-MySQL mit CEPH für eine verteilte Open-Source-Speicherschicht. Hier gibt es ein Webinar zum gleichen Thema:https://www.percona. com/resources/webinars/mysql-and-ceph , präsentiert von Yves Trudeau, dem Ingenieur, den ich auf der Konferenz sprechen sah.
Was bei der Verwendung von MySQL mit CEPH klar wurde, war, dass die Ingenieure den MySQL-Änderungspuffer da es keine Möglichkeit gibt, Änderungen an sekundären Indizes zwischenzuspeichern und gleichzeitig den Speicher zu verteilen. Dies führte zu enormen Leistungsproblemen bei Schreibvorgängen in Tabellen mit sekundären (nicht eindeutigen) Indizes.
Dies stimmte mit den Leistungsproblemen überein, die wir beim Benchmarking unserer Anwendung mit Aurora festgestellt haben. Unsere Datenbank hatte viele Sekundärindizes.
Wenn Sie also Aurora unbedingt für eine Datenbank mit hohem Schreibverkehr verwenden müssen, empfehle ich Ihnen, als Erstes alle Ihre sekundären Indizes zu löschen.
Offensichtlich ist dies ein Problem, wenn die Indizes benötigt werden, um einige Ihrer Abfragen zu optimieren. Beide SELECT-Abfragen natürlich, aber auch einige UPDATE- und DELETE-Abfragen können Sekundärindizes verwenden.
Eine Strategie könnte darin bestehen, eine Nicht-Aurora-Read Replica Ihres Aurora-Clusters zu erstellen und die sekundären Indizes nur in der Read Replica zu erstellen, um Ihre SELECT-Abfragen zu unterstützen. Ich habe das noch nie gemacht, aber anscheinend ist es möglich, laut https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Dies hilft jedoch immer noch nicht in Fällen, in denen Ihre UPDATE/DELETE-Anweisungen sekundäre Indizes benötigen. Ich habe keinen Vorschlag für dieses Szenario. Sie könnten Pech haben.
Meine Schlussfolgerung ist, dass ich Aurora nicht für eine schreibintensive Anwendung verwenden würde. Vielleicht ändert sich das in Zukunft.
Aktualisierung April 2021:
Seit ich das oben Gesagte geschrieben habe, habe ich Sysbench-Benchmarks gegen Aurora Version 2 ausgeführt. Ich kann die spezifischen Zahlen nicht teilen, aber ich komme zu dem Schluss, dass die aktuellen Aurora-Verbesserungen besser für schreiblastige Arbeitslasten geeignet sind. Ich habe Tests mit vielen sekundären Indizes durchgeführt, um sicherzugehen. Aber ich ermutige jeden, der es ernst meint, Aurora zu übernehmen, seine eigenen Benchmarks durchzuführen.
Zumindest ist Aurora viel besser als herkömmliches Amazon RDS für MySQL mit EBS-Speicher. Das ist wahrscheinlich der Punkt, an dem sie behaupten, Aurora sei 5x schneller als MySQL. Aber Aurora ist nicht schneller als einige andere Alternativen, die ich getestet habe, und kann tatsächlich nicht mithalten:
-
MySQL Server habe ich selbst auf EC2-Instances mit lokalem Speicher installiert, insbesondere i3-Instances mit lokal angeschlossenem NVMe. Soweit ich weiß, ist Instanzspeicherung nicht zuverlässig, daher müssten redundante Knoten ausgeführt werden.
-
MySQL Server wurde von mir auf physischen Hosts in unserem Rechenzentrum installiert, wobei direkt angeschlossener SSD-Speicher verwendet wurde.
Der Wert der Verwendung von Aurora als verwaltete Cloud-Datenbank liegt nicht nur in der Leistung. Es verfügt auch über eine automatische Überwachung, Backups, Failover, Upgrades usw.
