MongoDB və çevik məlumat sxemləri

(Bölmə: Texnologiya və Infrastruktur)

Qısa xülasə

MongoDB - çevik sxemlər (BSON), sürətli əlavələr, üfüqi miqyaslı və güclü Aggregation Pipeline ilə sənədyönümlü anbar. iGaming-də oyunçu profilləri, çevik CRM kartları, hadisə qeydləri, telemetriya, axın materiallaşdırılmış proyeksiyaları, oyun kataloqları və cəbhələr üçün cached performans üçün əladır. Pul variantları üçün (cüzdan/ledger) daha çox SQL/CP kontur qalır; MongoDB read-model və yüksək performanslı sənədli saxlama kimi uyğun gəlir.

Harada MongoDB iGaming maksimum verir

Oyunçuların profilləri və parametrləri: dəyişən strukturlar (lokal parametrlər, üstünlüklər, KYC metadata).
Məzmun/oyun/provayder kataloqları: kartların sürətli oxunması, filtrlər, etiketləmə, tam mətn.
Hadisələr/telemetriya/jurnallar: yüksək TPS, müvəqqəti pəncərələr, TTL saxlama.
Materiallaşdırılmış performans (CQRS): sürətli ekranlar (liderbordlar, son hərəkətlər, aqreqatlar).
Personalization/Fich online ML: Kolleksiyalarda KV nümunələri, qısa TTL.

Çevik sxem prinsipləri: xaos əvəzinə nizam-intizam

MongoDB «sxem olmadan» deyil - sxem kod və validasiya yaşayır.

1. Müqavilə kimi sxem: Kolleksiyalarda JSON Schema Validation.

2. 'schemaVersion' sahəsi ilə sənədlərin versiyası.

3. Ciddi məcburi sahələr (id, axtarış açarları), nadir atributların «quyruğu» - isteğe bağlıdır.

4. Massivlərin ölçüsü və daxili limiti (indekslər və RAM üçün).

5. Arxa planda miqrasiyalar: 'schemaVersion' yeniləmələri, şedulerlər, arxa filllər.

Nümunə: JSON Schema Validation

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" }
}
}
}
}
}
});

Data modeli və sənədlərin layihələndirilməsi

«Sorğu altında» layihələndirin: 1 ekran/end = 1 sənəd və ya kiçik sənəd dəsti.
Denormallaşma: kiçik alt sənədləri daxil edin (məsələn, oyun provayderlərinin mini kartları).

• Gömülmə - sıx bağlı və nadir yenilənən fraqmentlər üçün.
• Linklər ('ref') - böyük ölçülü/tez-tez yenilənən/təkrar istifadə edildikdə.
• Ölçü məhdudiyyəti: 16 MB ≤ sənəd; böyük binarniklər - GridFS/obyekt anbarları.
• Audit/meta məlumat: 'createdAt', 'updatedAt', 'traceId', 'tenantId', 'idempotencyKey'.

Indekslər: oxu keyfiyyəti və latency sabitliyi

• B-Tree (əsas)

Compound: sahələrin sırası tez-tez predikatlara və çeşidləmələrə uyğun gəlir.
Prefix-qayda: '(tenantId, playerId, createdAt)' üçün prefiks variantları işləyir.
Çeşidləmə: indeksin sonunda 'sort' qeyd edin (məsələn, 'createdAt: -1').

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

Partial / Sparse

Tez-tez olan alt çoxluqları sürətləndirir ('status:' pending ''), ölçüsünü azaldır.

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

TTL

Telemetriya/log/müvəqqəti fich üçün - avtomatik bitmə.

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

Mətn/autocomplete

'text' tam mətn üçün (dil məhdudiyyətləri); avtomatik tamamlama üçün - 'n-gram '/trigram sahələr və regex yanaşmalar və ya Atlas Search vasitəsilə.

Antipattern indeksləri

«Hər şey» indeksi → yazma sürətinin azalması.
partial → aşağı seçicilik olmadan aşağı kardinallıq.
Kompaundların təkrarlanması.
Limitsiz nəhəng massivlər daxilində sahələri indeksləşdirin.

