GH GambleHub

MongoDB ve esnek veri şemaları

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

Kısa Özet

MongoDB, esnek devreler (BSON), hızlı ekler, yatay ölçeklendirme ve güçlü Toplama Boru Hattı ile belge odaklı bir depolamadır. IGaming'de, oyuncu profilleri, esnek CRM kartları, olay günlükleri, telemetri, materyalize akış projeksiyonları, oyun katalogları ve önbelleğe alınmış ön görünümler için mükemmeldir. Parasal değişmezler için (cüzdanlar/defter), SQL/CP konturu daha sık bırakılır; MongoDB, okuma modeli ve yüksek performanslı belge depolama alanı olarak uygundur.

MongoDB'nin iGaming'den en iyi şekilde yararlandığı yer

Oynatıcı profilleri ve ayarları: yapı değişkenleri (yerel ayar ayarları, tercihler, KYC meta verileri).
İçerik/oyunlar/sağlayıcı katalogları: hızlı kart okuma, filtreler, etiketleme, tam metin.
Olaylar/telemetri/günlükler: yüksek TPS, zaman pencereleri, TTL depolama.
Materyalize Görünümler (CQRS): hızlı ekranlar (lider tabloları, son eylemler, kümeler).
Kişiselleştirme/özellikler çevrimiçi ML: Koleksiyonlarda KV kalıpları, kısa TTL.

Esnek bir planın ilkeleri: kaos yerine disiplin

MongoDB "şemasız" değildir - şema kod ve doğrulama içinde yaşar.

Tavsiye edilen:

1. Sözleşme olarak şema: Koleksiyonlarda JSON Şema Doğrulaması.

2. Belgelerin 'schemaVersion' alanıyla sürüm oluşturma.

3. Sıkı zorunlu alanlar (id, arama anahtarları), nadir özelliklerin "kuyruğu" - isteğe bağlı.

4. Dizi boyutlarını ve iç içe geçmeyi sınırlar (dizinler ve RAM için).

5. Arka plandaki geçişler: 'schemaVersion', shedulers, back fills ile güncellemeler.

Örnek: JSON Şema Doğrulaması

js db. createCollection("player_profiles", {
validator: {
$jsonSchema: {
bsonType: "object",
required: ["playerId", "createdAt", "schemaVersion"],
properties: {
playerId: { bsonType: "string" },
createdAt: { bsonType: "date" },
schemaVersion: { bsonType: "int", minimum: 1 },
locale: { bsonType: "string" },
kyc: {
bsonType: "object",
properties: {
status: { enum: ["pending", "verified", "rejected"] },
doc: { bsonType: "object" }
}
}
}
}
}
});

Veri modeli ve belge tasarımı

"Talep üzerine" tasarım: 1 ekran/uç nokta = 1 belge veya küçük bir belge kümesi.
Denormalizasyon: Ekli küçük altdokumentler ekleyin (örneğin, oyun sağlayıcılarının mini kartları).

Bağlar vs gömme:
  • Gömme - yakından ilişkili ve nadiren güncellenen parçalar için.
  • Referanslar ('ref') - büyük boyut/sık güncellemeler/yeniden kullanım için.
  • Boyut sınırı: belge ≤ 16 MB; Büyük ikili dosyalar - GridFS/nesne depoları.
  • Denetim/meta veriler: 'CreatedAt', 'updatedAt', 'traceId', 'tenantId', 'idempotencyKey'.

Dizinler: okuma kalitesi ve gecikme kararlılığı

Dizin türleri ve uygulamaları:
  • B-Ağacı (birincil)

Bileşik: Alanların sırası sık yüklemlere ve sıralamalara karşılık gelir.
Önek kuralı: önek seçenekleri '(tenantId, playerId, createdAt)' için çalışır.
Sıralama: Dizinin sonundaki 'sıralama'yı düşünün (örneğin,' createdAt: -1 ').

js db. bets. createIndex(
{ tenantId: 1, playerId: 1, createdAt: -1 },
{ name: "idx_bets_tenant_player_created_desc" }
);

Kısmi/Seyrek

Sık kullanılan alt kümeleri hızlandırın ('durum:' beklemede ''), boyutu küçültün.

js db. withdrawals. createIndex(
{ playerId: 1, createdAt: -1 },
{ partialFilterExpression: { status: "pending" } }
);

TTL

Telemetri/günlükler/geçici özellikler için - otomatik son kullanma.

js db. events. createIndex({ expireAt: 1 }, { expireAfterSeconds: 0 });

Metin/otomatik tamamlama

Tam metin için 'metin' (dil kısıtlamaları); Otomatik tamamlama için - alanlar ve regex yaklaşımları veya Atlas Search aracılığıyla'n-gram'/trigram.

İndeks antipatternleri

