0Pricing
SQL Academy · Lektion

Sharding-Strategien: Bereich, Hash, Verzeichnis

Vergleichen Sie bereichs-, hash- und verzeichnisbasiertes Sharding und wählen Sie einen stabilen Shard-Schlüssel, der die Last ausgewogen verteilt.

Sharding-Strategien: Bereich, Hash, Verzeichnis ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist Sharding?

Eine logische Datenbank wird auf mehrere physische Server („Shards“) aufgeteilt, wobei jeder eine Teilmenge der Daten enthält. Dies geschieht, wenn ein einzelner Server die Workload nicht mehr bewältigen kann.

Sharding ≠ Replikation

  • Replikation – dieselben Daten auf mehreren Servern (für HA und Leseskalierung)
  • Sharding – unterschiedliche Daten auf unterschiedlichen Servern (für Schreibskalierung und mehr Kapazität)

Oft kombinieren Sie beides: Jeder Shard wird für HA repliziert.

Drei Sharding-Strategien

  • Bereich – Sharding nach Wertebereich (id 1-1M auf Shard A, 1M-2M auf Shard B)
  • Hash – den Sharding-Schlüssel hashen, modulo N
  • Verzeichnis – eine separate Tabelle ordnet Schlüssel → Shard zu

Bereichs-Sharding

Einfach und gut für Zeitreihen sowie aufsteigende IDs geeignet. Risiko: Heiße Shards, wenn der gesamte Datenverkehr auf aktuelle Daten entfällt.

-- Conceptually:
-- Shard A: user_id 1 - 1,000,000
-- Shard B: user_id 1,000,001 - 2,000,000
-- Shard C: user_id 2,000,001 - 3,000,000

Hash-Sharding

Standardmäßig gleichmäßige Verteilung. Das Hinzufügen von Shards ist schwierig (beim erneuten Sharding werden alle Schlüssel verschoben):

-- shard_id = hash(user_id) % N
-- N=4: any user_id evenly distributed across 4 shards

Verzeichnis-Sharding

Eine Nachschlagetabelle ordnet jeden Schlüssel seinem Shard zu:

CREATE TABLE shard_routing (
  user_id BIGINT PRIMARY KEY,
  shard_id INT NOT NULL
);

-- Looking up a user costs a directory query first; cache it.

Konsistentes Hashing

Modulo-Hashing ist beim Hinzufügen von Shards unflexibel. Konsistentes Hashing minimiert die Anzahl der Schlüssel, die verschoben werden müssen:

-- Each shard owns a ring segment.
-- Adding a new shard moves only ~1/N of the keys.

Auswahl eines Sharding-Schlüssels

Der Sharding-Schlüssel bestimmt alles. Gute Sharding-Schlüssel:

  • Verteilen Daten gleichmäßig
  • Sind in den meisten Abfragen vorhanden (vermeidet Fan-out über mehrere Shards)
  • Sind unveränderlich (oder ändern sich nur selten)
<p>Common picks: user_id, tenant_id, customer_id. Avoid: timestamps for write-heavy workloads (creates hot shards).</p>

Ein Mandant pro Shard

Mandantenfähige SaaS-Anwendung: Jeder Mandant liegt auf einem dedizierten Shard. Das ist einfach nachzuvollziehen und ermöglicht eine leichte Isolation besonders aktiver Mandanten.

Design für erneutes Sharding

Planen Sie zukünftiges erneutes Sharding von Anfang an ein:

  • Verwenden Sie virtuelle Shards (z. B. 1024 logische Shards, die physischen Shards zugeordnet werden)
  • Ermöglichen Sie die einfache Migration eines logischen Shards auf einen anderen physischen Server
  • Vermeiden Sie Anwendungscode, der die Anzahl der Shards fest einprogrammiert

Abfragen über mehrere Shards

Das schwierigste Problem. JOINs und Berichte über mehrere Shards erfordern Fan-out- und Aggregationslogik in der Anwendung. Dies wird in der nächsten Lektion behandelt.

Transaktionen über mehrere Shards

Atomare Transaktionen über mehrere Shards benötigen ein Zwei-Phasen-Commit (2PC) oder Sagas. Die übliche Empfehlung lautet: Entwerfen Sie das System so, dass Transaktionen innerhalb eines Shards bleiben.

Zusammenfassung

Drei Strategien – wählen Sie abhängig von der Form Ihres Datenverkehrs.

  • Bereich – einfach, Risiko heißer Shards
  • Hash – gleichmäßig, aber unflexibel
  • Verzeichnis – flexibel, verursacht aber zusätzliche Latenz
  • Konsistentes Hashing für ein schrittweises erneutes Sharding

Kurze Überprüfung

Sie partitionieren eine users-Tabelle per Hash von user_id. Sie wechseln von 4 auf 5 Shards. Wie viele Schlüssel müssen verschoben werden?

Häufig gestellte Fragen

Ist die Lektion „Sharding-Strategien: Bereich, Hash, Verzeichnis“ kostenlos?

Ja — der vollständige Text von „Sharding-Strategien: Bereich, Hash, Verzeichnis“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Sharding-Strategien: Bereich, Hash, Verzeichnis“?

Vergleichen Sie bereichs-, hash- und verzeichnisbasiertes Sharding und wählen Sie einen stabilen Shard-Schlüssel, der die Last ausgewogen verteilt. Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Academy zu starten?

Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Sharding-Strategien: Bereich, Hash, Verzeichnis“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?

Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Sharding-Strategien: Bereich, Hash, Verzeichnis
  2. Shard-übergreifende Abfragen: Das schwierige Problem
  3. Citus und verteiltes Postgres
  4. Wann Sie NICHT sharden sollten
← Zurück zu SQL Academy