We horen deze vraag veel:hoe zit het met Amazon Aurora? Bij het bepalen van de best beheerde databaseservice voor uw organisatie, zijn er meerdere factoren waarmee u rekening moet houden - en een rode draad door al deze factoren is hoeveel controle u nodig hebt. Amazon werpt veel gewicht achter zijn Aurora DBaaS-aanbod, maar - afhankelijk van uw vereisten en prioriteiten - kan het kiezen van een database zoals MariaDB op Amazon EC2 of een andere, niet-Amazon-service beter bij u passen.
Hier zijn vier dingen die je waarschijnlijk niet wist over Amazon Aurora.
Een verouderde, verouderde database
Amazon Aurora 2.x gebruikt een oude versie van MySQL 5.7.
Aurora 2.0.1 werd uitgebracht in februari 2018, gebruikmakend van MySQL 5.7.12, zelf uitgebracht in april 2016. Aurora 2.x gebruikt nog steeds een oude versie van MySQL 5.7. Amazon publiceert echter niet langer de onderhoudsversie die het gebruikt. Dit zou geen verrassing moeten zijn. Er zijn meer dan een dozijn MySQL-onderhoudsreleases geweest sinds 5.7.12. Hoeveel van de bugfixes die erin zitten, heeft Amazon gebackporteerd? 17... van de honderden.
- Aurora 2.02.0:Bug #22833364
- Aurora 2.02.3:Bugs #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.0:Bugs #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.3:Bugs #25361251, #26734162, #27460607, #22343910, #23074801, #25287633
- Aurora 2.04.0:Bug #26225783
- Aurora 2.04.2:Bug #24829050
Als je een nieuwe database zou kunnen kiezen, zou je er dan een kiezen die meer dan drie jaar geleden is uitgebracht, een die drie jaar aan bugfixes, beveiligingspatches, verbeteringen en nieuwe functies mist?
Vereiste downtime en onderbreking
Aurora heeft downtime nodig voor onderhoud. Hoewel een deel van het onderhoud optioneel is en voor onbepaalde tijd kan worden uitgesteld, is ander onderhoud, zoals beveiligings- en betrouwbaarheidspatches, niet alleen vereist, maar resulteert dit ook in uitvaltijd tijdens een willekeurig onderhoudsvenster van 30 minuten. Verder resulteren database-upgrades (d.w.z. updates van de database-engine) in 20-30 seconden downtime omdat ze tegelijkertijd op elke database-instantie binnen een cluster worden uitgevoerd.
MariaDB Platform, aan de andere kant, ondersteunt doorlopende upgrades met elegante omschakelingen, waardoor DBA's on-demand onderhoud zonder downtime kunnen uitvoeren.
Naast onderhoud en upgrades, kan Aurora tot twee minuten duren om een automatische failover uit te voeren, wat resulteert in meer downtime. Verder resulteert automatische failover in verbroken verbindingen, sessies en transacties tijdens de vlucht.
MariaDB Platform ondersteunt, in tegenstelling tot Aurora, multi-master clustering om downtime als gevolg van een onverwachte storing te elimineren. Daarnaast ondersteunt MariaDB Platform verbindingsmigratie, sessieherstel en transactieherhaling om ervoor te zorgen dat onverwachte storingen geen gevolgen hebben voor applicaties.
Gebrek aan bedrijfsbeveiliging
Aurora mist veel van de zakelijke beveiligingsfuncties die van moderne databases worden verwacht, waaronder een database-firewall, dynamische gegevensmaskering, rollen, sleutelrotatie en TLS 1.3.
Aurora ondersteunt de Amazon Key Management Service, maar ondersteunt geen sleutelrotatie voor een database-instantie. In plaats daarvan kan een sleutelalias worden gebruikt om de sleutel voor nieuwe database-instances te wijzigen. Als zodanig, zelfs als een nieuwe sleutel wordt toegevoegd, zullen bestaande database-instanties gegevens blijven versleutelen en ontsleutelen met behulp van de oude sleutel.
MariaDB Platform ondersteunt sleutelrotatie en wanneer een nieuwe sleutel wordt toegevoegd, kan het de gegevens automatisch opnieuw versleutelen met de nieuwe sleutel, waardoor de oude sleutel kan worden weggegooid.
Aurora mist de krachtige database-firewall en dynamische database-maskeringsfuncties die beschikbaar zijn in MariaDB Platform, en omdat Aurora is gebaseerd op een oude versie van MySQL, mist het ook rollen. Verder is het beperkt tot TLS 1.0, 1.1 en 1.2.
De kleinste gemene deler
Aurora biedt gebruikers een kale database die is gemaakt met behulp van een cookie-cutter-sjabloon die bedoeld is om aan de kleinste gemene deler te voldoen. Terwijl MariaDB Platform lees-, schrijf- en opslagcapaciteit kan uitbreiden met transparante sharding via de Spider-opslagengine, of profiteren van voor schrijven en ruimte geoptimaliseerde opslag op SSD's via de MyRocks-opslagengine (ontwikkeld door Facebook), heeft Aurora geen van beide. Het is beperkt tot de InnoDB-opslagengine.
Dan is er gedistribueerde, kolomvormige opslag en massaal parallelle verwerking met MariaDB ColumnStore. Het is nog een andere opslagengine die niet beschikbaar is in Aurora. Hoewel Amazon zou aanraden om Aurora te gebruiken voor transactieverwerking en Redshift voor analyse, kunnen beide worden gedaan met MariaDB Platform, waardoor hybride transactie/analytische verwerking (HTAP) mogelijk wordt.
Naast voor werkbelasting geoptimaliseerde opslag-engines, zijn er veel functies beschikbaar in MariaDB Platform die niet te vinden zijn in Aurora, waaronder Oracle Database-compatibiliteit (d.w.z. PL/SQL), temporele tabellen, point-in-time rollback, streaming change-data-capture , een Apache Kafka-producent, transparante lees-/schrijfsplitsing, controlebeperkingen, standaardwaarde-expressies, algemene tabeluitdrukkingen, set-operators, vensterfuncties, door de gebruiker gedefinieerde functies (scalair, aggregatie en venster), reeksen en meer.
Amazons eigen ervaring met Aurora illustreert het belang van de bovenstaande overwegingen. Kort na de verhuizing van een aantal van hun databases naar Aurora, ondervond Amazon wijdverbreide storingen en andere databaseproblemen tijdens Prime Day 2018. Nu Prime Day 2019 nadert, wensen we Amazon veel succes!