Sharding und Replikation von Datenbanken

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Für iGaming-Plattformen, Traffic-Wachstum (Wetten, Einzahlungen, PSP-Webhooks, Spiele-Events) und Verfügbarkeitsanforderungen (≈99. 9–99. 99%) schnell an die Grenze einer einzelnen DB stoßen. Die Replikation bietet horizontale Leseskalierung und Fehlertoleranz. Sharding - horizontale Skalierung von Datensatz und Daten. Der Schlüssel sind die bewussten Kompromisse von PACELC (nach Ausfall: CA/P, sonst: Latenz gegen Consistency), klare SLOs und die Disziplin der Schaltungen/Schlüssel.

Begriffe und Modelle

Replikation - Kopieren Sie Daten zwischen Knoten.

Leader-Follower (Primary-Replica): Ein Eintrag → viele Lesungen.
Multi-Leader (Aktiv-Aktiv): Einträge in mehreren Regionen, Konflikte/Merge.
Consensus-replication (Raft/Paxos, NewSQL): Quorumeinträge (Cassandra/Scylla - AP-Quorum, CockroachDB/Yugabyte - CP-Quorum).
Sync/Semi-sync/Async: Latenzbalance vs RPO.
Sharding - Horizontale Aufteilung der Tabellen/Schlüssel nach Shards.

Hash-Sharding (Gleichmäßigkeit, schwierigere Bereiche).
Range-Sharding (Schlüsselbereiche, Risiko von „heißen“ Enden).
Konsistentes Hashing (sanftes Hinzufügen/Verringern von Knoten).
Geo-Sharding (nach Region/Gerichtsbarkeit).
Funktionale Sharding (nach Domain: Zahlungen/Gebote/CRM).

Wann und was bei iGaming zu wählen

Nur Replikation (ohne Sharding) - wenn das Hauptproblem beim Lesen liegt: Event-Feeds, Berichte, öffentliche Kataloge. Die Einträge passen in einen Leader, die Lesungen aus den Replikaten.
Sharding - wenn ein Schreib-/Speicherengpass besteht: Wettfluss, Saldentransaktionen, Triggerereignisse.

Multi-region:

Latenz gegenüber Spielern/PSPs → lokale Lesungen von Replikaten.
Regulierung (Datenlokalisierung) → Geo-Sharding.
Interregionale DR → asynchrone Replikation + Schaltplan.

PACELC und Garantieeigenschaften

CAP: Beim Netzsplit wählen wir C (Konsistenz) oder A (Verfügbarkeit).
PACELC: Wenn keine Fehler auftreten, wählen wir zwischen Latenz (L) und Konsistenz (C).
Geldwege (Bilanz, Abschreibungen): meist C-orientiert (CP/strict serializable oder serializable + business idempotence).
Weniger kritische Subsysteme (Klickprotokolle, Verzeichnisse): L-orientiert (AP/EC, eventual).

Replikation: Praktiken

Leader–Follower

