Shading i replikacja bazy danych

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Dla platform iGaming, wzrost ruchu (zakłady, depozyty, haki internetowe PSP, wydarzenia gry) i wymagania dostępności (99. 9–99. 99%) szybko trafił na limit jednego DB. Replikacja zapewnia poziomą skalowanie odczytu i tolerancję uszkodzeń; shading - pozioma skalowanie rekordów i danych. Kluczem są świadome kompromisy PACELC (po awarii: CA/P, inaczej: Latency vs Consistency), jasne SLO i schemat/kluczowa dyscyplina.

Warunki i modele

Replikacja - Kopiuje dane między stronami.

Leader-Follower (Primary-Replica): jeden wpis → wiele odczytów.
Multi-Leader (Active-Active): wpisy w kilku regionach, konflikty/połączenie.
Replikacja konsensusowa (Raft/Paxos, NewSQL): rekordy kworum (Cassandra/Scylla - kworum AP, CockroachDB/Yugabyte - kworum CP).
Synchronizacja/półsynchronizacja/async: opóźnienie salda vs RPO.
Shading - poziomy podział stołów/kluczy przez odłamki.

Shading hash (jednorodność, trudniejsze zakresy).
Shading zakresu (kluczowe zakresy, ryzyko hot end).
Konsekwentne hashing.
Geowłóknina (według regionu/jurysdykcji).
Shading funkcjonalny (według domeny: płatności/stawki/CRM).

Kiedy i co wybrać w iGaming

Replikacja tylko (bez strzyżenia) - gdy głównym problemem jest czytanie: kanały zdarzeń, raporty, katalogi publiczne. Zapisy są umieszczone w jednym liderze, odczytuje z replik.
Shading - gdy wąskie gardło zapisu/zatrzymania: przepływ kursu, transakcje bilansowe, zdarzenia wyzwalające.

Wielobranżowe:

Odtwarzacz/opóźnienie PSP → lokalne odczyty z replik.
Regulacja (lokalizacja danych) → geowłóknina.
Interregional DR → replika asynchroniczna + plan przełączania.

PACELC i właściwości gwarancyjne

WPR: z dzieloną siecią, wybierz C (spójność) lub A (dostępność).
PACELC: w przypadku braku awarii wybierz między Latency (L) a Consistency (C).
Sposoby gotówkowe: zwykle zorientowane na C (CP/surowy serializowalny lub serializowalny + business idempotence).
Mniej krytyczne podsystemy (kliknięcia dziennika, katalogi): zorientowane na L (AP/EC, eventual).

Praktyki replikacji

Leader-Follower

Pisze → lider, czyta, → czytaj skalowanie.
Odczytywanie po zapisie: dla operacji użytkownika, odczytywanie z lidera lub czekanie na lag (sprawdź 'last _ committed _ lsn'/' wait _ for _ replay _ lag').
Półsynchronizacja na ścieżkach krytycznych (redukcja RPO kosztem opóźnienia).
Awaria: automatyczne (patroni/tratwa koordynator) + ogrodzenie (tak, że nie ma podwójnego lidera).

Multi-Leader

Nadaje się do podziału domen i niskiego konfliktu (np. zawartość/ustawienia), ale nie dla jednego konta gracza bez specjalnych środków.
Zasady scalania: last-write-wins, CRDT, zasady konsolidacji domeny.

Konsensus/Kworum bazy danych

Zapisz kworum (np. „ZAPISZ KWORUM”), kworum czytać („CZYTAĆ KWORUM”) → silna/konfigurowalna konsystencja.
Zastanów się nad kosztami opóźnienia i kworum między AZ/regionem.

Shading: strategie i kluczowe wybory

Jak wybrać klucz

Stabilna dystrybucja przez player_id/ account_id/ bet_id.
Unikaj monotonnych klawiszy (automatyczne przyrost) w zakresie shading - „gorący” ogon.
Dla płatności - często 'player _ id' lub' account _ id'; dla kłód - 'event _ time' + bucketing; dla treści - "najemca _ id'.

