GH GambleHub

Veritabanı Parçalama ve Çoğaltma

(Bölüm: Teknoloji ve Altyapı)

Kısa özet

IGaming platformları için trafik artışı (bahisler, depozitolar, PSP web kitapları, oyun etkinlikleri) ve kullanılabilirlik gereksinimleri (≈99. 9–99. %99) hızla bir DB sınırına ulaştı. Çoğaltma, yatay okuma ölçeklemesi ve hata toleransı sağlar; Sharding - kayıt ve verilerin yatay ölçeklendirilmesi. Anahtar, PACELC'in bilinçli tavizleridir (başarısızlıktan sonra: CA/P, aksi takdirde: Gecikme vs Tutarlılık), açık SLO'lar ve şema/anahtar disiplini.


Şartlar ve modeller

Replikasyon - Verileri siteler arasında kopyalar.

Leader-Follower (Primary-Replica): Bir giriş çok okunur.
Multi-Leader (Active-Active): çeşitli bölgelerdeki girişler, çakışmalar/birleştirme.
Consensus-replication (Raft/Paxos, NewSQL): quorum kayıtları (Cassandra/Scylla - AP quorus, CockroachDB/Yugabyte - CP quorus).
Sync/Semi-sync/Async: RPO'ya karşı gecikme dengesi.
Parçalama - tabloların/anahtarların parçalara göre yatay bölünmesi.

Hash-sharding (tekdüzelik, daha sert aralıklar).
Menzil-sharding (anahtar aralıkları, sıcak son riski).
Tutarlı karma.
Geo-sharding (bölgeye/yetki alanına göre).
Fonksiyonel sharding (etki alanına göre: ödemeler/oranlar/CRM).


IGaming'de ne zaman ve ne seçilir

Yalnızca çoğaltma (parçalama yok) - ana sorun okuma olduğunda: olay akışları, raporlar, genel dizinler. Kayıtlar bir lidere yerleştirilir, kopyalardan okunur.
Sharding - yazma/tutma darboğazı: kur akışı, bilanço işlemleri, tetikleyici olaylar.

Çok bölgeli:
  • Oynatıcı/PSP gecikmesi - replikalardan yerel okumalar.
  • Düzenleme (veri lokalizasyonu) - coğrafi sharding.
  • Bölgelerarası DR - asenkron kopya + geçiş planı.

PACELC ve garanti özellikleri

CAP: bölünmüş bir ağ ile, C (tutarlılık) veya A (kullanılabilirlik) seçin.
PACELC: Hata yoksa, Gecikme (L) ve Tutarlılık (C) arasında seçim yapın.
Nakit yolları: genellikle C odaklı (CP/sıkı serializable veya Serializable + iş idempotency).
Daha az kritik alt sistemler (günlük tıklamaları, dizinler): L odaklı (AP/EC, nihai).


Çoğaltma Uygulamaları

Lider-Takipçi

Yazar - lider, okur, - ölçeklemeyi okur.
Read-after-write: kullanıcı işlemleri için, liderden okuyun veya lag bekleyin ('last _ committed _ lsn'/' wait _ for _ replay _ lag' işaretleyin).
Kritik yollarda yarı senkronizasyon (gecikme maliyetinde RPO azaltma).
Yük devretme: otomatik (patroni/sal koordinatörü) + eskrim (böylece çift lider olmaz).

Çoklu Lider

Bölünmüş alanlar ve düşük çatışma için uygundur (örn. İçerik/ayarlar), ancak özel önlemler olmadan tek bir oyuncu hesabı için değil.
Birleştirme ilkeleri: Son yazma kazancı, CRDT, etki alanı birleştirme kuralları.

Consensus/Quorum Veritabanları

Quorum write (örn. 'WRITE QUORUM'), quorum read ('READ QUORUM') - güçlü/yapılandırılabilir tutarlılık.
AZ/bölge arası gecikme ve çekirdek maliyetini göz önünde bulundurun.


Sharding: Stratejiler ve Anahtar Seçimler

Bir anahtar nasıl seçilir

