Datenbank-Sharding-Diagramm: Shard Keys, Routing und Resharding

Sharding teilt eine Datenbank in mehrere auf, von denen jede einen Teil der Daten hält. Es ist die Antwort, wenn eine Maschine die Schreiblast nicht mehr bewältigt oder die Daten nicht mehr fasst, und zugleich eine der teuersten Entscheidungen im Leben eines Systems: Queries, Transaktionen, Schemaänderungen und der Betrieb werden alle schwieriger.

Dieser Artikel behandelt, wann sich Sharding lohnt, wie man einen Shard Key wählt, die wichtigsten Sharding-Verfahren, wie Queries den richtigen Shard finden und wie man ohne Ausfallzeit neu shardet. Das Diagramm zeigt eine per Hash geshardete Bestelldatenbank mit logischen Shards.

Erst alles andere versuchen

Prüfe vor dem Sharding die günstigeren Optionen, ungefähr in dieser Reihenfolge:

1. Queries und Indizes reparieren. Die meisten Probleme vom Typ „Datenbank zu langsam“ sind ein fehlender Index oder eine Query, die zu viel liest.
2. Vertikal skalieren. Eine größere Maschine mit mehr Speicher und schnelleren Platten verschafft vielen Systemen Jahre.
3. Read Replicas hinzufügen für leselastige Last; der Artikel zur Datenbankreplikation behandelt die Verzögerung, die damit einhergeht.
4. Heiße Lesezugriffe cachen, wie im Artikel zu Caching-Strategien.
5. Nach Funktion aufteilen: Analytics-, Such- oder Audit-Tabellen in eigene Datenbanken verschieben.

Sharde, wenn Schreiblast oder Datenmenge auch nach diesen Schritten übersteigen, was ein Primary bewältigen kann, und der Trend sagt, dass es schlimmer wird.

Den Shard Key wählen

Der Shard Key entscheidet, auf welchem Shard eine Zeile liegt. Ein guter Key hat drei Eigenschaften:

• Jede heiße Query enthält ihn. Wenn die Bestelllisten-Query nach Kunde filtert, lässt customer_id den Router sie an einen einzigen Shard schicken. Eine Query ohne den Key muss jeden Shard fragen.
• Er verteilt die Last gleichmäßig. Viele unterschiedliche Werte, und kein einzelner Wert erzeugt einen großen Anteil des Traffics.
• Er hält zusammengehörige Daten zusammen. Alle Bestellungen, Positionen und Zahlungen eines Kunden auf einem Shard bedeuten, dass Transaktionen und Joins lokal bleiben.

Bei einem mandantenfähigen SaaS ist meist die Tenant-ID der Key, bei einer Consumer-App die Nutzer- oder Kunden-ID. Vorsicht bei Keys, die gut aussehen, aber Last bündeln, etwa ein Zeitstempel (alle neuen Writes landen auf einem Shard) oder ein Ländercode (ein Land dominiert).

Range, Hash oder Directory

Ein verbreiteter Hybrid: Hashe den Key auf eine feste Zahl logischer Shards (etwa 1.024) und führe ein kleines Directory, das logische Shards physischen Hosts zuordnet. Keys wandern nie zwischen logischen Shards; nur ganze logische Shards wandern zwischen Hosts. Das Engineering-Team von Instagram beschrieb diesen Ansatz 2012, mit Tausenden logischer Shards auf weit weniger Datenbankservern.

Queries routen

Irgendetwas muss wissen, wo jeder Key liegt:

• In der Anwendung, über eine Bibliothek, die den Key hasht und den Host nachschlägt. Einfach, aber jeder Service und jede Sprache braucht dieselbe Logik.
• In einem Proxy zwischen Anwendung und Datenbanken. Vitess macht das für MySQL mit seinem VTGate-Proxy, und Citus macht es für Postgres über einen Koordinatorknoten.

In beiden Fällen gilt: Cache die Shard-Map und lade sie neu, wenn sie sich ändert. Eine veraltete Map während eines Umzugs ist der klassische Resharding-Bug: Ein Router schreibt nach dem Cutover auf den alten Host, und die Zeile fehlt still auf dem neuen. Versioniere die Map und lehne Writes mit einer alten Version ab. Queries ohne Shard Key werden an alle Shards verteilt und die Ergebnisse zusammengeführt; das funktioniert für seltene Admin-Aufgaben und scheitert als normaler Zugriffsweg.

Resharding ohne Ausfallzeit

Mit logischen Shards bedeutet mehr Kapazität, einige logische Shards auf einen neuen Host zu verschieben:

1. Kopiere die Daten der logischen Shards auf den neuen Host, während der alte weiter bedient.
2. Streame laufende Änderungen per Replikation der Datenbank oder Change Data Capture, bis die Kopie aufgeholt hat.
3. Blockiere kurz die Writes für diese logischen Shards, lass die letzten Änderungen ankommen, aktualisiere die Shard-Map und mach weiter.
4. Prüfe, dann lösche die verschobenen Daten vom alten Host.

