MongoDB жана ийкемдүү маалымат схемалары

(Бөлүк: Технология жана инфраструктура)

Кыскача резюме

MongoDB - ийкемдүү схемалар менен документ-багытталган сактоо (BSON), тез киргизүү, горизонталдуу масштабдоо жана күчтүү Агрегация түтүк. iGaming бул оюнчулар, ийкемдүү CRM карталары, иш-чаралардын логдору, телеметрия, агымынын материалдык проекциялары, оюн каталогдору жана frontes үчүн кэш-шоу үчүн сонун. Акча инварианттары үчүн (капчыктар/ledger) көбүнчө SQL/CP контур бойдон калууда; MongoDB окуу-модель жана жогорку аткаруу документ сактоо катары ылайыктуу болуп саналат.

Кайда MongoDB iGaming максималдуу берет

Оюнчулардын профилдери жана жөндөөлөрү: өзгөрүлмө түзүлүштөр (жергиликтүү жөндөөлөрү, артыкчылыктары, KYC метадеректери).
Мазмун/оюн/провайдерлердин каталогдору: карталарды тез окуу, чыпкалар, тегдөө, толук текст.
Events/Telemetry/журналдар: жогорку TPS, убактылуу терезелер, TTL сактоо.
Материализацияланган көрүнүшү (CQRS): тез экрандар (алдыңкы такталар, акыркы аракеттер, агрегаттар).
Персоналдаштыруу/Fich Online ML: Коллекцияларда KV үлгүлөрү, кыска TTL.

Ийкемдүү схеманын принциптери: башаламандыктын ордуна тартип

MongoDB "схемасы жок" эмес - схема коддо жана валидацияда жашайт.

1. Контракт катары схема: Коллекцияларда JSON Schema Validation.

2. Документтерди 'schemaVersion' талаасы менен версиялоо.

3. Катуу милдеттүү талаалар (ID, издөө ачкычтары), сейрек кездешүүчү атрибуттардын "куйругу" - кошумча.

4. Массивдердин жана тиркемелердин өлчөмүн чектөө (индекстер жана RAM үчүн).

5. алкагында миграциялар: 'schemaVersion' боюнча апдейттер, шедулерлер, бэк-филлер.

Мисал: JSON схемасы 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" }
}
}
}
}
}
});

Маалыматтар модели жана документтерди долбоорлоо

"Суроо-талапка ылайык" долбоорлоо: 1 экран/эндпойнт = 1 документ же документтердин чакан топтому.
Denormisionalization: чакан кошумча документтерди (мисалы, оюн провайдерлеринин мини-карталары) камтыйт.

• Интеграция - тыгыз байланышкан жана сейрек жаңыртылган фрагменттер үчүн.
• Шилтемелер ('ref') - чоң өлчөмдө/тез-тез жаңыртып/кайра колдонууда.
• Өлчөм чектөө: 16 МБ ≤ документ; ири бинарники - GridFS/объект сактоо.
• Аудит/метадеректер: 'createdAt', 'updatedAt', 'traceId', 'tenantId', 'idempotencyKey'.

Индекстер: сапаттуу окуу жана туруктуулук latency

• B-Tree (негизги)

Compound: талаа тартиби тез-тез предикаттар жана сорттоо менен дал келет.
Префикс эрежеси: '(tenantId, playerId, createdAt)' үчүн префиксдик варианттар иштейт.
Сорттоо: индексинин аягында 'sort' эске алуу (мисалы, 'createdAt: -1').

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

Partial / Sparse

Көп кездешүүчү субтитрлер ('status:' pending ''), көлөмүн азайтат.

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

TTL

Телеметрия/логдор/убактылуу сыныктар үчүн - автоматтык түрдө аяктоо.

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

Текст/autocomplete

'text' толук текст үчүн (тилдер боюнча чектөөлөр); Auto толуктоо үчүн - талаалар жана regex ыкмалары же Atlas издөө аркылуу 'n-gram '/trigram.

Индекстерге каршы

"Бардык" индекси → жазуу ылдамдыгынын төмөндөшү.
partial жок төмөн кардиналдуулук → төмөн тандоо.
Компаунд.
Чектөөсүз алп массивдердин ичиндеги талааларды индекстөө.

