Ma’lumotlar bazalarini sharding va replikatsiya qilish

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

iGaming-platformalar uchun trafikning o’sishi (stavkalar, depozitlar, PSP vebxuklari, o’yinlar voqealari) va foydalanishga bo’lgan talablar (99 ≈. 9–99. 99%) tezda bitta DB chegarasiga tushadi. Replikatsiya oʻqishni gorizontal masshtablash va nosozlikka chidamlilik beradi; sharding - yozuv va ma’lumotlarni gorizontal ko’paytirish. Kalit - PACELCning ongli kompromislari (rad etilgandan keyin: CA/P, aks holda: Latency vs Consistency), aniq SLO va sxemalar/kalitlar intizomi.

Atamalar va modellar

Replikatsiya - ma’lumotlarni uzellar o’rtasida ko’chirish.

Leader-Follower (Primary-Replica): bitta yozuv → ko’p o’qish.
Multi-Leader (Active-Active): bir nechta mintaqalardagi yozuvlar, mojarolar/merj.
Consensus-replication (Raft/Paxos, NewSQL): kvorum yozuvlari (Cassandra/Scylla - AP-kvorumlar, CockroachDB/Yugabyte - CP-kvorumlar).
Sync/Semi-sync/Async: kechikish balansi vs RPO.
Sharding - jadvallarni/kalitlarni shardlarga gorizontal ajratish.

Hash-sharding (bir tekislik, murakkab diapazonlar).
Range-sharding (kalitlar diapazoni, «issiq» uchlar xavfi).
Consistent hashing (yumshoq qoʻshish/kamaytirish).
Geo-sharding (mintaqa/yurisdiksiya bo’yicha).
Funksional sharding (domenlar bo’yicha: to’lovlar/stavkalar/CRM).

iGaming’da qachon va nima tanlash kerak

Faqat replikatsiya (shardingsiz) - asosiy muammo o’qishda bo’ladi: voqealar lentalari, hisobotlar, ommaviy kataloglar. Yozuvlar bitta peshqadamga, o’qishlar esa replikalarga joylashtiriladi.
Sharding - yozish/saqlash joyi tor bo’lganda: stavkalar oqimi, balans tranzaksiyalari, trigger hodisalari.

Multi-region:

O’yinchilarga/PSP → lokal replikalardan o’qish.
Regulyatorika (ma’lumotlarni mahalliylashtirish) → geo-sharding.
Mintaqalararo DR → asinxron nusxa + almashtirish rejasi.

PACELC va kafolat xususiyatlari

CAP: split tarmogʻida C (konsistentlik) yoki A (foydalanish imkoniyati) ni tanlaymiz.
PACELC: xato boʻlmasa, Latency (L) va Consistency (C) orasidan tanlaymiz.
Pul yo’llari (balans, hisobdan chiqarish): odatda C-yo’naltirilgan (CP/strict serializable yoki Serializable + biznes-idempotentlik).
Kamroq tanqidiy quyi tizimlar (klik log, kataloglar): L-yoʻnaltirilgan (AP/EC, eventual).

Replikatsiya: amaliyotlar

Leader–Follower

Yozuvlar → etakchi, o’qish → nusxalar (read scaling).
Read-after-write: Foydalanuvchi operatsiyalari uchun yetakchi bilan o’qing yoki lag’ni kuting (tekshirish’last _ committed _ lsn ’/’ wait _ for _ replay _ lag’).
Kritik yo’llarda semi-sync (RPOni yashirin narxda kamaytirish).
Failover: avtomatik (patroni/raft-koordinator) + fencing (qoʻshaloq yetakchi boʻlmasligi uchun).

Multi-Leader

Ajratilgan domenlar va past mojaro (masalan, kontent/sozlash) uchun mos keladi, lekin maxsus choralarsiz bitta oʻyinchi hisobi uchun emas.
Merj siyosati: last-write-wins, CRDT, konsolidatsiya domen qoidalari.

Consensus/Kvorumli DB

Kvorum bilan yozish (masalan,’WRITE QUORUM’), kvorum bilan oʻqish (’READ QUORUM’) → kuchli/sozlanadigan konsistentlik.
Kvorum narxini hisobga oling.

Sharding: strategiya va kalitni tanlash

Kalitni qanday tanlash mumkin

