Vitess für horizontale MySQL-Skalierung: Sharding ohne Anwendungsumbau

1. Wann klassisches MySQL an die Grenzen vertikaler Skalierung stößt

Solange Datenvolumen und Traffic wachsen, lässt sich ein MySQL-Server zunächst vertikal skalieren: mehr Arbeitsspeicher für einen größeren Buffer Pool, schnellere NVMe-Speicher, mehr CPU-Kerne. Diese Strategie funktioniert gut, hat aber eine harte Obergrenze, die durch die größte verfügbare Hardware-Instanz vorgegeben ist, und irgendwann steigen die Kosten für die nächstgrößere Instanz überproportional zum tatsächlichen Nutzen.

Read-Replicas lindern reine Leselast, helfen aber nicht bei Schreiblast, denn alle Schreibzugriffe müssen weiterhin über den einen primären Server laufen. Wenn selbst ein großzügig dimensionierter Primary bei Schreibdurchsatz oder Verbindungszahl an seine Grenzen stößt, bleibt als nächster Schritt nur die horizontale Skalierung, also die Aufteilung der Daten auf mehrere unabhängige MySQL-Instanzen, das sogenannte Sharding.

2. Was Vitess ist: Herkunft und Architekturüberblick

Vitess wurde ursprünglich bei YouTube entwickelt, um dessen MySQL-Infrastruktur horizontal skalierbar zu machen, und ist heute ein bei der Cloud Native Computing Foundation gegraduierter Open-Source-Standard für MySQL-Sharding. Statt Sharding-Logik in jede einzelne Anwendung einzubauen, kapselt Vitess sie vollständig in einer eigenen Infrastrukturschicht zwischen Anwendung und den tatsächlichen MySQL-Instanzen.

Die zentralen Bausteine sind VTGate als zustandsloser Query-Router, mit dem sich die Anwendung über das gewöhnliche MySQL-Protokoll verbindet, VTTablet als Vorschaltprozess vor jeder einzelnen MySQL-Instanz, der Verbindungspooling, Query-Rewriting und Health-Checks übernimmt, sowie ein Topology Service, meist etcd, in dem Metadaten zu Keyspaces und Shards abgelegt sind. Für Administration und Orchestrierung kommen zusätzlich vtctld und vtorc zum Einsatz.

3. Transparentes Sharding: wie die Anwendung weiterhin normales MySQL sieht

Aus Sicht der Anwendung ändert sich beim Einsatz von Vitess zunächst wenig: Verbindungen werden über einen MySQL-Treiber wie gewohnt aufgebaut, SQL-Abfragen werden in gewohnter Syntax formuliert und abgeschickt. VTGate empfängt diese Abfragen, konsultiert das VSchema, um zu bestimmen, auf welchem oder welchen Shards die relevanten Daten liegen, und leitet die Abfrage entsprechend an die zuständigen VTTablet-Instanzen weiter.

Bei Abfragen, die Daten aus mehreren Shards zusammenführen müssen, etwa eine Aggregation ohne expliziten Sharding-Key-Filter, führt VTGate ein sogenanntes Scatter-Gather durch: Die Abfrage wird an alle relevanten Shards parallel gesendet, und die Teilergebnisse werden anschließend zusammengeführt. Das funktioniert transparent, ist aber deutlich teurer als eine Abfrage, die dank passendem Sharding-Key gezielt nur einen einzigen Shard trifft.

4. Das VSchema-Konzept: Sharding-Keys und Vindexes

Das VSchema definiert pro Keyspace, ob eine Tabelle geshardet oder ungeshardet ist, und legt für geshardete Tabellen einen primären Vindex fest, eine Abbildungsfunktion, die aus dem Wert der Sharding-Spalte bestimmt, welchem Shard eine Zeile zugeordnet wird. Ein Hash-Vindex verteilt Werte beispielsweise gleichmäßig über alle Shards, unabhängig von der Verteilung der eigentlichen Werte.

Für Abfragen über Spalten, die nicht der primäre Sharding-Key sind, definiert man zusätzliche sekundäre Vindexes, häufig realisiert über eigene Lookup-Tabellen, die den Zusammenhang zwischen alternativer Spalte und Sharding-Key materialisieren. Ein gut entworfenes VSchema mit passenden Vindexes ist entscheidend dafür, dass möglichst viele Abfragen gezielt einzelne Shards treffen, statt teure Scatter-Gather-Operationen auszulösen.

-- Vereinfachtes VSchema-Fragment (JSON) für eine geshardete Tabelle
{
  "sharded": true,
  "vindexes": {
    "hash": { "type": "hash" }
  },
  "tables": {
    "sales_order": {
      "column_vindexes": [
        { "column": "customer_id", "name": "hash" }
      ]
    }
  }
}

5. Resharding ohne Downtime: wie Vitess Umverteilungen handhabt

Ein zentrales Versprechen von Vitess ist die Möglichkeit, die Anzahl der Shards nachträglich zu ändern, ohne die Anwendung offline zu nehmen. Über den Reshard-Workflow kopiert Vitess Daten aus den bestehenden Shards in eine neue Shard-Topologie, hält beide Zustände über VReplication synchron und schaltet den Traffic erst nach vollständigem Abgleich auf die neue Topologie um.

