0Pricing
SQL Academy · Lektion

Shard-übergreifende Abfragen: Das schwierige Problem

Verstehen Sie, warum Shard-übergreifende Joins und Transaktionen das schwierigste Problem in verteilten Datenbanken sind, und lernen Sie Muster kennen, die sie minimieren.

Shard-übergreifende Abfragen: Das schwierige Problem ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 2 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.

Die Kosten des Shar­ding

Sharding skaliert Schreibvorgänge und Kapazität, macht aber Abfragen über mehrere Shards schmerzhaft: Jede Abfrage über mehrere Shards ist ein Fan-out.

Abfragen innerhalb eines Shards sind einfach

Wenn Ihr Sharding-Schlüssel in der WHERE-Klausel vorkommt, sendet der Router eine Abfrage an genau einen Shard:

-- shard_id = hash(user_id) % N
SELECT * FROM orders WHERE user_id = 42;
-- Router computes shard, sends one query, gets one result.

Fan-out-Abfragen

Ohne den Sharding-Schlüssel fragt der Router jeden Shard ab und führt die Ergebnisse zusammen:

-- WHERE status = 'paid' — no user_id
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100;
-- Must query all N shards, merge results, sort, take top 100.

Fan-out-Aggregationen

Für COUNT/SUM/AVG: Rufen Sie Teilergebnisse von jedem Shard ab und kombinieren Sie sie anschließend im Router oder in der Anwendung:

-- On each shard:
SELECT COUNT(*), SUM(total) FROM orders;

-- Aggregator:
final_count = SUM(counts), final_sum = SUM(sums)

-- AVG is trickier — need SUM and COUNT, can't average averages.

JOINs über mehrere Shards

Wenn beide Seiten nach demselben Schlüssel geshardet und somit gemeinsam platziert sind, bleibt der JOIN lokal auf dem Shard. Andernfalls ist er bei großer Skalierung praktisch unmöglich.

Referenztabellen (auf jedem Shard repliziert)

Kleine „Lookup“-Tabellen werden auf jeden Shard repliziert, sodass JOINs mit ihnen lokal bleiben. Citus nennt sie „reference tables“.

Muster über mehrere Shards vermeiden

Tricks beim Schemaentwurf:

  • Denormalisieren – duplizieren Sie übergeordnete Daten in den Shard mit den untergeordneten Daten
  • Verwenden Sie den Sharding-Schlüssel überall – auch wenn er scheinbar „nicht erforderlich“ ist
  • Berechnen Sie Berichte vorab in einer separaten Analytics-Datenbank

Seitennavigation über mehrere Shards

OFFSET 1000 LIMIT 10 über viele Shards ist katastrophal – jeder Shard muss 1010 Zeilen liefern. Verwenden Sie stattdessen Keyset-Pagination.

Verteilte Transaktionen

Ein Zwei-Phasen-Commit (2PC) koordiniert atomare Commits über mehrere Shards. Es ist langsam und bei einer Partition anfällig. Entwerfen Sie das System in der Praxis für „Saga“-Muster:

// Saga pattern (conceptual):
//   1. Local TX on shard A: mark as pending, log
//   2. RPC to shard B: do its part
//   3. Local TX on shard A: mark as committed
//   4. On failure: compensating transactions

Heiße Shards

Ein prominenter Benutzer oder ein virales Produkt – konzentrierter Datenverkehr auf einem Shard macht Ihre Skalierungsstrategie zunichte. Erkennen und teilen Sie den Shard (Sub-Sharding) oder verschieben Sie ihn.

Fremdschlüssel über mehrere Shards

RDBMS-Fremdschlüssel erstrecken sich nicht über mehrere Shards. Sie setzen die referenzielle Integrität in der Anwendung durch oder akzeptieren letztendliche Konsistenz für Beziehungen zwischen Shards.

Zusammenfassung

Sharding verlagert die Schwierigkeit von der „Skalierung von Schreibvorgängen“ hin zur „Gestaltung von Abfragen, die lokal auf einem Shard bleiben“.

  • Abfragen innerhalb eines Shards sind schnell
  • Fan-out ist langsam
  • Denormalisieren Sie, damit die Verarbeitung lokal bleibt
  • Referenztabellen für gemeinsam genutzte Dimensionen
  • Sagas statt 2PC

Kurze Überprüfung

Warum ist ein SELECT ohne Sharding-Schlüssel in der WHERE-Klausel bei einer geshardeten Datenbank teuer?

Häufig gestellte Fragen

Ist die Lektion „Shard-übergreifende Abfragen: Das schwierige Problem“ kostenlos?

Ja — der vollständige Text von „Shard-übergreifende Abfragen: Das schwierige Problem“ 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 „Shard-übergreifende Abfragen: Das schwierige Problem“?

Verstehen Sie, warum Shard-übergreifende Joins und Transaktionen das schwierigste Problem in verteilten Datenbanken sind, und lernen Sie Muster kennen, die sie minimieren. 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 2 von 4.

Wie lange dauert die Lektion „Shard-übergreifende Abfragen: Das schwierige Problem“?

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