Cloud-Instanzvergleich

Dieselbe Ausstattung auf drei Clouds — und warum das nicht dasselbe Angebot ist

Die Wahl einer Datenbankinstanz beginnt meist mit einer Ausstattung — so viele vCPU, so viel Speicher — und endet bei dem Namen aus der Anbieterliste, der oberhalb dieser Untergrenze am günstigsten ist. Dieses Werkzeug schlägt das bei AWS RDS, Google Cloud SQL und Azure Flexible Server gleichzeitig nach und ergänzt die Zahl, die jene Listen auslassen: wie viele Verbindungen Sie tatsächlich öffnen dürfen.

So wird gerechnet

• Nimmt eine Mindest-vCPU-Zahl und eine Mindestspeichergröße und findet je Cloud die kleinste Instanz, die beides erfüllt.
• Zeigt zwei größere Optionen daneben, damit Sie sehen, was der nächste Schritt an Ressourcen kostet.
• Nennt neben jeder Ausstattung das Verbindungslimit, berechnet nach der Regel des jeweiligen Anbieters.
• Markiert die kleinste Übereinstimmung ausdrücklich, denn die erste Zeile einer Anbietertabelle ist selten die gesuchte.

kleinste Uebereinstimmung = Minimum ueber Instanzen mit
    vcpu >= Ihr_Minimum  UND  Speicher >= Ihr_Minimum
  sortiert nach vcpu, dann Speicher

die Verbindungen stammen aus der veroeffentlichten Regel
jedes Anbieters, nicht aus einem gemeinsamen Standard

Rechenbeispiel

Ein Dienst, der mindestens 8 vCPU und 32 GiB braucht, über die drei Clouds hinweg.

1. AWS: db.m5.2xlarge — 8 vCPU, 32 GiB, rund 3.324 Verbindungen
2. Azure: B8ms — 8 vCPU, 32 GiB, 3.437 Verbindungen
3. Google Cloud SQL: db-custom-8-53248 — 8 vCPU, 52 GiB, 600 Verbindungen
4. die Ausstattungen stimmen auf zwei Clouds fast überein; die Verbindungslimits überhaupt nicht

AWS und Azure landen auf praktisch identischer Hardware mit praktisch identischer Verbindungsobergrenze. Cloud SQL gibt Ihnen 20 GiB mehr Speicher und etwa ein Fünftel der Verbindungen. Ist Ihr Dienst verbindungslastig statt speicherlastig, ist das bereits die ganze Entscheidung.

Das Ergebnis lesen

• Cloud SQL akzeptiert beliebige benutzerdefinierte Maschinenzuschnitte, die für Google gezeigte kleinste Übereinstimmung ist also die kleinste in diesem Katalog, nicht die kleinste existierende. Ein Zuschnitt mit exakt 8 vCPU und 32 GiB ist dort verfügbar; die Spalte weist darauf hin, und die Google-Zahl ist als Stichprobe zu lesen.
• Die kleinste Übereinstimmung ist manchmal burstfähig, und burstfähig ist nicht gleichwertig. Azures B-Serie und AWS' t-Klasse sammeln im Leerlauf CPU-Guthaben und drosseln, wenn es aufgebraucht ist — passend für eine Entwicklungsdatenbank oder ein sprunghaftes internes Werkzeug, schlecht für alles mit dauerhafter Grundlast.
• vCPU-Zahlen sind zwischen Clouds nicht unbesehen vergleichbar. AWS-Graviton-Instanzen zählen physische Kerne, x86-Klassen zählen Hyperthreads — 8 vCPU Graviton und 8 vCPU x86 sind also nicht dieselbe Rechenleistung. Innerhalb einer Cloud belastbar vergleichen, zwischen Clouds nur grob.
• Verglichen werden Ausstattung und Verbindungsgrenze, nicht der Preis. Reservierte Kapazität, Committed-Use-Rabatte und Sparpläne verschieben die realen Kosten um ein Vielfaches, und zwar je Cloud unterschiedlich — ein Ausstattungsvergleich ist der Anfang einer Entscheidung, nicht ihr Ende.
• Für die meisten Datenbanken zählt Speicher mehr als vCPU, denn er bestimmt sowohl den Cache, der Abfragen von der Platte fernhält, als auch — bei AWS und Azure — die Verbindungsobergrenze selbst. Wenn unklar ist, welche Untergrenze steigen soll: den Speicher.

Häufige Fragen

Warum zeigt Google mehr Speicher als angefragt?

Weil der Katalog hier gängige Cloud-SQL-Zuschnitte abtastet statt alle möglichen aufzuzählen, und der nächstgelegene abgetastete Zuschnitt über Ihrer Untergrenze überschießen kann. Cloud SQL unterstützt benutzerdefinierte Zuschnitte, Sie können den gewünschten Speicher also meist exakt anfordern — lesen Sie die Google-Spalte als Hinweis.

Ist die kleinste Übereinstimmung immer die richtige Wahl?

Sie ist das Günstigste oberhalb Ihrer Untergrenze — richtig nur, wenn die Untergrenze richtig ist. Setzen Sie sie aus gemessener Nutzung plus Reserve für Wachstum und Failover an, nicht aus der aktuellen Spitze: Eine exakt auf die heutige Spitze bemessene Instanz hat für die morgige keinen Platz.

Warum unterscheiden sich die Verbindungslimits bei gleichem Speicher so stark?

Weil sie von verschiedenen Regeln mit verschiedenen Absichten gesetzt werden. AWS und Azure leiten das Limit aus dem Speicher ab und landen im selben Bereich. Google setzt es über Speicherstufen deutlich niedriger an, in der Annahme, verbindungslastige Lasten nutzten einen Pooler. Keine der drei ist falsch; sie werden unterschiedlich durchgesetzt, und das betrifft Sie.