Дерекқорды шардингтеу және репликалау

(Бөлім: Технологиялар және Инфрақұрылым)

Қысқаша түйіндеме

iGaming-платформалар үшін трафиктің өсуі (мөлшерлемелер, депозиттер, PSP веб-хактері, ойындар оқиғалары) және қолжетімділікке қойылатын талаптар (99- ≈. 9–99. 99%) бір ДБ шегіне тез тіреледі. Репликация оқуды көлденең масштабтауды және істен шығуға төзімділікті береді; шардинг - жазбалар мен деректерді көлденең масштабтау. Кілт - PACELC саналы ымырасы (бас тартқаннан кейін: CA/P, әйтпесе: Latency vs Consistency), нақты SLO және схемалар/кілттер тәртібі.

Терминдер мен модельдер

Репликалау - тораптар арасындағы деректерді көшіру.

Leader-Follower (Primary-Replica): бір жазба → көп оқу.
Multi-Leader (Active-Active): бірнеше өңірлердегі жазбалар, жанжалдар/мердж.
Consensus-replication (Raft/Paxos, NewSQL): кворумдық жазбалар (Cassandra/Scylla - AP-кворумдар, CockroachDB/Yugabyte - CP-кворумдар).
Sync/Semi-sync/Async: кідіріс балансы vs RPO.
Шардинг - кестелерді/кілттерді шардарға көлденең бөлу.

Hash-шардинг (біркелкілік, күрделірек диапазондар).
Range-шардинг (кілттердің диапазондары, «ыстық» ұштарының тәуекелі).
Consistent hashing (жұмсақ қосу/түйін азайту).
Geo-шардинг (өңір/юрисдикция бойынша).
Функционалдық шардинг (домендер бойынша: төлемдер/мөлшерлемелер/CRM).

iGaming бағдарламасында қашан және не таңдау керек

Тек репликалау (шардингсіз) - оқудағы негізгі проблема: оқиғалар таспасы, есептер, көпшілік каталогтар. Жазбалар бір көшбасшыға, оқулар репликадан орналастырылады.
Шардинг - жазу/сақтау орны тар болғанда: мөлшерлемелер ағыны, теңгерім транзакциялары, триггерлік оқиғалар.

Multi-region:

Ойыншыларға жасырындылық/PSP → жергілікті репликадан оқу.
Реттеуіш (деректерді оқшаулау) → geo-шардинг.
Аймақаралық DR → асинхронды реплика + ауыстыру жоспары.

PACELC және кепілдік қасиеттері

CAP: split желісі кезінде C (консистенттілік) немесе A (қолжетімділік) таңдаймыз.
PACELC: қателер болмаған жағдайда Latency (L) және Consistency (C) арасында таңдаймыз.
Ақша жолдары (теңгерім, есептен шығару): әдетте C-бағдарланған (CP/strict serializable немесе Serializable + бизнес-идемпотенттілік).
Аз сыни кіші жүйелер (кликтер, каталогтар): L-бағдарланған (AP/EC, eventual).

Репликалау: тәжірибелер

Leader–Follower