Auch das Verschieben einzelner Tabellen zwischen Keyspaces, etwa im Rahmen einer schrittweisen Migration von einer monolithischen zu einer geshardeten Struktur, funktioniert über denselben MoveTables-Mechanismus. Diese Fähigkeit, produktive Datenmengen im laufenden Betrieb umzuverteilen, ist einer der Hauptgründe, warum Teams überhaupt zu Vitess greifen, statt Sharding von Hand in der Anwendung zu implementieren.

6. Praktische Einordnung: ab welcher Größenordnung sich Vitess lohnt

Vitess entfaltet seinen Nutzen vor allem bei Datenmengen im Bereich mehrerer Terabyte oder Tabellen mit Milliarden Zeilen, bei denen selbst ein leistungsstarker Einzelserver mit den größten verfügbaren Instanztypen an Grenzen stößt, oder bei Abfragelasten von zehntausenden Queries pro Sekunde, die ein einzelner Primary nicht mehr sicher bedienen kann. Auch bei echten Multi-Tenant-Plattformen mit sehr vielen unabhängigen Mandanten kann Sharding nach Mandanten-ID sinnvoll sein.

Unterhalb dieser Größenordnung, also im Bereich weniger hundert Gigabyte bis niedriger einstelliger Terabyte mit moderater Schreiblast, lässt sich die gleiche Skalierung meist deutlich einfacher über einen gut getunten Primary mit mehreren Read-Replicas und gegebenenfalls einem Verbindungs-Proxy erreichen, ohne die betriebliche Komplexität von Vitess in Kauf nehmen zu müssen.

7. Komplexitätskosten: Betriebsaufwand und zusätzliche Abhängigkeiten

Der Betrieb von Vitess bringt spürbaren zusätzlichen Aufwand mit sich: Ein dediziertes Operations-Team muss VTGate, VTTablet-Instanzen, den Topology Service und die Orchestrierungswerkzeuge überwachen, aktualisieren und bei Störungen debuggen. In der Praxis wird Vitess häufig zusammen mit Kubernetes betrieben, meist über den offiziellen Vitess-Operator, was zusätzliches Kubernetes-Know-how im Team voraussetzt.

Auch auf Anwendungsseite entsteht Aufwand: Ein sorgfältig entworfenes VSchema mit passenden Vindexes ist Voraussetzung dafür, dass Abfragen effizient bleiben, und Änderungen am Schema oder an Zugriffsmustern erfordern häufig eine erneute Überarbeitung des VSchema. Diese Lernkurve sollte nicht unterschätzt werden, bevor man sich für Vitess entscheidet.

8. Magento-Kontext: wann Vitess eher nicht und wann doch infrage kommt

Die weit überwiegende Mehrheit der Magento-Shops bewegt sich mit Datenbankgrößen im Bereich weniger Gigabyte bis niedriger dreistelliger Gigabyte und Abfragelasten, die ein einzelner, gut getunter MySQL- oder Percona-Server samt Read-Replicas problemlos bedient. Für diese Fälle wäre Vitess ein deutlicher Overkill, der operative Komplexität ohne entsprechenden Nutzen hinzufügt.

Relevant wird Vitess dagegen für sehr große B2B-Marktplätze mit enormem Bestellvolumen oder für SaaS-Plattformen, die viele unabhängige Händler auf einer gemeinsamen Infrastruktur mit echtem Sharding nach Mandanten-ID betreiben, insbesondere wenn einzelne Mandanten selbst schon beträchtliche Datenmengen erzeugen und horizontale statt vertikale Skalierung wirtschaftlicher wird.

9. Alternativen zu Vitess: Read-Replicas, ProxySQL und Anwendungs-Sharding

Bevor man sich für Vitess entscheidet, lohnt sich der Blick auf günstigere Zwischenschritte: Read-Replicas mit Lesetrennung auf Anwendungsebene lösen viele Leselast-Probleme ohne jede Sharding-Komplexität. ProxySQL kann Verbindungspooling, Read-Write-Splitting und Query-Routing übernehmen, ohne dass Daten tatsächlich über mehrere unabhängige Instanzen verteilt werden müssen.

Manuelles Anwendungs-Sharding, etwa eine Aufteilung nach Website oder Store View bei Multi-Site-Magento-Installationen, kann in vielen Fällen ausreichen, ohne die generische, aber komplexe Sharding-Infrastruktur von Vitess einzuführen. Auch konsequente Archivierung alter Bestell- und Logdaten reduziert oft schon die effektive Datenmenge so weit, dass horizontale Skalierung gar nicht erst nötig wird.

-- Einfache Lesetrennung ohne Vitess: Read-Replica gezielt für Reports nutzen
-- Schreibverbindung (Primary)
INSERT INTO sales_order_grid (...) VALUES (...);

-- Report-Abfrage bewusst gegen Read-Replica
SELECT store_id, COUNT(*) AS orders
FROM sales_order_grid
WHERE created_at >= CURDATE() - INTERVAL 30 DAY
GROUP BY store_id;

10. Zusammenfassung

11. FAQ: Vitess in MySQL-Umgebungen: Das Wichtigste auf einen Blick