player_id/ account_id/ bet_id göre kararlı dağılım.
Menzil ayırmada monoton tuşlardan (otomatik artırım) kaçının - "sıcak" kuyruk.
Ödemeler için - genellikle 'player _ id' veya 'account _ id'; Günlükler için - 'event _ time' + bucketing; İçerik için - 'tenant _ id'.

Strateji

player_id tarafından hash-sharding: oran/bakiye akışı üzerinde denge.
Analitik/arşivler için aralık tabanlı zaman tabanlı sharding.
Geo-sharding: EU oyuncuları - EU-shard (yerel yasalara uygunluk).
Hibrit: Bölge içinde karma + yetki alanına göre coğrafi.

Sıcak tuşlarla mücadele

Anahtar tuzlama (anahtara tuz/kova ekleyin).
Yazma kısma aslında bir komut kuyruğudur (seri yürütücü).
Bir sıra kuyruğu ile ayrı bir satırda "agregalar" (denge) gerçekleştirin.


Çapraz parça işlemleri

Para transferi/tazminat: Sıcak pistlerde 2PC kaçının.
Saga modeli: yerel işlemlere + telafi edici eylemlere, sabit idempotans ve giden kutusuna ayrılır.
2PC/commit protokolleri: izin verilen nokta (arka ofis partileri), ancak gecikme ve hata toleransı açısından pahalıdır.
Projeksiyonlar: Alanlar arası ekranlar için okuma modelleri, akıştan güncellendi.


Şemalar, endeksler ve evrim

Şema sürüm oluşturma: back-compat'tan geçişler, koddaki özellik bayrakları.
Sharding tuşları ve sık sorgular üzerindeki indeksler; Çapraz parça birleştirmesinden kaçının (ön birleştirme/denormalleştirme yapın).
JSON/yerleştirme depoları için - "gürültülü" koleksiyonlar için şemaları (JSON-Schema/Protobuf) ve TTL'yi doğrulayın.


Çevrimiçi ölçeklendirme ve yeniden harding

Sanal parça (yuva) sayısını N≫tekushcheye için plan yapın - esnek yeniden dengeleme.
Yumuşak düğüm ekleme için tutarlı karma veya'sanal düğümler ".

Online Yeniden Şekillendirme:
  • Çift giriş (eski + yeni parça), tutarlılık doğrulaması;
  • Parçaların arka plan kopyaları (mantıksal döküm/tablo taşıma/akış klonu);
  • "Marker" + gözlem penceresi ile değiştirin, ardından çift kayıt yapın.
  • Kesinti olmadan lideri taşıma: rolleri değiştirme, bağlantıları boşaltma.

SLO, gözlemlenebilirlik ve uyarı

SLO yazma/okuma: Sıcak masalarda p99 ≤ X ms, geçerli gecikme kopyaları ≤ Y saniye, kullanılabilirlik ≥ Z.
Metrikler: TPS, p95/p99, replikasyon gecikmesi, çoklu lider, yeniden deneme hızı, kilitlenmeler, kilit bekleme, önbellek isabet oranı, IOPS/gecikme diski.
Trace: Veritabanı isteklerinde 'trace _ id', broker/event bus ile ilişkilendirme.
Bozulmanın erken tespiti için kanarya sorguları ve sentetik işlemler.


Güvenlik ve Uyumluluk

Dinlenme ve geçiş sırasında şifreleme (TLS), anahtar rotasyonu.
RBAC/ACL, etki alanına/kiracıya göre segmentasyon, ödemeler/LCC için ayrı kümeler.
Veri yerelleştirme (EU/TR/LATAM) - geo-sharding ve retention politikalarını birleştirir.
Denetim: kim ve ne okur/kurallar; PII maskeleme; Denetim dışa aktarma.


Yedeklemeler, PITR, DR

Tam + artımlı yedeklemeler, tesis dışı depolama.
Lider kümeleri için PITR (point-in-time recovery).

RPO/RTO:
  • Kritik etki alanları (denge/ödeme) - RPO≈0 -30'lar (yarı senkronize veya sık sık WAL gönderimi), otomatik yük devretme ile ≤ dakika RTO.
  • Daha az kritik - dakika/saate kadar RPO.
  • DR egzersizleri (oyun günü) ve belgelenmiş bir anahtar runbook.