Жазбалар → көшбасшы, оқу → реплика (read scaling).
Read-after-write: пайдаланушы операциялары үшін көшбасшыдан оқыңыз немесе лаг күтіңіз (тексеру 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Сындарлы жолдардағы Semi-sync (RPO-ны жасырындылық бағасымен төмендету).
Failover: автоматты (patroni/raft-координатор) + fencing (қос көшбасшы болмауы үшін).

Multi-Leader

Бөлінген домендер мен төмен қайшылықтар үшін жарамды (мысалы, контент/теңшелім), бірақ арнайы шараларсыз ойыншының бірыңғай шотына жарамайды.
Мердж саясаты: last-write-wins, CRDT, шоғырландыру домендік ережелері.

Consensus/Кворумды БД

Кворуммен жазу (мысалы, 'WRITE QUORUM'), кворуммен оқу ('READ QUORUM') → күшті/теңшелетін консистенттік.
АЗ/өңірлер арасындағы латенттілікті және кворум құнын ескеріңіз.

Шардинг: стратегиялар және кілтті таңдау

Кілтті қалай таңдауға болады

player_id/ account_id/ bet_id бойынша тұрақты бөлу.
Range-шардингте монотонды кілттерден (auto-increment) аулақ болыңыз - «ыстық» құйрық.
Төлемдер үшін - көбінесе 'player _ id' немесе 'account _ id'; логтар үшін - 'event _ time' + bucketing; мазмұн үшін - 'tenant _ id'.

Стратегиялар

player_id бойынша hash-шардинг: ставкалар/баланстар ағынындағы баланс.
Талдау/мұрағаттар үшін уақыт бойынша Range-шардинг.
Geo-шардинг: EU-ойыншылар → EU-шард (жергілікті заңдарға сәйкес).
Гибрид: аймақ ішіндегі hash + юрисдикция бойынша geo.

«Ыстық» кілттермен күресу

Key-salting (кілтке тұз/bucket қосу).
Write-throttling мәні бойынша, командалар кезегі (serial executor).
«Агрегаттарды» (балансты) кезектілікпен жеке сторда материалдандыру.

Кросс-шард операциялары

Ақшалай аударымдар/өтемақылар: ыстық жолдарда 2PC болдырмау.
Сага-паттерн: жергілікті транзакцияларға + өтемдік әрекеттерге, қатаң теңсіздікке және outbox.
2РС/коммита хаттамалары: нүктелік (бэк-офистік батчтар) рұқсат етіледі, бірақ жасырындылығы мен істен шығуға төзімділігі бойынша қымбат.
Проекциялар: ағымнан жаңартылатын домен аралық экрандар үшін оқырман көріністері (read models).

Схемалар, индекстер және эволюция

Схеманы нұсқалау: back-compat, кодтағы feature-flags көшіру.
Шардалау кілттері және жиі сұраулар бойынша индекстер; cross-shard join (pre-join/денормализация жасаңыз).
JSON/док-сақтау орындары үшін - «шулы» коллекциялар үшін (JSON-Schema/Protobuf) және TTL схемаларын валидациялаңыз.

Онлайн масштабтау және ресхардинг

N ≫ виртуалды шардтардың ағымдағы санын (slots) → икемді ребалансты жоспарлаңыз.
Consistent hashing немесе тораптарды жұмсақ қосу үшін «виртуалды нодтар».

Online-ресхардинг:

қос жазба (ескі + жаңа шард), консистенттілікті валидациялау;
күбілердің фондық көшірмелері (logical dump/table move/streaming clone);
«маркер» бойынша қайта қосу + бақылау терезесі, содан кейін қос жазбаны алып тастау.
Көшбасшының тоқтаусыз көшуі: рөлдерді ауыстыру, коннекшендерді дренаждау.

SLO, бақылау және алертинг

SLO жазу/оқу: p99 ≤ X мс ыстық кестелерде, рұқсат етілген lag реплика ≤ Y секунд, қол жетімділік ≥ Z.
Метриктер: TPS, p95/p99, replication lag, қайшылық (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency диск.
Трассировка: 'trace _ id' ДБ сұрауларында оқиғалар брокерімен/шинасымен байланыстыру.
Құлдыраудың ерте детекторы үшін канареялық сұраулар мен synthetic transactions.

Қауіпсіздік және талаптарға сәйкестігі

Тыныштықта және транзитте шифрлау (TLS), кілттерді ротациялау.
RBAC/ACL, домендер/тенанттар бойынша сегменттеу, төлемдер/АКҚ үшін жеке кластерлер.
Деректерді оқшаулау (EU/TR/LATAM) - гео-шардинг пен ретенция саясаттарын біріктіріңіз.
Аудит: кім және не оқыды/ереже; PII бүркемелеу; аудит экспорты.

Бэкаптар, PITR, DR

Толық + инкременталды бэкаптар, оффсайт-сақтау орны.
Жетекші кластерлер үшін PITR (point-in-time recovery).

RPO/RTO:

Сындарлы домендер (баланс/төлем) - RPO ≈ 0-30с (semi-sync немесе жиі WAL-шиппинг), автоматты failover бар RTO ≤ минут.
Аз сыни - RPO минут/сағатқа дейін.
DR-жаттығулар (game day) және құжатталған runbook ауыстыру.

Өнімділік және тюнинг (қысқаша)

Жад/кэш: буферлерді үлкейтіңіз (shared buffers/innodb buffer pool), cache-hit ≥ 95% қадағалаңыз.
Журнал/қозғалтқыш: жылдам NVMe, WAL/redo үшін жеке том.
Қосылымдар пулы (PgBouncer/Hikari).
Жоспарлаушы/статистика: автованализа/автовакуум (Postgres), компакция/тюнинг GC (LSM-қозғалтқыштар).
Кворумдар/реплика-фактор: p99 және істен шығуға төзімділік арасындағы теңгерім.

iGaming үшін типтік топологиялар

1) Баланстар мен төлемдер (CP-контур)

Ойыншы аймағында Leader-Follower, жақын репликаға semi-sync.
'account _ id' бойынша hash-шардинг.
«Жазудан кейін» - көшбасшыдан; API-latency үшін Redis проекциялары.
Outbox → есептеулер/талдау үшін оқиғалар шина.

2) Ставкалардың тарихы/ойын оқиғалары (AP-бағдарланған лог)