Strategia

Shading przez player_id: bilans przepływu prędkości/sald.
Zakresy czasowe dla analityki/archiwów.
Geowłóknina: gracze UE → EU-shard (zgodność z przepisami lokalnymi).
Hybryda: hash w regionie + geo według jurysdykcji.

Walka gorących kluczy

Solenie klucza (dodać sól/wiadro do klucza).
Write-throttling jest zasadniczo kolejką poleceń (wykonawca szeregowy).
Urzeczywistnić „agregaty” (równowagę) w oddzielnym wierszu z kolejką sekwencji.

Operacje krzyżowe

Przelew pieniężny/rekompensata: unikać 2PC na gorących ścieżkach.
Wzór sagi: podzielony na transakcje lokalne + działania kompensacyjne, twardy idempotencja i outbox.
protokoły 2PC/commit: dopuszczalny punkt (serie zaplecza), ale kosztowny pod względem opóźnień i tolerancji błędów.
Projekcje: czytaj modele dla ekranów poprzecznych, aktualizowane z strumienia.

Systemy, wskaźniki i ewolucja

Schemat wersji: migracje z back-compat, feature-flags na kod.
Indeksy na klawiszy shading i częste zapytania; unikać łączenia krzyżowo-odłamkowego (wykonać wstępne połączenie/denormalizację).
Dla magazynów JSON/dokowania - systemy walidacji (JSON-Schema/Protobuf) i TTL dla zbiorów „hałaśliwych”.

Skalowanie online i ponowne wykorzystywanie

Zaplanuj N-tekushcheye liczbę wirtualnych odłamków (szczelin) → elastyczna rebalancja.
Spójne hashing lub „wirtualne węzły” dla dodawania węzłów miękkich.

Przesunięcie online:

podwójny wpis (stary + nowy odłamek), walidacja spójności;
kopie tła kawałków (zrzut logiczny/ruch stołu/klon strumieniowy);
przełącznik przez „marker” + okno obserwacyjne, a następnie podwójny rekord.
Przenoszenie lidera bez przestoju: przełączanie ról, odprowadzanie połączeń.

SLO, obserwowalność i ostrzeganie

SLO napisz/przeczytaj: p99 ≤ X ms na gorących tabelach, ważne repliki lag ≤ Y sekund, dostępność ≥ Z.
Metryki: TPS, p95/p99, lag replikacji, multi-leader, szybkość wznowienia, impasy, czekanie blokady, współczynnik trafienia pamięci podręcznej, dysk IOPS/opóźnienie.
Śledzenie: 'trace _ id' w żądaniach bazy danych, powiązanie z brokerem/autobusem zdarzeń.
Zapytania kanaryjskie i transakcje syntetyczne do wczesnego wykrywania degradacji.

Bezpieczeństwo i zgodność

Szyfrowanie w stanie spoczynku i tranzytu (TLS), rotacja klucza.
RBAC/ACL, segmentacja według domeny/najemcy, oddzielne klastry płatności/LCC.
Lokalizacja danych (EU/TR/LATAM) - połączenie polityki geodezyjnej i retencyjnej.
Audyt: kto i co czytać/zasady; Maskowanie PII; Kontrola eksportu.

Kopie zapasowe, PITR, DR

Pełne + dodatkowe kopie zapasowe, magazyn offsetowy.
PITR (odzyskiwanie w czasie) dla klastrów liderów.

RPO/RTO:

Domeny krytyczne (saldo/płatność) - RPO ≤ 0 -30s (półsynchronizacja lub częsta wysyłka WAL), RTO ≤ minuty z automatyczną awarią.
Mniej krytyczny - RPO do minut/godziny.
Ćwiczenia DR (dzień gry) i udokumentowany katalog przełączników.