Einträge → Führer, Lesen → Repliken (Read Scaling).
Read-after-write: Für benutzerdefinierte Operationen lesen Sie vom Leader oder warten Sie auf den Lag (check 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Semi-Sync auf kritischen Pfaden (RPO-Reduktion auf Kosten der Latenz).
Failover: automatisch (patroni/raft-coordinator) + fencing (damit es keinen Doppelführer gibt).

Multi-Leader

Geeignet für geteilte Domains und geringe Konflikte (z.B. Inhalte/Einstellungen), aber nicht für ein einzelnes Spielerkonto ohne besondere Maßnahmen.
Merge-Richtlinien: last-write-wins, CRDT, Domänenkonsolidierungsregeln.

Consensus/Quorum DB

Schreiben mit Quorum (z. B. 'WRITE QUORUM'), Lesen mit Quorum ('READ QUORUM') → starke/anpassbare Konsistenz.
Berücksichtigen Sie die Latenz der Inter-AZ/Regionen und die Kosten des Quorums.

Sharding: Strategien und Schlüsselwahl

Wie wählt man einen Schlüssel

Stabile Verteilung über player_id/ account_id/ bet_id.
Vermeiden Sie monotone Schlüssel (Auto-Increment) in Range-Sharding - „heißer“ Schwanz.
Für Zahlungen - häufig 'player _ id' oder 'account _ id'; für Protokolle - 'event _ time' + bucketing; für den Inhalt „tenant _ id“.

Strategien

Hash-Sharding durch player_id: Balance auf den Fluss von Wetten/Salden.
Range-Sharding nach Zeit für Analysen/Archive.
Geo-Sharding: EU-Spieler → EU-Shard (Einhaltung lokaler Gesetze).
Hybrid: Hash innerhalb der Region + Geo nach Gerichtsbarkeit.

Umgang mit „heißen“ Schlüsseln

Key-Salting (Salz/Bucket zum Schlüssel hinzufügen).
Write-throttling durch das Wesen der command queue (serial executor).
Materialisieren Sie „Aggregate“ (Balance) in einem separaten Stor mit einer Sequenzwarteschlange.

Cross-Shard-Operationen

Geldtransfer/Entschädigung: Vermeiden Sie 2PC auf heißen Wegen.
Saga-Muster: Aufschlüsselung in lokale Transaktionen + kompensierende Aktionen, harte Idempotenz und Outbox.
2RS/Commit-Protokolle: punktuell zulässig (Back-Office-Batches), aber teuer in Latenz und Fehlertoleranz.
Projektionen: Leservorstellungen (Lesemodelle) für domänenübergreifende Bildschirme, die aus dem Stream aktualisiert werden.

Schemata, Indizes und Evolution

Schema-Versionierung: Migrationen von Back-Compat, Feature-Flags auf Code.
Indizes nach Sharding-Schlüsseln und häufigen Abfragen; Vermeiden Sie Cross-Shard-Join (Pre-Join/Denormalisierung).
Für JSON/Dock-Speicher - Validieren Sie Schemata (JSON-Schema/Protobuf) und TTL für „laute“ Sammlungen.

Online-Skalierung und Resharding

Planen Sie eine N≫tekushcheye Anzahl von virtuellen Shards (Slots) → flexible Rebalance.
Konsistentes Hashing oder „virtuelle Knoten“ zum sanften Hinzufügen von Knoten.

Online-Resharding:

Doppelaufzeichnung (alt + neu schard), Konsistenzvalidierung;
Hintergrundkopien von Chankas (logical dump/table move/streaming clone);
Umschalten auf „Marker“ + Beobachtungsfenster, dann Entfernen der doppelten Aufzeichnung.
Bewegen Sie den Führer ohne Ausfallzeiten: Rollen wechseln, Anschlüsse entleeren.

SLO, Beobachtbarkeit und Alarmierung

Schreib/Lese-SLO: p99 ≤ X ms auf Hot Tables, gültige Lag-Repliken ≤ Y Sekunden, Verfügbarkeit ≥ Z.
Metriken: TPS, p95/p99, replication lag, conflict (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency disk.
Trace: 'trace _ id' in DB-Anfragen, Verknüpfung mit dem Event-Broker/Bus.
Kanarische Anfragen und synthetische Transaktionen zur Früherkennung von Degradationen.

Sicherheit und Compliance

Verschlüsselung im Ruhezustand und im Transit (TLS), Schlüsselrotation.
RBAC/ACL, Segmentierung nach Domains/Tenanten, separate Cluster für Zahlungen/CUS.
Datenlokalisierung (EU/TR/LATAM) - Kombinieren Sie Geo-Sharding und Retention Politics.
Audit: wer und was gelesen/Regeln; Maskieren von PII; Audit exportieren.

Backups, PITR, DR

Vollständige + inkrementelle Backups, Offsite-Speicher.
PITR (Point-in-Time Recovery) für Leader-Cluster.

RPO/RTO:

Kritische Domains (Saldo/Zahlung) - RPO≈0 -30s (Semi-Sync oder häufiges WAL-Shipping), RTO ≤ Minuten mit automatischem Failover.
Weniger kritisch - RPO bis zu Minuten/Stunden.
DR-Übung (Spieltag) und dokumentiertes Schaltbuch.

Performance und Tuning (kurz)

Speicher/Cache: Erhöhen Sie die Puffer (shared buffers/innodb buffer pool), folgen Sie dem Cache-Hit ≥ 95%.
Log/Engine: schnelle NVMe, separater Band unter WAL/redo.
Verbindungspool (PgBouncer/Hikari).
Planer/Statistik: Auto-Analyse/Auto-Vakuum (Postgres), GC-Kompression/Tuning (LSM-Engines).
Quorum/Replikat-Faktor: Balance zwischen p99 und Fehlertoleranz.

Typische Topologien für iGaming

1) Salden und Zahlungen (CP-Gliederung)

Leader-Follower in der Region des Spielers, Semi-Sync zum nahen Nachbau.
Hash-Sharding durch 'account _ id'.
Lesen „nach dem Schreiben“ - vom Führer; Projektionen in Redis für API-Latenz.
Outbox → ein Ereignisbus für Berechnungen/Analysen.

2) Wetthistorie/Spielereignisse (AP-orientiertes Log)