Range-шардинг уақыты бойынша немесе hash 'player _ id' бағанды/LSM-сақтау орнында.
Есеп беру/OLAP үшін асинхрондық репликалар.
Eventual consistency қолайлы, өткізу қабілеті маңызды.

3) Профильдер/CRM (Multi-region read, локализация)

Юрисдикция бойынша Geo-шардинг, оқуға арналған жергілікті репликалар.
Жазбалар жақын көшбасшы арқылы; кросс-өңір - асинхронды + тек сындарлы емес өрістер үшін жанжалдарды шешу.

Мысалдар (тұжырымдамалық)

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

Кворумдық жазба (жалған)


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

2PC орнына сага (оңайлатылған)

1. Депоненттеуді шард-A (idempotent) деп есептен шығару.
2. Оқиғаны жіберу «алынды» → төлем қызметі (шард-B).
3. Егер 2-қадам сәтсіз болса - 1-қадам «қайтару» оқиғасымен өтеледі.

Енгізу парағы

1. Деректер домендерін және SLO (p99, RPO/RTO, репликалар легі) анықтаңыз.
2. Репликалау моделін (leader/follower, кворум) және шардинг стратегиясын таңдаңыз.
3. Шардинг кілттері мен сұлбаны бекітіңіз (өзгермейді!).
4. read-after-write саясаты мен оқу бағытын енгізіңіз.
5. Онлайн-ресхардингті жобалаңыз (виртуалды шарлар, қосарланған жазба).
6. Оқиғалар/командалар үшін теңсіздік пен outboxқа кепілдік беріңіз.
7. Бэкаптарды, PITR, DR және тұрақты жаттығуларды теңшеңіз.
8. Байқауды қосыңыз: лаг, кворумдар, ыстық кілттер, жанжалдар.
9. Runbook: failover, split-brain, деградацияларды құжаттаңыз.
10. Матчтық шыңдар астында жүктеме/хаос-тесттер жүргізіңіз.

Антипаттерндер

Бір алпауыт шард «барлығына» және «содан кейін кесеміз».
Сұраудың ыстық жолындағы кросс-шардтық join's.
read-after-write саясатының болмауы.
Шардингтің «сындыру» кілттері схемаларының көші-қоны.
Дауларды қатаң қараусыз ақшалай шоттар үшін Multi-leader.
PITR/DR жоқ - логикалық қатеден кейін қалпына келтіру мүмкін емес.

Қорытынды

Репликация оқуды және істен шығуға төзімділікті, шардинг - жазбалар мен көлемді шешеді. iGaming-тегі табысты сәулет - бұл айқын SLO және PACELC-компромисстер, тұрақты шардинг кілттері, минималды кросс-шардты үйлестіру (2PC орнына сага), read-after-write пәні, реттелген online-ресхардинг және тұрақты DR-жаттығулар. Мұндай тәсіл турнирлердің шыңына қарай кеңейтіледі, деректерді оқшаулау бойынша реттеушілік шектеулерге төтеп береді және пайдалануда болжамды болып қалады.