Vitess und Citus automatisieren Varianten dieses Ablaufs. Probe ihn, bevor du ihn brauchst; zum ersten Mal unter Last neu zu sharden ist ein schlechter Tag.

IDs, die über Shards hinweg funktionieren

Eine Sequence pro Datenbank vergibt auf jedem Shard dieselben IDs. Nutze IDs, die ohne Koordination eindeutig sind: UUIDs (Version 7 hält sie grob zeitlich geordnet, was Indizes schont) oder 64-Bit-IDs im Stil von Snowflake, die einen Zeitstempel, eine Shard- oder Maschinennummer und einen Zähler kombinieren. Die logische Shard-Nummer in die ID einzubetten hat einen Bonus: Mit nur einer Bestell-ID weiß der Router, wo er suchen muss, ohne jemanden zu fragen.

Das Architekturdiagramm

So liest du es:

• Links: Der Bestellservice schickt jede Query mit einer Kunden-ID an den Shard-Router.
• Mitte: Der Router hasht die Kunden-ID auf einen von 1.024 logischen Shards und findet den Host in der gecachten Shard-Map (gestrichelt).
• Rechts: Vier Postgres-Hosts halten je 256 logische Shards. Host 4 verschiebt seine obere Hälfte auf einen neuen Host 5, der laufende Resharding-Schritt.
• Oben rechts: Kundenübergreifende Reports lesen ein Analytics-Warehouse, das per Change Data Capture befüllt wird, sodass sie nie über Shards verteilt werden.
• Der Markdown-Block listet die Regeln, an die sich jeder halten muss, der Queries schreibt.

Die Kosten, die du akzeptierst

Das Architekturdiagramm für mandantenfähiges SaaS zeigt die Variante mit einem Shard pro Mandant, bei der die folgenden Kompromisse pro Mandant gelten.

• Shard-übergreifende Transaktionen werden zu verteilten Transaktionen oder Sagas. Entwirf so, dass sie selten sind.
• Eindeutigkeitsbedingungen über Shards hinweg brauchen ein globales ID-Schema statt einer Sequence pro Datenbank.
• Schemaänderungen laufen auf jedem Shard, also brauchen Migrationen Tooling und müssen teilweise Fertigstellung tolerieren.
• Der Betrieb vervielfacht sich: Backups, Upgrades und Monitoring für jeden Shard.

Was in ein Sharding-Diagramm gehört

• Der Shard Key und das Verfahren (Hash, Range, Directory).
• Logische und physische Shards, falls du sie trennst.
• Wo das Routing passiert: Bibliothek, Proxy oder Koordinator.
• Der Weg für Queries ohne Key, etwa ein Warehouse oder ein Suchindex.
• Der Resharding-Zustand, wenn gerade ein Umzug läuft.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem C4-Modell-Pack Container-Nodes für den Service und den Shard-Router hinzu und eine Datenbank für die Shard-Map.
3. Füge aus dem Daten-Pack Postgres-Nodes für die Hosts hinzu, beschriftet mit ihren logischen Shard-Bereichen, plus einen für den neuen Host.
4. Füge aus dem Daten-Pack ein Datenlager für Reports hinzu, gespeist über eine gepunktete CDC-Kante.
5. Zeichne den Resharding-Umzug als gestrichelte Kante und füge einen Markdown-Block aus dem Basis-Pack mit den Sharding-Regeln hinzu.

Das Beispiel nutzt 10 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen Sharding und Partitionierung? Partitionierung bedeutet meist, eine Tabelle innerhalb eines Datenbankservers aufzuteilen. Sharding verteilt die Daten auf mehrere Server, sodass jeder nur einen Teil hält.

Wie wähle ich einen Shard Key? Nimm das Attribut, nach dem jede heiße Query filtert und das zusammengehörige Daten zusammenhält, mit vielen unterschiedlichen Werten und gleichmäßiger Last, etwa eine Tenant- oder Kunden-ID.

Was sind logische Shards? Eine feste, große Zahl von Hash-Buckets, die auf weniger physische Server abgebildet werden. Ganze logische Shards zwischen Servern zu verschieben vermeidet, beim Erweitern jeden Key neu zu hashen.

Wie führe ich Queries über alle Shards aus? Vermeide sie auf heißen Pfaden. Für Reports repliziere die Daten in ein Warehouse; für seltene Admin-Aufgaben ist eine verteilte Query über den Router akzeptabel.

Wann sollte ich sharden? Wenn Schreiblast oder Datenmenge übersteigen, was ein gut getunter einzelner Primary bewältigen kann, und der Trend anhält, nach Indizierung, vertikaler Skalierung, Replikas, Caching und funktionaler Aufteilung.

Kostenlos starten — ein Seat, keine Kreditkarte.