"Tüm" indeksi - yazma hızında bir düşüş.
Kısmi olmayan düşük kardinalite - düşük seçicilik.
Bileşik kopyaları.
Sınırsız dev dizilerin içindeki dizin alanları.

Toplama Boru Hattı: Hızlı Ekranlar ve Raporlar

Erken aşamalar olarak '$ match' - '$ sort' - '$ limit' kullanın; '$ match/$ sort' altında proje dizinleri.
Kontrollü joynes için '$ arama' (yumuşak, makul hacimlerde).
Birden fazla metrik için '$ facet'; '$ unionWith' - koleksiyonları birleştirin.
'$ merge'/' $ out' - koleksiyondaki sonuçları gerçekleştirir (okuma modelleri).

Örnek: son oyuncu bahisleri + kasa:
js db. bets. aggregate([
{ $match: { tenantId: "eu-1", playerId: "p123" } },
{ $sort: { createdAt: -1 } },
{ $limit: 100 },
{ $group: {
_id: "$playerId",
lastBets: { $push: { amount: "$amount", ts: "$createdAt", game: "$gameId" } },
totalAmount: { $sum: "$amount" }
} }
]);

İşlemler, tutarlılık ve idempotency

Tek belgeli atomik - serbest atomisite; karmaşık değişmezler - belge bölümlemeyi düşünün.
Çok belgeli işlemler (ACID) - çoğaltma setleriyle kullanılabilir, ancak gecikmede daha pahalıdır; noktasal olarak uygulayın.

Endişe Yaz/Endişe Oku:
  • 'w: "majority" 'for critical records (latency cost);
  • 'readConcern: "majority"' tutarlı okuma için.
  • Idempotency: 'idempotencyKey'/' pspTx' üzerindeki benzersiz anahtarlar, UPSERT işlemleri ('$ setOnInsert', '$ inc').
UPPERT örneği:
js db. wallet. updateOne(
{ playerId: "p123" },
{ $inc: { balanceCents: -5000 }, $set: { updatedAt: new Date() } },
{ upsert: true, writeConcern: { w: "majority" } }
);
💡 Parasal değişmezler için genellikle SQL tercih edilir. Mongo'da - sadece sıkı anahtar/idempotence disiplini ve sınırlı işlemlerle.

Sharding ve anahtar seçimi

MongoDB, shard anahtarına göre parçalar. Seçim kritiktir:
  • Yük dağılımı: yüksek kardinalite anahtarı ve tekdüze dağıtım (örneğin, '(tenantId, playerId)').
  • Monotonluktan kaçının: Tek anahtar olarak 'At' yaratıldı - "sıcak" parça.
Aralıklar vs hash:
  • Hashed - kayıtları daha eşit dağıtır.
  • Range, aralık sorguları için daha iyidir, ancak sıcak kuyrukları izleyin.
  • Düzenleme/yerelleştirme için etiket aralıkları (EU/LatAm/TR).
Örnek:
js sh. enableSharding("igaming");
db. bets. createIndex({ tenantId: 1, playerId: 1, _id: "hashed" });
sh. shardCollection("igaming. bets", { tenantId: 1, playerId: 1, _id: "hashed" });
Antipatterns:
  • Düşük kardinaliteye göre Shard-key ('durum') - parçaların eğrilmesi.
  • Shardy koleksiyonları arasında sık sık '$ arama', bir seferde bir anahtar olmadan.
  • Değiştirilebilir parça anahtarı (değiştirilmesi zor ve pahalı).

Replica setleri, okur ve okuduktan sonra yazma politikası

Replika seti = HA ve işlem temeli.

Tercihi Oku:
  • Eleştirel okuma-yazma için 'birincil';
  • 'primaryPreferred'/' secondary' - analitik/kritik olmayan için.
  • Okuma/Yazma endişesi, SLO ve gecikme bütçesi ile koordine edilir.

Değişim Akışları, CDC ve Entegrasyonlar

Akışları Değiştir: ekleme/güncelleme/silme aboneliği - aşağıdakiler için uygundur:
  • Önbellek katmanı senkronizasyonu (Redis)
  • CRM tetikleyicileri/bildirimleri,
  • OLAP'a indirme (ClickHouse/Pinot),
  • reaktif ekranlar.
  • Giden kutusu deseni: kritik etki alanları için, olayları ayrı bir koleksiyona yayınlayın; bağlayıcı daha sonra okur ve veri yoluna (Kafka) çevirir. Bu, entegrasyonların öngörülebilirliğini arttırır.

Gözlemlenebilirlik ve SLO

SLO: p99 kart okuma ≤ 10-20 ms; 20-40 ms ≤ olayların eklenmesi; X % içindeki parçalar arasındaki leutency farkı; kullanılabilirlik ≥ 99. 9%.
Metrikler: op-latency, kuyruk derinliği, ikincil başına yumru yüzdesi, önbellek/WT istatistikleri, sayfa hataları, kilit beklemeleri, açık imleçlerin/bağlantıların sayısı.
Profil oluşturma: 'sistem. profile ',' explain ("executionStats") ', toplama/dizin kilitleri.
Uyarılar: WT önbellek basıncının büyümesi, yavaş işlemler, endekste yer almayan taleplerin büyümesi, ikincil taleplerin birikmesi, yığın geçişleri/dengeleyici.