Aggregation Pipeline: тез экрандар жана отчеттор

'$match' → '$sort' → '$limit' колдонуңуз; "$match/ $sort" боюнча индекстерди долбоорлоо.
'$lookup' контролдонуучу джойндор үчүн (жумшак, акылга сыярлык көлөмдө).
'$facet' көп метриктер үчүн; '$unionWith' - жыйнактарды бириктирүү.
'$merge '/' $out' - коллекциядагы жыйынтыктарды материалдаштыруу (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" }
} }
]);

Транзакциялар, ырааттуулук жана демпотенттүүлүк

Single-document atomic - акысыз атомдук; татаал инварианттар - документтерди бөлүү жөнүндө ойлонуп көрүңүз.
Multi-document transactions (ACID) - репликалар менен бар, бирок latency боюнча кымбатыраак; максаттуу колдонуу.

• 'w: "majority"' критикалык жазуулар үчүн (latency наркы);
• 'readConcern:' majority 'макулдашылган окуу үчүн.
• Демпотенттик: уникалдуу ачкычтар 'idempotencyKey '/' pspTx', UPSERT-иш ('$setOnInsert', '$inc').

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

Шардана жана ачкычтарды тандоо

• Жүктү бөлүштүрүү: жогорку кардиналдык жана бирдей бөлүштүрүү ачкычы (мисалы, '(tenantId, playerId)').
• Монотондуулуктан качыңыз: 'createdAt' жалгыз ачкыч катары → "ысык" шард.

• Hashed - жазууларды бирдей бөлүштүрөт.
• Түстүү - диапазондук суроолор үчүн жакшы, бирок ысык куйруктарды ээрчип.
• Зона-шардинг (tag ranges) жөнгө салуу/локалдаштыруу үчүн (EU/LatAm/TR).

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

• Төмөнкү кардиналдуулугу боюнча Шард ачкычы ('status') - шардалардын кыйшаюусу.
• Тез-тез '$lookup' бир ачкыч менен биргелешип шардарлоо жок жыйнактардын ортосунда.
• Өзгөрүлмө shard key (алмаштыруу кыйын жана кымбат).

Реплика-топтомдор, окуу жана саясат read-after-write

Реплика-сет = HA жана транзакциялардын негизи.

• критикалык read-after-write үчүн 'primary';
• 'primaryPreferred '/' secondary' - аналитика/сын эмес.
• Read/Write concern SLO жана latency бюджети менен макулдашуу.

Change Streams, CDC жана интеграция

• кэш катмарларын синхрондоштуруу (Redis),
• CRM триггерлери/билдирүүлөр,
• OLAP жүктөмөлөр (ClickHouse/Pinot),
• реактивдүү экрандар.
• Outbox үлгү: критикалык домендер үчүн, андан кийин connector окуп жана шинага (Kafka) берүү өзүнчө чогултуу боюнча иш-чараларды жарыялайт. Бул интеграциянын алдын ала аныктыгын жогорулатат.

Байкоо жана SLO

SLO: p99 карталарды окуу ≤ 10-20 мс; окуялар киргизүү ≤ 20-40 ms; X% чегинде шардалардын ортосундагы лейтенсинин айырмасы; жеткиликтүүлүгү ≥ 99. 9%.
Метриктер: оп-латенттүүлүк, queue depth,% юмпс боюнча экинчилик, cache/WT статистика, page faults, lock-waits, ачык курсорлор/байланыштар саны.
Профилдөө: 'system. profile ',' explain ("executionStats") ', жыйнактарды/индекстерди бөгөттөө.
Alerts: WT cache pressure өсүшү, жай иш-аракеттер, индекске түшпөгөн суроо-талаптардын өсүшү, экинчилик артта калуу, chunk migrations/балансы.

Аткаруу жана тюнинг

