Verilənlər bazasının şardinqi və replikasiyası

(Bölmə: Texnologiya və Infrastruktur)

Qısa xülasə

iGaming platformaları üçün trafik artımı (dərəcələr, depozitlər, PSP vebhukları, oyun hadisələri) və mövcudluq tələbləri (≈ 99. 9–99. 99%) bir DB həddinə tez düşür. Replikasiya üfüqi oxu miqyası və pozulma müqaviməti verir; sharding - yazı və məlumatların üfüqi miqyası. Açar - şüurlu kompromislər PACELC (imtina sonra: CA/P, əks halda: Latency vs Consistency), aydın SLO və nizam-intizam sxemləri/açarları.

Şərtlər və modellər

Replikasiya - düyünlər arasında məlumatların kopyalanması.

Leader-Follower (Primary-Replica): bir yazı → çox oxunur.
Multi-Leader (Active-Active): bir neçə regionda qeydlər, münaqişələr/merj.
Consensus-replication (Raft/Paxos, NewSQL): kvorum qeydləri (Cassandra/Scylla - AP-kvorumlar, CockroachDB/Yugabyte - CP-kvorumlar).
Sync/Semi-sync/Async: gecikmə balansı vs RPO.
Şardinq - cədvəllərin/açarların üfüqi bölünməsi.

Hash-charding (vahid, daha çətin diapazonlar).
Range-charding (açar diapazonları, «isti» ucların riski).
Consistent hashing (yumşaq əlavə/yumşaq nod).
Geo-şardinq (region/yurisdiksiya üzrə).
Funksional şardinq (domenlər üzrə: ödənişlər/dərəcələr/CRM).

iGaming-də nə vaxt və nə seçmək lazımdır

Yalnız replikasiya (charding olmadan) - əsas oxu problemi olduqda: hadisə lentləri, hesabatlar, ictimai kataloqlar. Qeydlər bir liderə, oxu isə replikalardan yerləşdirilir.
Charding - dar qeyd/saxlama yeri olduqda: bahis axını, balans əməliyyatları, tetikleyici hadisələr.

Multi-region:

Oyunçulara gecikmə/PSP → replikalardan yerli oxunmalar.
Tənzimləyici (məlumat lokalizasiyası) → geo-çardinq.
Regionlararası DR → asenxron replika + keçid planı.

PACELC və zəmanət xüsusiyyətləri

CAP: split şəbəkədə C (tutarlılıq) və ya A (mövcudluq) seçirik.
PACELC: uğursuzluqlar olmadıqda Latency (L) və Consistency (C) arasında seçim.
Pul yolları (balans, silinmə): adətən C-yönümlü (CP/strict serializable və ya serializable + business idempotent).
Az kritik alt sistemlər (klik log, kataloqlar): L-yönümlü (AP/EC, eventual).

Replikasiya: praktikalar

Leader–Follower

