Împărțirea și replicarea bazelor de date

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Pentru platformele iGaming, creșterea traficului (pariuri, depozite, carti web PSP, evenimente de joc) și cerințele de disponibilitate (≈99. 9–99. 99%) a atins rapid limita de un DB. Replicarea oferă scalarea citirii orizontale și toleranța la erori; sharding - scalarea orizontală a înregistrărilor și a datelor. Cheia este compromisurile conștiente ale PACELC (după eșec: CA/P, în caz contrar: latență vs consecvență), SLO clare și schema/disciplina cheie.

Termeni și modele

Replicare - Copiază datele între site-uri.

Leader-Follower (Primary-Replica): o singură intrare → multe citește.
Multi-Leader (Active-Active): intrări în mai multe regiuni, conflicte/fuziune.
Replicarea consensului (Raft/Paxos, NewSQL): înregistrări cvorum (Cassandra/Scylla - cvorumuri AP, Cvorumuri CockroachDB/Yugabyte - CP).
Sincronizare/semi-sincronizare/Async: echilibru de întârziere vs RPO.
Sharding - împărțirea orizontală a tabelelor/cheilor de cioburi.

Hash-sharding (uniformitate, intervale mai dure).
Gama-sharding (intervale cheie, risc final fierbinte).
Hashing consistent.
Geo-sharding (pe regiuni/jurisdicții).
Sharding funcțional (pe domenii: plăți/rate/CRM).

Când și ce să alegeți în iGaming

Replicarea numai (nu sharding) - atunci când problema principală este citirea: feed-uri eveniment, rapoarte, directoare publice. Înregistrările sunt plasate într-un singur lider, citeşte din replici.
Sharding - atunci când scrieți/țineți blocajul: debitul ratei, tranzacțiile bilanțiere, evenimentele declanșatoare.

Multi-regiune:

Latența jucătorului/PSP → citirile locale din replici.
Reglarea (localizarea datelor) → geografia.
Interregional DR → asincron replica + plan de comutare.

PACELC și proprietăți de garanție

CAP: cu o rețea divizată, selectați C (consistență) sau A (disponibilitate).
PACELC: dacă nu există eșecuri, alegeți între latență (L) și consistență (C).
Cash ways: de obicei C-orientate (CP/strict serializabil sau serializabil + idempotency de afaceri).
Subsisteme mai puțin critice (clicuri de jurnal, directoare): orientate spre L (AP/CE, eventual).

Practici de replicare

Leader-Follower

Scrie → lider, citește → citește scalarea.
Read-after-write: pentru operațiunile utilizatorilor, citiți de la lider sau așteptați lag (verificați 'last _ committed _ lsn'/' wait _ for _ replay _ lag').
Semi-sincronizare pe căile critice (reducerea RPO la costul latenței).
Failover: automată (patroni/plută coordonator) + scrimă (astfel încât nu există nici un lider dublu).

Multi-Leader

Potrivit pentru domenii divizate și conflicte reduse (de ex. conținut/setări), dar nu pentru un singur cont de jucător fără măsuri speciale.
Fuzionarea politicilor: last-write-wins, CRDT, reguli de consolidare a domeniului.

Baze de date consens/cvorum

Scriere cvorum (ex. 'WRITE QUORUM'), cvorum read ('READ QUORUM') → consistență puternică/configurabilă.
Luați în considerare latența inter-AZ/regiune și costul cvorumului.

Sharding: Strategii și alegeri cheie

Cum de a alege o cheie

Distribuție stabilă prin player_id/ account_id/ bet_id.
Evitați cheile monotone (auto-increment) în gama-sharding - coada „fierbinte”.
Pentru plăți - adesea 'player _ id' sau' account _ id'; pentru jurnale - 'event _ time' + bucketing; pentru conținut - 'chiriaș _ id'.

Strategii

Hash-sharing după player_id: echilibru pe fluxul de rate/solduri.
Sharding bazat pe interval de timp pentru analize/arhive.
Geo-sharing: actorii UE → EU-shard (respectarea legislației locale).
Hibrid: hash în cadrul regiunii + geo de jurisdicție.

Combaterea cheilor fierbinți

Sărarea cheilor (adăugați sare/găleată la cheie).
Write-throttling este, în esență, o coadă de comandă (executor serial).
Materializați „agregate” (echilibru) într-un rând separat cu o coadă de secvență.

Operațiuni cross-shard

Transfer de bani/compensare: evitați 2PC pe piste fierbinți.
Modelul Saga: împărțit în tranzacții locale + acțiuni compensatorii, idempotență și outbox.
protocoale 2PC/commit: punct admis (loturi back-office), dar costisitoare în latență și toleranță la erori.
Proiecții: citiți modele pentru ecrane cross-domain, actualizate din flux.

Scheme, indici și evoluție

Versionarea schemei: migrări de la back-compat, feature-flags pe cod.
Indexuri pe taste de afișare și interogări frecvente; evita cross-shard se alăture (face pre-unire/denormalizare).
Pentru depozitele JSON/andocare - scheme de validare (JSON-Schema/Protobuf) și TTL pentru colecțiile „zgomotoase”.

Scalare și Rescharing Online

Planificați să N≫tekushcheye numărul de cioburi virtuale (sloturi) → reechilibrare flexibilă.
Hashing consistent sau „noduri virtuale” pentru adăugarea de noduri moi.

Resharding online:

