MongoDB და მოქნილი მონაცემთა სქემები

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

MongoDB არის დოკუმენტზე ორიენტირებული საცავი მოქნილი სქემებით (BSON), სწრაფი ჩანართებით, ჰორიზონტალური მასშტაბებით და ძლიერი აგრეგაციის მილით. IGaming- ში ეს შესანიშნავია მოთამაშეთა პროფილებისთვის, მოქნილი CRM ბარათები, მოვლენების ლოგოები, ტელემეტრია, სტრიმისგან დამზადებული მატერიალური პროგნოზები, თამაშების კატალოგები და ფრონტებისთვის დახურული წარმოდგენები. ფულადი ინვარიანტებისთვის (საფულეები/ლედგერი), SQL/CP წრე უფრო ხშირად რჩება; MongoDB მიზანშეწონილია, როგორც read მოდელი და მაღალი ხარისხის დოკუმენტური საცავი.

სადაც MongoDB მაქსიმუმს აძლევს iGaming- ს

მოთამაშეთა პროფილები და პარამეტრები: ცვლადი სტრუქტურა (ლოკალური პარამეტრები, პრეფერენციები, KYC მეტამონაცემები).
შინაარსის/თამაშების/პროვაიდერების კატალოგები: ბარათების სწრაფი კითხვა, ფილტრები, ტეგირება, სისრულე.
მოვლენები/ტელემეტრია/ჟურნალები: მაღალი TPS, დროებითი ფანჯრები, TTL შენახვა.
მატერიალიზებული წარმოდგენები (CQRS): სწრაფი ეკრანები (ლიდერები, უახლესი მოქმედებები, დანაყოფები).
პერსონალიზაცია/ფიჩები ონლაინ ML: KV ნიმუშები კოლექციებში, მოკლე TTL.

მოქნილი სქემის პრინციპები: დისციპლინა ქაოსის ნაცვლად

MongoDB არ არის „სქემის გარეშე“ - სქემა ცხოვრობს კოდში და ვალიდაციაში.

რეკომენდებულია:

1. სქემა, როგორც კონტრაქტი: JSON Schema ვალიდაცია კოლექციებში.

2. „schemaVersion“ - ის მიერ დოკუმენტების ვერსია.

3. მკაცრი სავალდებულო ველები (id, ძიების გასაღებები), იშვიათი ატრიბუტების „კუდი“ არჩევითია.

4. მასივებისა და ინვესტიციების განზომილების შეზღუდვა (ინდექსებისთვის და RAM).

5. მიგრაცია ფონზე: schemaVersion ', shedulers, სარეზერვო ფილები.

მაგალითი: 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" }
}
}
}
}
}
});

მონაცემთა მოდელი და დოკუმენტების დიზაინი

დაპროექტეთ „მოთხოვნის ქვეშ“: 1 ეკრანი/ენდპოინტი = 1 დოკუმენტი ან დოკუმენტების მცირე ნაკრები.
დენორმალიზაცია: ჩართეთ მცირე ინვესტირებული ქვე-დოკუმენტები (მაგალითად, თამაშების პროვაიდერების მინი ბარათები).

ბმულები:

ინტეგრაცია - მჭიდროდ დაკავშირებული და იშვიათად განახლებული ფრაგმენტებისთვის.
ბმულები ('ref') - დიდი ოდენობით/ხშირი აპდეიტებით/განმეორებით გამოყენებით.
ზომების შეზღუდვა: დოკუმენტი 16 MB; დიდი ბინარი - GridFS/ობიექტის საცავი.
აუდიტი/მეტამონაცემები: 'createdAt', 'განახლება', 'traceId', 'tenantId', 'idempotencyKey'.

ინდექსები: კითხვისა და სტაბილურობის ხარისხი

ინდექსებისა და პრაქტიკის ტიპები:

B-Tree (ძირითადი)