Qeydlər → lider, oxu → replikalar (read scaling).
Read-after-write: istifadəçi əməliyyatları üçün lider ilə oxuyun və ya laq (yoxlama 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Kritik yollarda Semi-sync (gecikmə qiyməti ilə RPO azaldılması).
Failover: avtomatik (patroni/raft-koordinator) + fencing (ikili lider yoxdur).

Multi-Leader

Bölünmüş domenlər və aşağı münaqişə (məsələn, məzmun/konfiqurasiya) üçün uyğundur, lakin xüsusi tədbirlər olmadan oyunçunun vahid hesabı üçün deyil.
Merj siyasətləri: last-write-wins, CRDT, domen konsolidasiya qaydaları.

Consensus/Kvorum DB

Kvorum ilə yazma (məsələn, 'WRITE QUORUM'), kvorum ilə oxumaq ('READ QUORUM') → güclü/xüsusi tutarlılıq.
AZ/regionlar arasında gecikməni və kvorumun dəyərini nəzərə alın.

Sharding: strategiyalar və açar seçimi

Açarı necə seçmək olar

Sabit player_id/ account_id/ bet_id paylanması.
Range-şardinqdə monoton açarlardan (auto-increment) çəkinin - «isti» quyruq.
Ödənişlər üçün - tez-tez 'player _ id' və ya 'account _ id'; log üçün - 'event _ time' + bucketing; məzmun üçün - 'tenant _ id'.

Strategiyalar

Hash-charding player_id: bahis/balans axını balans.
Analitika/arxivlər üçün Range-charding.
Geo-charding: EU oyunçular → EU-chard (yerli qanunlara uyğunluq).
Hibrid: bölgədə hash + yurisdiksiyasına görə geo.

«Qaynar» açarları ilə mübarizə

Key-salting (açara duz/bucket əlavə edin).
Write-throttling mahiyyətcə, sıra komandalar (serial executor).
«Aqreqatları» (balansı) bir sıra ilə ayrı bir storada materiallaşdırmaq.

Xaç-şard əməliyyatları

Pul köçürmələri/kompensasiyalar: isti yollarda 2PC qarşısını almaq.
Saga-pattern: yerli əməliyyatlar bölünür + kompensasiya hərəkətləri, sərt idempotent və outbox.
2RS/kommit protokolları: nöqtəli (arxa ofis batçları), lakin gecikmə və pozulma müqaviməti baxımından bahalıdır.
Proyeksiyalar: streaming yenilənmiş domenlərarası ekranlar üçün oxucu təqdimatları (read models).

Sxemlər, indekslər və təkamül

Sxem versiyası: kodda back-compat, feature-flags ilə miqrasiya.
Şardlaşdırma açarları və tez-tez sorğular üzrə indekslər; cross-shard join-dən qaçın (pre-join/denormalizasiya edin).
JSON/dok-saxlama üçün - «səs-küylü» kolleksiyalar üçün sxemləri (JSON-Schema/Protobuf) və TTL-ni təsdiqləyin.

Onlayn miqyas və resharding

N ≫ cari virtual şard sayı (slots) → çevik rebalance planlaşdırın.
Yumşaq düyün əlavə etmək üçün Consistent hashing və ya «virtual nodes».

Online resharding:

ikiqat qeyd (köhnə + yeni şard), sabitlik validasiyası;
çanaqların fon surətləri (logical dump/table move/streaming clone);
«marker» + müşahidə pəncərəsi ilə keçid, sonra ikiqat qeyd.
Liderin fasiləsiz hərəkət etməsi: rolların dəyişdirilməsi, konnekşenlərin drenajı.

SLO, müşahidə və alertinq

SLO yazma/oxu: p99 ≤ X ms isti cədvəllərdə, icazə verilən lag replikaları ≤ Y saniyə, mövcudluq ≥ Z.
Metriklər: TPS, p95/p99, replication lag, ziddiyyət (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency disk.
Tracking: DB sorğularında 'trace _ id', broker/lastik hadisələri ilə əlaqələndirin.
Erkən deqradasiya detektoru üçün kanarya sorğuları və synthetic transactions.

Təhlükəsizlik və tələblərə uyğunluq

Sülh və tranzit şifrələmə (TLS), açarların rotasiyası.
RBAC/ACL, domen/tenant seqmentasiyası, ödənişlər/KOS üçün ayrı-ayrı klasterlər.
Məlumatların lokalizasiyası (EU/TR/LATAM) - geo-şardinq və retensiya siyasətlərini birləşdirin.
Audit: kim və nə oxumaq/qaydaları; PII maskalanması; audit ixracı.

Backup, PITR, DR

Tam + artımlı arxalar, ofsayt saxlama.
Lider klasterlər üçün PITR (point-in-time recovery).

RPO/RTO:

Kritik domenlər (balans/ödəniş) - RPO ≈ 0-30s (semi-sync və ya tez-tez WAL-shipping), avtomatik failover ilə ≤ dəqiqə RTO.
Daha az kritik - dəqiqə/saat qədər RPO.
DR-təlim (game day) və sənədli runbook keçid.

Performans və sazlama (qısa)

Yaddaş/cache: buferləri artırın (shared buffers/innodb buffer pool), cache-hit ≥ 95% izləyin.
Jurnal/mühərrik: sürətli NVMe, WAL/redo altında ayrı bir cild.
Bağlantı hovuzu (PgBouncer/Hikari).
Planlaşdırıcı/statistika: avtovanaliz/avtovakum (Postgres), kompaksiya/sazlama GC (LSM mühərrikləri).
Kvorumlar/replika faktoru: p99 və arıza müqaviməti arasında balans.

iGaming üçün tipik topologiyalar

1) Balans və ödənişlər (CP-kontur)

Oyunçu regionda lider-Follower, yaxın replika üçün semi-sync.
Hash-charding 'account _ id'.
«Yazıdan sonra» oxunması - liderdən; API-latency üçün Redis proyeksiyaları.
Outbox → hesablamalar/analitika üçün şin hadisələr.

2) Bahis tarixi/oyun hadisələri (AP-yönümlü log)