intrare dublă (cioburi vechi + noi), validarea consistenței;
copii de fundal ale bucăților (groapa de gunoi logică/mutarea mesei/clona de streaming);
comutați cu „marker” + fereastră de observare, apoi înregistrați dublu.
Mutarea liderului fără întreruperi: comutarea rolurilor, drenarea conexiunilor.

SLO, observabilitate și alertare

SLO scrie/citi: p99 ≤ X ms pe mese fierbinți, replici valide lag ≤ secunde Y, disponibilitate ≥ Z.
Măsurători: TPS, p95/p99, decalaj de replicare, multi-leader, rată de reîncercare, blocaje, așteptare de blocare, raport de lovire a memoriei cache, disc IOPS/latență.
Trace: 'trace _ id' în cererile de baze de date, asociat cu broker/eveniment autobuz.
Interogări canare și tranzacții sintetice pentru detectarea precoce a degradării.

Securitate și conformitate

Criptare în repaus și în tranzit (TLS), rotație cheie.
RBAC/ACL, segmentare pe domenii/chiriași, clustere separate pentru plăți/LCC.
Localizarea datelor (EU/TR/LATAM) - combina politicile de geografie si retentie.
Audit: cine și ce citește/reguli; PII mascare; Export Audit.

Copii de rezervă, PITR, DR

Backup complet + incremental, stocare offsite.
PITR (point-in-time recovery) pentru grupurile de lideri.

RPO/RTO:

Domenii critice (sold/plată) - RPO≈0 -30 (semi-sincronizare sau frecvente WAL-transport), RTO ≤ minute cu failover automat.
Mai puțin critică - RPO până la minute/ore.
Exerciții DR (ziua jocului) și o carte de comutare documentată.

Performanță și tuning (scurt)

Memorie/memorie cache: creșteți tampoanele (tampoane partajate/piscină tampon innodb), monitorizați cache-hit ≥ 95%.
Magazin/motor: rapid NVMe, volum separat sub WAL/reface.
Piscină de conexiune (PgBouncer/Hikari).
Planificator/statistici: auto-analiză/auto-vid (Postgres), compresie/tuning GC (motoare LSM).
Factorul cvorum/replica: echilibru între p99 și toleranța la erori.

Topologii tipice pentru iGaming

1) Solduri și plăți (CP-loop)

Leader-Follower în regiunea jucătorului, semi-sincronizare la o replică strânsă.
Hash-sharding prin "account _ id'.
Lecturi „după scris” - de la lider; proiecții la Redis pentru API-latență.
Outbox → event bus pentru calcule/analytics.

2) Istoria pariurilor/evenimente de joc (jurnal orientat spre AP)

Raza de acțiune în funcție de timp sau hash de 'player _ id' în coloană/stocare LSM.
Replici asincrone pentru raportare/OLAP.
Coerența eventuală este acceptabilă, lățimea de bandă este mai importantă.

3) Profile/CRM (Citire multiregională, localizare)

Geo-partajarea pe jurisdicție, replici locale pentru lecturi.
Intrările prin cel mai apropiat lider; cross-region - asincron + rezolvarea conflictelor numai pentru câmpurile non-critice.

Exemple (conceptual)

Postgres: partajare declarativă prin '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

-- Replication: WAL publishing to replicas, synchronous for hot region.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Înregistrarea cvorumului (pseudo)


WRITE CL = QUORUM -- record confirmed by majority of replicas
READ CL = LOCAL _ QUORUM -- local quorum for low latency

Saga în loc de 2PC (simplificat)

1. Scrieți depunerea la ciob-A (idempotent).
2. Trimite eveniment „eliminat” → serviciu de plată (shard-B).
3. Dacă pasul 2 eșuează, compensați pasul 1 cu un eveniment „retur”.

Lista de verificare a implementării

1. Definiți domeniile de date și SLO-urile (p99, RPO/RTO, jurnal de replici).
2. Selectați modelul de replicare (lider/adept, cvorum) și strategia de sharding.
3. Fixați cheile de sharding și schema (imuabil!).
4. Introduceți politica de citire după scriere și citiți rutarea.
5. Design online resharding (cioburi virtuale, intrare dublă).
6. Asigurați idempotența și outbox pentru evenimente/comenzi.
7. Configurați copii de rezervă, PITR, DR și exerciții regulate.
8. Includeți observabilitatea: lag, cvorumuri, chei fierbinți, conflicte.
9. Document runbook: failover, split-creier, degradare.
10. Efectuați teste de încărcare/haos sub vârfurile de meci.

Anti-modele

Un ciob uriaş „pentru orice” şi „apoi tăiat”.
Cross-shard se alăture în modul fierbinte al cererii.
Fără politică de citire după scriere (bug-uri plutitoare).
Migrarea schemelor de „rupere” a cheilor de tăiere.
Multi-lider pentru conturi în numerar fără rezolvarea strictă a conflictelor.
Nu PITR/DR - Imposibil de a recupera de la eroare logică.

Rezumat

Replicarea rezolvă citește și reziliență, sharding rezolvă scrie și volumul. Arhitectura de succes în iGaming este compromisuri clare SLO și PACELC, chei de sharding stabile, un minim de coordonare cross-shard (saga în loc de 2PC), disciplină read-after-write, resharding online și exerciții DR regulate. Această abordare scalează vârfurile turneelor, rezistă restricțiilor de reglementare privind localizarea datelor și rămâne previzibilă în funcționare.