Wydajność i dostrajanie (krótki)

Pamięć/pamięć podręczna: zwiększenie buforów (bufory wspólne/basen buforowy innodb), pamięci podręcznej monitora ≥ 95%.
Magazyn/silnik: szybki NVMe, oddzielna objętość WAL/redo.
Basen (PgBouncer/Hikari).
Planner/statistics: auto-analysis/auto-próżnia (Postgres), GC compression/tuning (silniki LSM).
Współczynnik kworum/repliki: równowaga między p99 a tolerancją uszkodzeń.

Typowe topologie dla iGaming

1) Salda i płatności (pętla CP)

Leader-Follower w regionie gracza, półsynchronizować do bliskiej repliki.
Shading hash przez 'account _ id'.
Odczyty „po napisaniu” - od lidera; projekcje dla Redis dla API-latency.
Outbox → event bus do obliczeń/analiz.

2) Historia zakładów/imprezy hazardowe (dziennik zorientowany na AP)

Shading zakresu według czasu lub hash przez 'player _ id' w kolumnie/pamięci LSM.
Asynchroniczne repliki do raportowania/OLAP.
Ewentualna konsystencja jest akceptowalna, przepustowość jest ważniejsza.

3) Profile/CRM (wielobranżowy odczyt, lokalizacja)

Geowłóknienie według jurysdykcji, lokalne repliki odczytów.
Wpisy przez najbliższego lidera; cross-region - asynchronicznie + rozwiązywanie konfliktów tylko w dziedzinach innych niż krytyczne.

Przykłady (koncepcyjne)

Postgres: deklaratywne ostrzenie przez '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)';

Nagrywanie kworum (pseudo)


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

Saga zamiast 2PC (uproszczone)

1. Zapisz depozyt do shard-A (idempotent).
2. Wyślij zdarzenie „usunięte” → usługa płatnicza (shard-B).
3. Jeśli krok 2 nie powiedzie się, skompensuj krok 1 zdarzeniem "powrót'.

Lista kontrolna wdrażania

1. Zdefiniuj domeny danych i SLO (p99, RPO/RTO, dziennik replik).
2. Wybierz model replikacji (leader/follower, quorum) i strategię shading.
3. Naprawić klucze i schemat (immutable!).
4. Wpisz zasady odczytu po zapisie i przeczytaj routing.
5. Projekt odtworzenia online (wirtualne odłamki, podwójne wejście).
6. Zapewnij idempotencję i skrzynkę odbiorczą dla zdarzeń/poleceń.
7. Skonfiguruj kopie zapasowe, PITR, DR i regularne ćwiczenia.
8. Uwzględnij obserwowalność: lag, kworums, gorące klucze, konflikty.
9. Katalog dokumentów: awaria, podział mózgu, degradacja.
10. Wykonaj testy obciążenia/chaosu w szczytach dopasowania.

Anty-wzory

Jeden olbrzymi odłamek „za wszystko” i „potem przeciąć”.
Połączenie Cross-Shard jest na gorąco.
Brak zasad odczytu po zapisie (zmienne błędy).
Migracja systemów „łamania” kluczy.
Wielu liderów w zakresie kont gotówkowych bez ścisłego rozwiązywania konfliktów.
Brak PITR/DR - Nie można odzyskać z błędu logicznego.

Wyniki

Replikacja rozwiązuje odczyty i odporność, shading rozwiązuje zapisy i głośność. Udana architektura w iGaming to wyraźne kompromisy SLO i PACELC, stabilne klucze do rzucania, minimalna koordynacja krzyżówek (saga zamiast 2PC), dyscyplina czytania po pisaniu, dobrze funkcjonująca reshitting online i regularne ćwiczenia DR. To podejście skala do szczytów turnieju, wytrzymuje ograniczenia regulacyjne dotyczące lokalizacji danych i pozostaje przewidywalne w eksploatacji.