Range-charding və ya hash 'player _ id' sütun/LSM-saxlama.
Hesabat üçün asinxron replikalar/OLAP.
Eventual consistency məqbuldur, daha vacib bant genişliyi.

3) Profillər/CRM (Multi-region read, lokalizasiya)

Yurisdiksiya üzrə geo-şardinq, oxumaq üçün yerli replikalar.
Ən yaxın lider vasitəsilə qeydlər; cross-region - asenxron + münaqişələrin həlli yalnız kritik olmayan sahələr üçün.

Nümunələr (konseptual)

Postgres: 'player _ id' üçün deklarativ şardinq

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 (psevdo)


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

2PC əvəzinə saga (sadələşdirilmiş)

1. Şard-A (idempotent) depozitini silin.
2. Hadisəni göndərin «çıxarıldı» → ödəniş xidməti (şard-B).
3. 2-ci addım uğursuz olarsa, 1-ci addımı «geri dönüş» hadisəsi ilə kompensasiya edin.

Giriş çek siyahısı

1. Məlumat domenlərini və SLO-ları (p99, RPO/RTO, lag replica) təyin edin.
2. Replikasiya modelini (leader/follower, kvorum) və şərdinq strategiyasını seçin.
3. Charding açarları və sxemi düzəldin (dəyişməz!).
4. read-after-write siyasətini və oxu marşrutunu daxil edin.
5. Onlayn resharding (virtual şard, ikiqat qeyd) dizayn edin.
6. Hadisələr/komandalar üçün idempotentlik və outbox təmin edin.
7. Backup, PITR, DR və müntəzəm təlimləri qurun.
8. Müşahidə qabiliyyətini daxil edin: laq, kvorumlar, qaynar açarlar, münaqişələr.
9. Runbook sənədləşdirin: failover, split-brain, deqradasiya.
10. Matç zirvələri altında yükləmə/xaos testləri aparın.

Antipatternlər

Bir nəhəng şard «hər şeyə» və «sonra kəsin».
Qaynar sorğu yolunda cross-chard join's.
read-after-write siyasəti yoxdur (üzən yük).
Sxemlərin miqrasiyası «sındırıcı» şardinq açarları.
Ciddi münaqişə qətnaməsi olmadan pul hesabları üçün Multi-lider.
No PITR/DR - məntiqi səhvdən sağalmaq mümkün deyil.

Nəticələr

Replikasiya oxu və pozulma müqavimətini, charding - yazıları və həcmi həll edir. iGaming-də uğurlu memarlıq aydın SLO və PACELC kompromisləri, sabit şərdinq açarları, minimum xaç-şərd koordinasiyası (2PC əvəzinə saga), read-after-write nizam-intizamı, yaxşı qurulmuş online resharding və müntəzəm DR təlimləridir. Bu yanaşma turnirlərin zirvələri altında ölçülür, məlumatların lokallaşdırılması ilə bağlı tənzimləyici məhdudiyyətlərə tab gətirir və istismarda proqnozlaşdırıla bilən olaraq qalır.