player_id/ account_id/ bet_id bo’yicha barqaror taqsimlash.
Range-shardingda monoton kalitlardan (auto-increment) qoching - «issiq» quyruq.
To’lovlar uchun ko’pincha’player _ id’yoki’account _ id’; loglar uchun -’event _ time’+ bucketing; kontent uchun -’tenant _ id’.

Strategiyalar

player_id bo’yicha hash-sharding: stavkalar/balanslar oqimidagi balans.
Tahlillar/arxivlar uchun vaqt boʻyicha range-sharding.
Geo-sharding: EU-oʻyinchilar → EU-shard (mahalliy qonunlarga muvofiqlik).
Gibrid: mintaqa ichidagi hash + yurisdiksiya boʻyicha geo.

«Issiq» kalitlarga qarshi kurash

Key-salting (kalitga tuz/bucket qoʻshish).
Write-throttling mohiyatan, komandalar navbati (serial executor).
«Agregatlar» (balans) ni ketma-ketlik navbati bilan alohida storada materiallashtirish.

Kross-shard operatsiyalari

Pul o’tkazmalari/kompensatsiyalar: issiq yo’llarda 2PC oldini olish.
Saga-pattern: lokal tranzaksiyalarga + kompensatsiya harakatlariga, qattiq idempotentlikka va outboxga bo’lish.
2RS/kommit protokollari: nuqta (bek-ofis batchlari) bo’yicha ruxsat etiladi, lekin yashirin va ishlamay qolish chidamliligi bo’yicha qimmat.
Proyeksiyalar: domenlararo ekranlar uchun oqimdan yangilanadigan o’quvchi taqdimotlari (read models).

Sxemalar, indekslar va evolyutsiya

Sxemani versiya qilish: koddagi back-compat, feature-flags bilan migratsiya.
Shardalash kalitlari va tez-tez so’rovlar bo’yicha indekslar; cross-shard join (pre-join/denormalizatsiya) dan qochish.
JSON/dok saqlash uchun - «shovqinli» kolleksiyalar uchun sxemalarni (JSON-Schema/Protobuf) va TTLni tasdiqlang.

Onlayn masshtablash va resxarding

N ≫ joriy virtual shard (slots) → moslashuvchan rebalansni rejalashtiring.
Consistent hashing yoki yumshoq tugunlarni qoʻshish uchun «virtual nodlar».

Online-resxarding:

ikki tomonlama yozuv (eski + yangi shard), konsistentlik validatsiyasi;
chanklarning fon nusxalari (logical dump/table move/streaming clone);
«marker» + kuzatuv oynasi orqali o’zgartirish, so’ngra ikki marta yozib olish.
Rahbarning ishlamay harakatlanishi: rollarni almashtirish, konnekshenlarni drenajlash.

SLO, kuzatish va alerting

SLO yozish/oʻqish: p99 ≤ X ms issiq jadvallarda, ruxsat etilgan lag nusxalari ≤ Y soniya, foydalanish imkoniyati ≥ Z.
Metriklar: TPS, p95/p99, replication lag, ziddiyat (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency disk.
Trace:’trace _ id’DB soʻrovlarida broker/shina bilan bogʻlanadi.
Erta degradatsiya detektori uchun kanar so’rovlari va synthetic transactions.

Xavfsizlik va talablarga muvofiqlik

Tinch va tranzit shifrlash (TLS), kalitlarni almashtirish.
RBAC/ACL, domen/tenantlar bo’yicha segmentatsiya, to’lovlar uchun alohida klastyerlar/KS.
Ma’lumotlarni mahalliylashtirish (EU/TR/LATAM) - geo-sharding va retensiya siyosatlarini birlashtiring.
Audit: kim va nima o’qigan/qoidalar; PII niqoblash; audit eksporti.

Bekaplar, PITR, DR

To’liq + inkremental backaplar, ofsayt saqlash joyi.
Yetakchi klasterlar uchun PITR (point-in-time recovery).

RPO/RTO:

Tanqidiy domenlar (balans/to’lov) - RPO ≈ 0-30s (semi-sync yoki tez-tez WAL-shipping), avtomatik failover bilan ≤ daqiqa davomida RTO.
Kamroq tanqidiy - RPO daqiqa/soatgacha.
DR mashqlari (game day) va hujjatli runbook almashtirish.

Unumdorlik va tyuning (qisqacha)

Xotira/kesh: buferlarni kattalashtiring (shared buffers/innodb buffer pool), cache-hit ≥ 95% ga kuzating.
Jurnal/dvigatel: tezkor NVMe, alohida jild - WAL/redo.
Ulanish puli (PgBouncer/Hikari).
Rejalashtiruvchi/statistika: avtovanaliza/avtovakuum (Postgres), kompaksiya/tyuning GC (LSM-dvigatellar).
Kvorumlar/replika-omil: p99 va muvaffaqiyatsizlikka chidamlilik o’rtasidagi balans.

iGaming uchun namunaviy topologiyalar

1) Balanslar va to’lovlar (CP-kontur)