Range-Sharding nach Zeit oder Hash nach 'player _ id' im Säulen-/LSM-Speicher.
Asynchrone Replikate für Reporting/OLAP.
Eventual consistency ist akzeptabel, die Bandbreite ist wichtiger.

3) Profile/CRM (Multi-Region lesen, Lokalisierung)

Geo-Sharding nach Gerichtsbarkeit, lokale Repliken für Lesungen.
Aufzeichnungen durch den nächsten Führer; cross-region - asynchron + Konfliktlösung nur für unkritische Felder.

Beispiele (konzeptionell)

Postgres: deklaratives Sharding durch 'player _ id'

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Quorum Record (Pseudo)


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Saga statt 2PC (vereinfacht)

1. Schreiben Sie die Hinterlegung auf shard-A (idempotent) ab.
2. Senden Sie das Ereignis „gefilmt“ → den Auszahlungsdienst (Shard-B).
3. Wenn Schritt 2 fehlschlägt, kompensieren Sie Schritt 1 mit dem Ereignis „return“.

Checkliste Umsetzung

1. Definieren Sie Datendomänen und SLOs (p99, RPO/RTO, Replikat-Lag).
2. Wählen Sie ein Replikationsmodell (Leader/Follower, Quorum) und eine Sharding-Strategie.
3. Fixieren Sie die Sharding-Schlüssel und das Schema (unveränderlich!).
4. Geben Sie Read-After-Write-Richtlinie und Leserouting ein.
5. Gestalten Sie Online-Resharding (virtuelle Shards, Double Writing).
6. Idempotenz und Outbox für Events/Teams garantieren.
7. Richten Sie Backups, PITR, DR und regelmäßige Übungen ein.
8. Umfassen Sie die Beobachtbarkeit: Lag, Quorums, Hot Keys, Konflikte.
9. Dokumentieren Sie das Runbook: Failover, Split-Brain, Degradation.
10. Führen Sie Belastungs-/Chaos-Tests für Matchspitzen durch.

Antimuster

Ein riesiger Shard „für alles“ und „dann werden wir schneiden“.
Cross-Shard-Join's auf dem heißen Weg der Anfrage.
Keine Read-After-Write-Richtlinie (Floating Bugs).
Schemamigrationen „brechen“ Sharding-Schlüssel.
Multi-Leader für Geldkonten ohne strikte Konfliktlösung.
Kein PITR/DR - Es ist unmöglich, sich von einem logischen Fehler zu erholen.

Ergebnisse

Replikation löst Lese- und Fehlertoleranz, Sharding löst Schreib- und Lautstärke. Erfolgreiche Architektur in iGaming sind klare SLOs und PACELCs, stabile Sharding-Schlüssel, ein Minimum an Cross-Shard-Koordination (Saga statt 2PCs), die Disziplin des Read-After-Write, gut funktionierendes Online-Resharding und regelmäßige DR-Übungen. Dieser Ansatz ist skalierbar für Turnierspitzen, hält regulatorischen Einschränkungen bei der Datenlokalisierung stand und bleibt im Betrieb vorhersehbar.