კომპოზიცია: ველების რიგი შეესაბამება ხშირი პრედიკატებსა და დახარისხებას.
Prefix წესი: „(tenantId, playerId, createdAt)“ პრეფიქსი პარამეტრები.
დალაგება: მხედველობაში მიიღეთ 'შემდეგი' ინდექსის ბოლოს (მაგალითად, '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' სრული ტექსტისთვის (შეზღუდვები ენებზე); ავტომობილების დასრულებისთვის - 'n-gram '/trigram ველებით და რეგექსის მიდგომებით ან Atlas Search.

ინდექსების საწინააღმდეგო

ინდექსი „ყველაფრისთვის“ არის ჩაწერის სიჩქარის ვარდნა.
დაბალი კარდინალობა პარტიული - დაბალი სელექციურობა.
სარეზერვო კომპოზიციები.
გიგანტური მასივების შიგნით მინდვრების ინდექსირება ლიმიტების გარეშე.

Aggregation Pipeline: სწრაფი ეკრანები და მოხსენებები

გამოიყენეთ 'match' აშშ დოლარი 'sort' აშშ დოლარი '$ limit', როგორც ადრეულ ეტაპზე; შეიმუშავეთ ინდექსები 'match/$ sort'.
'lookup' აშშ დოლარი კონტროლირებადი ჯოინებისთვის (რბილი, გონივრული მოცულობით).
'facet' მრავალჯერადი მეტრიკისთვის; '$ UnionWith' - კოლექციების ასოციაცია.
'აშშ დოლარი '/' $ out' - შედეგების მატერიალიზაცია კოლექციაში (read მოდელები).

მაგალითი: მოთამაშის უახლესი განაკვეთები + თაღი:

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 - უფასო ატომური; რთული ინვარიანტები - იფიქრეთ დოკუმენტების დაყოფაზე.
მრავალჯერადი დოკუმენტაციის თარგმანები (ACID) - არსებობს რეპლიკების ნაკრები, მაგრამ უფრო ძვირია, ვიდრე ლათინური; გამოიყენეთ წერტილოვანი.

Write Concern / Read Concern:

'w: „majority“ კრიტიკული ჩანაწერებისთვის (ლატენტობის ღირებულება);
'readConcern: „majority“ შეთანხმებული კითხვისთვის.
Idempotence: უნიკალური გასაღებები 'idempotencyKey '/' pspTx', UPSERT ოპერაციები ('SetOnInsert', '$ inc').

UPSERT- ის მაგალითი:

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

💡 ფულადი ინვარიანტებისთვის, ჩვეულებრივ, SQL ურჩევნიათ. მონგოში - მხოლოდ მკაცრი გასაღების/იდემპოტენტურობის დისციპლინით და შეზღუდული გარიგებებით.

შარდვა და კლავიშების არჩევა

MongoDB shard key. არჩევანი კრიტიკულია:

დატვირთვის განაწილება: მაღალი კარდინალობის გასაღები და ერთგვაროვანი განაწილება (მაგალითად, '(tenantID, playerId)').
მოერიდეთ ერთფეროვნებას: 'createdAt', როგორც ერთადერთი გასაღები - „ცხელი“ ხიბლი.

დიაპაზონი hash:

Hashed - თანაბრად ანაწილებს ჩანაწერებს.
Ranged უკეთესია დიაპაზონის მოთხოვნებისთვის, მაგრამ თვალყური ადევნეთ ცხელ კუდებს.
ზონა-შარდინგი (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 Preference:

"primary 'კრიტიკული read-after-write;
'primariPreferred '/' საიდუმლო "- ანალიტიკოსებისთვის/არა კრიტიკული.
Read/Write Concern კოორდინაციას უწევს SLO და latency ბიუჯეტს.

Change Streams, CDC და ინტეგრაცია

Change Streams: ჩანართების/აფდიტების/მოცილების გამოწერა მოსახერხებელია:

ქეშის სინქრონიზაცია (Redis),
CRM/შეტყობინებების გამომწვევი,
ჩამოტვირთვა OLAP- ში (ClickHouse/Pinot),
თვითმფრინავის ეკრანები.
Outbox ნიმუში: კრიტიკული დომენებისთვის, გამოაქვეყნეთ მოვლენები ცალკეულ კოლექციაში, რომელსაც შემდეგ კითხულობს კონექტორი და გადასცემს საბურავებს (კაფკა). ეს ზრდის ინტეგრაციის პროგნოზირებას.

დაკვირვება და SLO

SLO: ბარათის 99 კითხვა 10-20 ms; მოვლენების ჩანართები 20-40 ms; ლეიტენსიის განსხვავება შარდს შორის X% -ში; ხელმისაწვდომობა 99. 9%.
მეტრიკა: op-latence, queue depth,% იუმფის მეორეხარისხოვანი, cache/WT სტატისტიკა, page faults, lock-waits, ღია კურსორების/კავშირების რაოდენობა.
პროფილირება: 'სისტემა. profile ',' explain („Executionstats“) ', კოლექციების/ინდექსების დაბლოკვა.
ალერტები: WT cache pressure- ის ზრდა, ნელი ოპერაციები, მოთხოვნების ზრდა, რომლებიც არ შედიოდა ინდექსში, მეორეხარისხოვანი, chunk migrations/ბალანსის ჩამორჩენა.

პროდუქტიულობა და tuning

WiredTiger Cache: ნაგულისხმევი ~ 50% RAM - გადაადგილება პროფილის ქვეშ.
Compression: snappy/zstd კოლექციებისთვის, ჟურნალებისთვის zstd - ბალანსი CPU/IO.
Batch ჩანართები და bulkWrite ტელემეტრიისთვის.
Projection ('{field: 1') ისე, რომ არ გადაიტანოს „სქელი“ დოკუმენტები.
Limit/Skip: თავიდან აიცილეთ დიდი „skip“ - გამოიყენეთ პაგინაცია კურსორის/მარკერის მიხედვით („createdAt/_ id“).
Capped კოლექცია „ბეჭედი“ ლოგებისთვის.

უსაფრთხოება და შესაბამისობა

Auth/RBAC: როლები კოლექციებზე/BD, მინიმალური აუცილებელი შეღავათები.
TLS ტრანზიტში, დისკზე დაშიფვრა (FLE/at-rest).
PII პოლიტიკოსები: შენიღბვა/ფსევდონიმი, ცალკეული კოლექციები მგრძნობიარე სფეროებისთვის.
მრავალ ტენანტობა: პრეფიქსი/ინდივიდუალური DD/კოლექციები, „tenantId“ ფილტრები, შეგიძლიათ RLS- ის მსგავსი ფენები განაცხადში.
აუდიტი: ჩართეთ ოპერაციების აუდიტი კრიტიკულ კოლექციებზე.

Bacaps, PITR და DR

სურათები (snapshots) ტომი + oplog bacaps Point-in-Time Recovery- ისთვის.
რეპლიკა სხვა რეგიონში DR- სთვის; რეგულარული აღდგენის სწავლებები.
oplog- ის ზრდის კონტროლი ჩანართების მწვერვალებისთვის (PSP ვებჰუკი/ტურნირები).
შარდის მტევნებში - შეთანხმებული ქუდები config სერვერთან.

ინტეგრაცია დანარჩენ არქიტექტურასთან

CQRS: გუნდები სცემეს SQL (ფული), MongoDB- ში Materialized Views- ის მოვლენები.
Event-Streaming: Kafka/Pulsar, როგორც საბურავი, Mongo - sink/source მეშვეობით კონექტორები და Change Streams.
Redis: იქვე, როგორც ულტრა დაბალი ლატენტობის ფენა (ქეში/მრიცხველები).
OLAP: გადმოტვირთვა ClickHouse/Pinot- ში გრძელი სკანირებისა და BI- სთვის.

განხორციელების შემოწმების სია

1. დაფიქსირეთ დომენები: რა ხდება მონგოში (მოქნილი/მაღალი TPS/პროექციები), რომელიც რჩება SQL- ში.
2. დაადგინეთ schema კონტრაქტები: JSON Schema Validation, 'schemaVersion'.
3. შეიმუშავეთ ინდექსები რეალური მოთხოვნებისთვის; დაამატეთ TTL ხმაურიანი მონაცემებისთვის.
4. შეარჩიეთ shard key (მაღალი კარდინალობა, ერთგვაროვნება); საჭიროების შემთხვევაში - zone sharding.
5. რეპლიკების ნაკრები, Read/Write Concern SLO- ს ქვეშ; Read-after-write პოლიტიკა.
6. ჩართეთ დაკვირვება და პროფილირება, ალერტები ინდექსებზე/WT cache/oplog.
7. მოაწყეთ bacaps + PITR, DR მტევანი და რეგულარული წვრთნები.
8. დააკავშირეთ Change Streams/Outbox ქეშისა და საბურავების სინქრონიზაციისთვის.
9. შეზღუდეთ დოკუმენტების ზომა და ინვესტიცია; შემოიღეთ კურსორის პაგინაცია.
10. ცალკეული პოლიტიკოსები PII/ტენანტებისთვის, დაშიფვრა, აუდიტი.

ანტიპატერები

„სქემის გარეშე“ გაყიდვაში: სავალდებულო და ვერსიების არარსებობა - ქაოსი.
დროის შარდის გასაღები/ერთფეროვანი - ცხელი ხუჭუჭა და არასტაბილური p99.
ჯოინი „დოლარი lookup“ უზარმაზარ კომპლექტებში ინდექსების/პაგინაციის გარეშე.
ყველგან გამოიყენეთ გარიგებები - პროდუქტიულობის დაკარგვა.
TTL/retention- ის ნაკლებობა ლოგებისთვის არის მოცულობისა და ღირებულების ზრდა.
კრიტიკულად მნიშვნელოვანი ფულადი ინვარიანტების შენახვა მხოლოდ მონგოში მკაცრი იდემპტენტურობის გარეშე.

შედეგები

MongoDB არის ძლიერი ინსტრუმენტი iGaming მოქნილი დომენებისთვის: პროფილები, კატალოგები, ტელემეტრია, პროექცია და პერსონალიზაცია. წარმატების გასაღებია კონტრაქტების სქემა და შესაბამისობა, გააზრებული ინდექსაცია, კომპეტენტურად შერჩეული shard key, შეგნებული Read/Write Concern, Change Streams ინტეგრაციისთვის და მკაცრი ოპერაციული დისციპლინა (დაკვირვება, ზურგჩანთები, DR). SQL ბირთვთან და ნაკადის ავტობუსთან ერთად, ეს პლატფორმას აძლევს სწრაფ ინტერფეისებს და სტაბილურობას ტურნირის მწვერვალებისთვის.