Performans ve ayarlama (kısa)

Bellek/önbellek: arabellekleri artırın (paylaşılan arabellekler/innodb arabellek havuzu), önbellek isabetli ≥ %95 izleyin.
Dergi/motor: Hızlı NVMe, WAL/redo altında ayrı hacim.
Bağlantı havuzu (PgBouncer/Hikari).
Planlayıcı/istatistik: otomatik analiz/otomatik vakum (Postgres), GC sıkıştırma/ayarlama (LSM motorları).
Quorum/replica factor: p99 ve hata toleransı arasındaki denge.


IGaming için tipik topolojiler

1) Bakiyeler ve ödemeler (CP-loop)

Oyuncunun bölgesindeki Lider-Takipçi, yakın bir replikaya yarı senkronize.
'Account _ id'ile hash-sharding.
Okumalar "yazdıktan sonra" - liderden; API-gecikme için Redis'e projeksiyonlar.
Giden kutusu - hesaplamalar/analizler için olay yolu.

2) Bahis geçmişi/oyun etkinlikleri (AP odaklı log)

Sütun/LSM depolamada 'player _ id'ile zamana veya hash'e göre aralık-sharding.
Raporlama/OLAP için asenkron kopyalar.
Nihai tutarlılık kabul edilebilir, bant genişliği daha önemlidir.

3) Profiller/CRM (Çok bölgeli okuma, yerelleştirme)

Yetki alanına göre coğrafi paylaşım, okumalar için yerel kopyalar.
En yakın liderden girişler; Bölgeler arası - yalnızca kritik olmayan alanlar için eşzamansız + çakışma çözümü.


Örnekler (kavramsal)

Postgres: 'player _ id'tarafından bildirimsel 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)';

Quorum kaydı (sözde)


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

2PC yerine Saga (basitleştirilmiş)

1. Depozitoyu shard-A'ya (idempotent) yazın.
2. "Kaldırıldı" etkinliğini gönder - ödeme hizmeti (shard-B).
3. 2. adım başarısız olursa, 1. adımı bir "return" olayı ile telafi edin.


Uygulama kontrol listesi

1. Veri etki alanlarını ve SLO'ları tanımlayın (p99, RPO/RTO, çoğaltma günlüğü).
2. Çoğaltma modelini (lider/takipçi, çekirdek) ve parçalama stratejisini seçin.
3. Sharding anahtarlarını ve şemayı düzeltin (değişmez!).
4. Yazma sonrası okuma ilkesi ve okuma yönlendirmesi yazın.
5. Tasarım çevrimiçi yeniden şekillendirme (sanal parçalar, çift giriş).
6. Olaylar/komutlar için idempotency ve giden kutusu sağlayın.
7. Yedeklemeler, PITR, DR ve düzenli egzersizler ayarlayın.
8. Gözlemlenebilirliği içerir: lag, quorum, hot key, çakışmalar.
9. Doküman çalışma kitabı: yük devretme, bölünmüş beyin, bozulma.
10. Maç tepe noktaları altında yük/kaos testleri gerçekleştirin.


Anti-desenler

Dev bir parça'her şey için've "sonra kes".
Parçalar arası birleşme isteğin sıcak bir şekilde.
Yazma sonrası okuma politikası yok (yüzen hatalar).
Şemaların göçleri "kırma" sharding anahtarları.
Katı çatışma çözümü olmayan nakit hesaplar için çoklu lider.
PITR/DR yok - Mantıksal hatadan kurtarılamıyor.


Sonuçlar

Çoğaltma okuma ve esnekliği çözer, parçalama yazma ve hacim çözer. İGaming'deki başarılı mimari, açık SLO ve PACELC tavizleri, kararlı sharding anahtarları, minimum çapraz parça koordinasyonu (2PC yerine saga), yazma sonrası okuma disiplini, iyi işleyen çevrimiçi yeniden şekillendirme ve düzenli DR egzersizleridir. Bu yaklaşım, turnuva zirvelerine ölçeklenir, veri yerelleştirme konusundaki düzenleyici kısıtlamalara dayanır ve operasyonda öngörülebilir kalır.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.