Leader-Follower oʻyinchi hududida, semi-sync yaqin replikaga.
’account _ id’ boʻyicha hash-sharding.
«yozuvdan keyin» o’qish - rahbardan; API-latency uchun Redisdagi proyeksiyalar.
Outbox → hisoblash/tahlil qilish uchun voqealar shinasi.

2) Stavkalar tarixi/o’yin voqealari (AP-yo’naltirilgan log)

Range-sharding/hash’player _ id’ustunli/LSM saqlash joyida.
Hisobot uchun asinxron nusxalar/OLAP.
Eventual consistency maqbul, o’tkazish qobiliyati muhimroqdir.

3) Profillar/CRM (Multi-region read, lokalizatsiya)

Yurisdiksiya bo’yicha geo-sharding, o’qish uchun lokal replikalar.
Eng yaqin rahbar orqali yozuvlar; kross-mintaqa - asinxron + mojarolarni faqat tanqidiy bo’lmagan maydonlar uchun hal qilish.

Namunalar (konseptual)

Postgres: ’player _ id’boʻyicha deklarativ sharding

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

Kvorum yozuvi (psevdo)


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

2PC o’rniga saga (soddalashtirilgan)

1. Depozitni shard-A (idempotent) ga hisobdan chiqarish.

2. To’lov xizmati (shard-B)

3. Agar 2-qadam muvaffaqiyatsiz tugasa, 1-qadamni «qaytish» hodisasi bilan qoplang.

Joriy etish chek-varaqasi

1. Maʼlumotlar va SLO domenlarini aniqlang (p99, RPO/RTO, lag replika).
2. Replikatsiya modelini (leader/follower, kvorum) va sharding strategiyasini tanlang.
3. Sharding kaliti va sxemani (oʻzgarmas!) oʻrnating.
4. Oʻqish siyosati va oʻqish marshrutini kiriting.
5. Onlayn resxarding (virtual sharlar, ikki marta yozib olish) loyihalashtiring.
6. Hodisa/buyruqlar uchun idempotentlik va outboxni kafolatlang.
7. Orqaplar, PITR, DR va muntazam mashqlarni sozlang.
8. Kuzatishni yoqing: lag, kvorumlar, issiq kalitlar, mojarolar.
9. Runbook: failover, split-brain, degradatsiyalarni hujjatlashtiring.
10. O’yin cho’qqilarida yuklash/tartibsizlik testlarini o’tkazing.

Antipatternlar

Bitta ulkan shard «hamma narsaga» va «keyin kesamiz».
So’rov yo’lidagi xoch-shard join’s.
read-after-write siyosatining yo’qligi.
Sxemalar migratsiyasi «buzuvchi» sharding kalitlari.
Mojarolarni qat’iy hal qilmasdan pul hisobvaraqlari uchun multi-leader.
Hech qanday PITR/DR mavjud emas - mantiqiy xatodan tuzalib boʻlmaydi.

Yakunlar

Replikatsiya o’qish va muvaffaqiyatsizlikka chidamlilik, sharding - yozuv va hajmni hal qiladi. iGamingdagi muvaffaqiyatli arxitektura - bu aniq SLO va PACELC murosalari, barqaror sharding kalitlari, minimal kross-shard muvofiqlashtirish (2PC o’rniga saga), read-after-write intizomi, hushyor onlayn-resxarding va muntazam DR-mashqlardir. Bunday yondashuv turnirlar cho’qqisiga ko’tariladi, ma’lumotlarni mahalliylashtirish bo’yicha tartibga soluvchi cheklovlarga bardosh beradi va foydalanishda oldindan aytib bo’lmaydi.