Aggregation Pipeline: sürətli ekranlar və hesabatlar

'$match' → '$sort' → '$limit' erkən mərhələlər kimi istifadə edin; «$match/ $sort» altındakı indeksləri layihələndirin.
Nəzarət edilən joynlar üçün '$lookup' (yumşaq, ağlabatan həcmdə).
'$facet' çoxmetrika üçün; '$unionWith' - kolleksiyaların birləşməsi.
'$merge '/' $out' - kolleksiyada nəticələrin materiallaşdırılması (read-models).

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" }
} }
]);

Əməliyyatlar, uyğunluq və idempotentlik

Single-document atomic - pulsuz atom; mürəkkəb invariantlar - sənədlərin bölünməsi haqqında düşünün.
Multi-document transactions (ACID) - replika-setlər ilə mövcuddur, lakin latency daha bahalı; nöqtəli tətbiq edin.

• 'w: kritik qeydlər üçün' majority '(latency dəyəri);
• 'readConcern:' majority 'razılaşdırılmış oxumaq üçün.
• İdempotentlik: 'idempotencyKey '/' pspTx', UPSERT əməliyyatlarında unikal açarlar ('$setOnInsert', '$inc').

js db.wallet.updateOne(
{ playerId: "p123" },
{ $inc: { balanceCents: -5000 }, $set: { updatedAt: new Date() } },
{ upsert: true, writeConcern: { w: "majority" } }
);

Şardlaşdırma və açar seçimi

• Yük paylanması: yüksək kardinallıq və vahid paylanma açarı (məsələn, '(tenantId, playerId)').
• Monotonluqdan çəkinin: 'createdAt' yeganə açar → «isti» şard.

• Hashed - qeydləri daha bərabər paylayır.
• Ranged - aralıq sorğular üçün daha yaxşıdır, lakin isti quyruqları izləyin.
• Tənzimləyici/lokalizasiya (EU/LatAm/TR) üçün zona-şardinq (tag ranges).

js sh.enableSharding("igaming");
db.bets.createIndex({ tenantId: 1, playerId: 1, _id: "hashed" });
sh.shardCollection("igaming.bets", { tenantId: 1, playerId: 1, _id: "hashed" });

• Aşağı kardinallığa görə şard açarı ('status') - şard çarpazlığı.
• Tez-tez '$lookup' bir açar üçün co-charding olmadan charded kolleksiyalar arasında.
• Dəyişdirilə bilən shard key (dəyişdirmək çətin və bahadır).

Replika-set, oxu və read-after-write siyasəti

Replika-set = HA və əməliyyatların əsası.

• kritik read-after-write üçün 'primary';
• 'primaryPreferred '/' secondary' - analitik/qeyri-tənqidi üçün.
• Read/Write concern SLO və latency büdcəsi ilə razılaşdırın.

Change Streams, CDC və inteqrasiya

• cache layları sinxronizasiya (Redis),
• CRM/bildiriş tetikləyiciləri,
• OLAP yükləmələri (ClickHouse/Pinot),
• reaktiv ekranlar.
• Outbox-pattern: Kritik domenlər üçün hadisələri ayrı bir kolleksiyaya yerləşdirin, sonra konnektor oxuyur və şinə (Kafka) yayımlanır. Bu, inteqrasiyanın proqnozlaşdırılmasını artırır.

Müşahidə və SLO

SLO: p99 kart oxu ≤ 10-20 ms; hadisələri ≤ 20-40 ms; Şardlar arasındakı leytens fərqi X%; mövcudluğu ≥ 99. 9%.
Metriklər: gizli, queue depth, ikincil, cache/WT statistikası, page faults, lock-waits, açıq kursorların/birləşmələrin sayı.
Profil: 'system. profile ',' explain («executionStats») ', kolleksiyaların/indekslərin bloklanması.
Alertlər: WT cache pressure böyüməsi, yavaş əməliyyatlar, indeksə daxil olmayan sorğuların böyüməsi, ikincil geriləmə, chunk migrations/balans.

Performans və sazlama