WiredTiger Cache: демейки ~ 50% RAM - профилине ылайык тастыктоо.
Compression: чогултуу үчүн snappy/zstd, журналдар үчүн zstd - CPU/IO балансы.
Batch-киргизүү жана bulkWrite үчүн телеметрия.
Projection ('{field: 1}') "калың" документтерди сүйрөп эмес.
Limit/Skip: чоң 'skip' → курсор/маркер боюнча пагинацияны колдонуңуз ('createdAt/_ id').
Capped жыйнактары үчүн "шакек" казык.

Коопсуздук жана комплаенс

Auth/RBAC: чогултуу/DD ролдору, минималдуу зарыл артыкчылыктар.
Транзитте TLS, дискте шифрлөө (FLE/at-rest).
PII саясаты: маскировка/псевдонимизациялоо, сезимтал талаалар үчүн өзүнчө коллекциялар.
Multitenanthy: префикстер/жеке DD/чогултуу, filters 'tenantId', колдонмодо RLS окшош катмарлар болушу мүмкүн.
Аудит: маанилүү чогултуу боюнча иш аудит кирет.

Backup, PITR жана DR

Сүрөттөр (snapshots) томдору + Point-in-Time Recovery үчүн oplog-backup.
DR үчүн башка аймакта реплика-комплект; үзгүлтүксүз калыбына келтирүү машыгуулары.
Oplog өсүшүн контролдоо (PSP Webhucks/турнирлер).
Шард-кластерлерде - config-сервер менен макулдашылган бэкаптар.

Калган архитектура менен интеграция

CQRS: командалар SQL уруп (акча), окуялар → MongoDB Materialized Views.
Event-Streaming: Kafka/шина катары Pulsar, Mongo - sink/source connectors жана Change Streams аркылуу.
Redis: өтө төмөн жашыруун катмар катары жакын (кэш/эсептегичтер).
OLAP: узак сканер жана BI үчүн ClickHouse/Pinot жүктөө.

Киргизүүнүн чек-тизмеси

1. Домендерди бекитүү: Mongo (ийкемдүү/жогорку TPS/проекциялар), бул SQLде калат.
2. Аныктоо схемасы contracts: JSON схемасы Validation, 'schemaVersion'.
3. Реалдуу суроо-талаптарга индекстерди долбоорлоо; "ызы-чуу" маалыматтар үчүн TTL кошуу.
4. Тандоо shard key (жогорку кардиналдуулук, бир калыпта); зарыл болсо - zone-шардинг.
5. SLO үчүн реплика-комплект, Read/Write Concern; read-after-write саясаты.
6. / WT cache/oplog индекстерине байкоо жана профилин, алерттерди киргизиңиз.
7. Backup + PITR, DR-кластер жана үзгүлтүксүз машыгууларды уюштуруу.
8. Кэш жана шиналарды синхрондоштуруу үчүн Change Streams/Outbox туташтырыңыз.
9. Документтердин көлөмүн жана жайгаштырууну чектөө; курсор боюнча пагинацияны киргизиңиз.
10. PII/тенанттар үчүн өзүнчө саясат, шифрлөө, аудит.

Антипаттерндер

"Схемасы жок" тукумунда: валидация жана версиялардын жоктугу → башаламандык.
Убакыт ачкычы/монотондук - ысык жана туруксуз p99.
Джойна '$lookup' индекстери/пагинациясы жок чоң топтомдордо.
Бардык жерде транзакцияларды колдонуу - өндүрүмдүүлүктү жоготуу.
Логдор үчүн TTL/Retenia жоктугу → көлөмү жана наркы өсүшү.
өтө маанилүү акча инварианттар гана Mongo катуу боштондук жок сактоо.

Жыйынтыктар

MongoDB - ийкемдүү iGaming домендери үчүн күчтүү курал: профилдер, каталогдор, телеметрия, проекциялар жана персоналдаштыруу. Ийгиликтин ачкычы - схема-контракттар жана валидация, ойлонулган индекстөө, туура тандалган shard key, аң-сезимдүү Read/Write Concern, интеграция үчүн Change Streams жана катуу эксплуатациялык тартип (байкоо, backup, DR). SQL ядро ​ ​ жана агымдык шиналар менен айкалышып, бул аянтчага тез интерфейстерди жана турнирдик чокуларга туруктуулукту берет.