Performans ve ayarlama

WiredTiger Önbellek: varsayılan olarak ~ %50 RAM - profil için doğrulayın.
Sıkıştırma: Koleksiyonlar için snappy/zstd, günlükler için zstd - CPU/IO dengesi.
Toplu ekler ve topluTelemetri için yaz.
"Kalın" belgeleri sürüklememek için projeksiyon ('{alan: 1}').
Limit/Skip: Büyük 'skip' kullanmaktan kaçının - imleç/işaretleyici sayfalama kullanın ('createdAt/_ id').
"Ring" günlükleri için sınırlı koleksiyonlar.

Güvenlik ve uyumluluk

Auth/RBAC: koleksiyon/veritabanı üzerindeki roller, minimum gerekli ayrıcalıklar.
TLS aktarım halinde, diskte şifreleme (FLE/at-rest).
PII politikaları: maskeleme/aliasing, hassas alanlar için ayrı koleksiyonlar.
Çoklu kiracılık: ön ekler/bireysel veritabanları/koleksiyonlar, 'tenantId' filtreleri, uygulamada RLS benzeri katmanlar yapabilirsiniz.
Denetim: Kritik koleksiyonlardaki işlemlerin denetlenmesini sağlar.

Yedeklemeler, PITR ve DR

Birimlerin anlık görüntüleri + Point-in-Time Recovery için oplog yedeklemeleri.
DR için başka bir bölgede kopya seti; Düzenli kurtarma egzersizleri.
Ekleme zirveleri için oplog büyümesinin kontrolü (PSP webhooks/turnuvalar).
Parça kümelerinde - yapılandırma sunucusuyla tutarlı yedeklemeler.

Mimarinin geri kalanıyla entegrasyon

CQRS: teams hit SQL (money), events - Materialized Views in MongoDB.
Olay Akışı: Otobüs olarak Kafka/Pulsar, Mongo - konektörler ve Change Streams aracılığıyla lavabo/kaynak.
Redis: ultra düşük gecikme katmanı (önbellekler/sayaçlar) olarak yakın.
OLAP: uzun taramalar ve BI için ClickHouse/Pinot'a yükleyin.

Uygulama kontrol listesi

1. Fix etki alanları: Mongo'da ne olur (esnek/yüksek TPS/projeksiyon), SQL'de ne kalır.
2. Şema sözleşmelerini tanımlayın: JSON Schema Validation, 'schemaVersion'.
3. Gerçek sorgular için tasarım endeksleri; Gürültülü veriler için TTL ekleyin.
4. Parça anahtarını seçin (yüksek kardinalite, tekdüzelik); Gerekirse - zone-sharding.
5. Bir çoğaltma seti kurun, SLO için Okuma/Yazma Endişesi; Yazma sonrası okuma politikası.
6. Gözlemlenebilirliği ve profillemeyi ,/WT önbellek/oplog indeksleri için uyarıları etkinleştirin.
7. Yedeklemeleri organize edin + PITR, DR kümesi ve düzenli egzersizler.
8. Önbellekleri ve veri yollarını senkronize etmek için Değişim Akışları/Giden Kutusu'nu bağlayın.
9. Belge boyutunu ve iç içe geçirmeyi sınırlayın; İmleç ile sayfalama uygula.
10. PII/kiracılar için ayrı politikalar, şifreleme, denetim.

Anti-desenler

Üründe "şema yok": doğrulama ve sürüm eksikliği - kaos.
Zaman/monoton Shard anahtar - sıcak parça ve kararsız p99.
Joynes '$ lookup' indekssiz/sayfasız büyük setlerde.
İşlemleri her yerde kullanın - üretkenlik kaybı.
Günlükler için TTL/retentions eksikliği - hacim ve maliyet artışı.
Kritik parasal değişmezleri yalnızca Mongo'da sıkı idempotency olmadan saklayın.

Özet

MongoDB, esnek iGaming etki alanları için güçlü bir araçtır: profiller, dizinler, telemetri, projeksiyonlar ve kişiselleştirme. Başarının anahtarı bir sözleşme şeması ve doğrulama, düşünceli indeksleme, iyi seçilmiş bir parça anahtarı, bilinçli Okuma/Yazma Endişesi, entegrasyonlar için Değişim Akışları ve sıkı operasyonel disiplindir (gözlemlenebilirlik, yedeklemeler, DR). SQL çekirdeği ve akış veriyolu ile birleştirildiğinde, bu, platforma hızlı arayüzler ve turnuva zirveleri için istikrar sağlar.

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.