WiredTiger Cache: default ~ 50% RAM - profil altında valid.
Compression: kolleksiyalar üçün snappy/zstd, jurnallar üçün zstd - CPU/IO balansı.
Telemetriya üçün Batch-insert və bulkWrite.
Projection ('{field: 1}') «qalın» sənədləri çəkməmək üçün.
Limit/Skip: böyük 'skip' → pagination/marker ('createdAt/_ id') istifadə edin.
Capped kolleksiyaları üçün «ring» yuvaları.

Təhlükəsizlik və uyğunluq

Auth/RBAC: kolleksiya/DB rolları, minimal lazımi imtiyazlar.
tranzit TLS, disk şifrələmə (FLE/at-rest).
PII siyasətləri: maskalanma/təxəllüs, həssas sahələr üçün ayrı-ayrı kolleksiyalar.
Multi-tenantlıq: prefikslər/ayrı-ayrı DB/kolleksiyalar, 'tenantId' filtrləri, tətbiqdə RLS kimi təbəqələr ola bilər.
Audit: Kritik kolleksiyalarda əməliyyatların auditini daxil edin.

Backup, PITR və DR

Şəkil (snapshots) cildləri + Point-in-Time Recovery üçün oplog-backup.
DR üçün başqa bir bölgədə replika-set; müntəzəm bərpa təlimləri.
Oplogun böyüməsinə nəzarət (PSP webhucks/turnirləri).
Şard-klasterlərdə - config-server ilə razılaşdırılmış backaplar.

Digər memarlıq ilə inteqrasiya

CQRS: komandalar SQL vurur (pul), hadisələr → MongoDB Materialized Views.
Event-Streaming: Kafka/Pulsar bir şin kimi, Mongo - sink/source connectors və Change Streams vasitəsilə.
Redis: ultra aşağı gecikmə təbəqəsi (caches/counters) kimi yaxındır.
OLAP: Uzun skanlar və BI üçün ClickHouse/Pinot-a boşaltma.

Giriş çek siyahısı

1. Domenləri düzəldin: nə Mongo (çevik/yüksək TPS/proyeksiyalar), nə SQL-də qalır.
2. Müəyyən schema contracts: JSON Schema Validation, 'schemaVersion'.
3. Real sorğular üçün indeksləri dizayn edin; «səs-küylü» məlumatlar üçün TTL əlavə edin.
4. Seçin shard key (yüksək kardinallıq, vahid); lazım olduqda - zone-charding.
5. SLO altında replika-set, Read/Write Concern konfiqurasiya; read-after-write siyasəti.
6. / WT cache/oplog indeksləri üçün müşahidə və profil, riskləri daxil edin.
7. Backup + PITR, DR-klaster və müntəzəm təlimlər təşkil edin.
8. Cache və şinləri sinxronlaşdırmaq üçün Change Streams/Outbox bağlayın.
9. Sənədlərin ölçüsünü və yerləşdirilməsini məhdudlaşdırın; Kursor üçün paqinasiya tətbiq edin.
10. PII/tenant, şifrələmə, audit üçün ayrı-ayrı siyasətlər.

Antipatternlər

Prodda «sxem olmadan»: validasiya və versiyaların olmaması → xaos.
Vaxt açarı/monoton - isti şard və qeyri-sabit p99.
Coynalar '$lookup' indeks/paginasiya olmadan böyük dəstlərdə.
Əməliyyat hər yerdə istifadə - performans itkisi.
Loads üçün TTL/Retance yoxdur → həcm və dəyər artımı.
ciddi idempotentlik olmadan yalnız Mongo kritik pul invariantları saxlamaq.

Nəticələr

MongoDB - iGaming çevik domenləri üçün güclü vasitədir: profillər, kataloqlar, telemetriya, proyeksiyalar və personallaşdırma. Uğur açarı - sxem-müqavilələr və validasiya, düşünülmüş indeksasiya, düzgün seçilmiş şard key, şüurlu Read/Write Concern, inteqrasiya üçün Change Streams və sərt əməliyyat intizamı (müşahidə, arxa, DR). SQL nüvəsi və axın şinası ilə birlikdə bu platformaya sürətli interfeyslər və turnir zirvələrinə sabitlik verir.