GH GambleHub

MongoDB և տվյալների ճկուն սխեմաներ

(Բաժին ՝ Տեխնոլոգիաներ և ենթակառուցվածքներ)

Ռուսական ռեզյումե

MongoDB-ը փաստագրական կենտրոնացված պահեստ է ճկուն սխեմաներով (BSON), արագ ներդիրներով, հորիզոնական մեծացումով և հզոր Aggregation Pipeline-ով։ IGaming-ում այն շատ հարմար է ռուսական խաղացողների, ճկուն CRM քարտերի, իրադարձությունների լոգարանների, հեռուստատեսության, ստրիմից նյութականացված պրոյեկտների, խաղերի կատալոգների և ճակատների համար քշված գաղափարների համար։ Դրամական ինվարանտների համար (դրամապանակներ/ledger) ավելի հաճախ մնում է SQL/CP-2019; MongoDB-ը տեղին է որպես read-model և բարձր արտադրողական փաստագրական պահեստ։


Որտեղ MongoDB-ը տալիս է առավելագույնը iGaming-ում

Ավելցուկ և ռուսական խաղացողներ 'ռուսական կառուցվածքներ (ռուսական լոկալ, նախասիրություններ, KYC-մետատվյալներ)։

Ստանդարտ և բովանդակություն/խաղեր/պրովայդերներ 'արագ կարդալ քարտերը, ֆիլտրերը, թեգավորումը, ամբողջական տեքստը։

Իրադարձություններ/հեռուստացույց/ամսագրեր 'բարձր TPS, ժամանակավոր պատուհաններ, TTL պահեստավորում։

Նյութականացված ներկայացումները (CQRS) 'արագ էկրաններ (առաջնորդներ, վերջին գործողությունները, ագրեգատները)։

Կերպարացում/ֆիչին առցանց ML: KV-pattern հավաքածուներում, կարճ TTL-ում։


Ճկուն սխեմայի սկզբունքները 'կարգապահություն քաոսի փոխարեն

MongoDB-ը «առանց սխեմայի» չէ, սխեման ապրում է կոդում և վալիդացիայում։

Խորհուրդ է տրվում

1. Սխեման որպես պայմանագիր 'JSON Schema Validation հավաքածուներում։

2. Փաստաթղթերի տարբերակումը «schemaVersion» դաշտով։

3. Խիստ պարտադիր դաշտերը (id, որոնման բանալին), հազվագյուտ ատրիբուտների «պոչը» օպոզացիոնալ է։

4. Զանգվածների և ներդրումների չափի սահմանափակումը (ինդեքսների և RAM)։

5. Ֆոնի վրա 'ապդեյտներ' schemaVersion ', գլուխգործոցներ, բեք ֆիլներ։

Օրինակ ՝ 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 փաստաթուղթ կամ փաստաթղթերի փոքր հավաքածու։

Դենորմալացում 'միացրեք փոքր ներդրված սուբյեկտները (օրինակ, խաղերի պրովայդերների մինի քարտերը)։

Հղում vs-ը կառուցում է

Տեղադրումը սերտորեն կապված և հազվադեպ նորարարված բեկորների համար է։

Հղումները («ref») մեծ չափսերով/հաճախակի apdeytes/կրկնակի օգտագործմամբ։

Չափի սահմանափակումը 'փաստաթուղթը 3616 ՄԲ; մեծ երկվորյակներ 'GridFS/օբյեկտի ձեռնարկություններ։

Աուդիտ/մետատվյալներ ՝ «createdAt», «coratedAt», «trantid Id», «tenantId», «idempotencyKey»։


Ինդեքսներ 'կարդալու որակը և www.latency

Ինդեքսների և պրակտիկայի տեսակները

B-Tree (հիմնական)

Compound: Դաշտերի կարգը համապատասխանում է հաճախակի նախադրյալներին և տեսակավորումներին։

Դելֆիքսի կանոնը '«(tenantId, playerID, createdAt)» համար աշխատում են նախածննդյան տարբերակներ։

Տեսակավորում 'հաշվի առեք «soft» -ը ինդեքսի վերջում (օրինակ ՝ «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

լրիվ տեքստի համար (լեզուների սահմանափակումներ); ավտոմատացման համար '"n-gram '/trigae դաշտի միջոցով և regex մոտեցումներով կամ Atlas Search։

Antipatterns ինդեքսներ

«Ամեն ինչի վրա» ինդեքսը բացատրում է ձայնագրման արագության անկումը։

Ցածր կարդինալությունը առանց partial-ի ցածր ընտրությունն է։

Կրկնվող կոմպաունդները։

Ինդեքսավորել դաշտերը հսկայական զանգվածների ներսում առանց սահմանների։


Aggregation Pipeline: Արագ էկրաններ և հաշվետվություններ

Օգտագործեք "match '07" դոլար sport '108' limit "որպես վաղ փուլեր։ նախագծեք ինդեքսները «match/դոլար sport»։

«lookup» դոլարը վերահսկվող ջոյների համար (փափուկ, խելացի ծավալներով)։

«Facet» -ը բազմաթիվ մետրերի համար, «unionWith» -ը հավաքածուների միավորումն է։

'merge '/' ut' - հավաքածուի արդյունքների նյութականացումը (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-ով։ կիրառել կետային։

Write Concern / Read Concern:
  • '«majority»' կրիտիկական գրառումների համար (արժեքը latency);
  • "readConcern:" majority "-ը համաձայնեցված կարդալու համար։
  • Idempotenty: յուրահատուկ բանալիներ '«idempotencyKey »/« pspTx», UPSIM վիրահատություն («setonInsport», «inc»)։

UPS.RU-ի օրինակ

js db.wallet.updateOne(
{ playerId: "p123" },
{ $inc: { balanceCents: -5000 }, $set: { updatedAt: new Date() } },
{ upsert: true, writeConcern: { w: "majority" } }
);
💡 Դրամական ինվարանտների համար սովորաբար նախընտրում են SQL-ը։ Mongo-ում միայն մրցույթի/idempotenty-ի խիստ կարգապահության և սահմանափակ գործարքների ժամանակ։

Շարդինգ և ընտրություն 2019

MongoDB-ը գնդակահարում է shard key-ով։ Ընտրությունը քննադատական է

Բեռի բաշխումը 'բարձր կարդինալության բանալին և միատեսակ բաշխումը (օրինակ' (tenantId, playerId) ")։

Խուսափեք միապաղաղությունից '«createdAt»' որպես միակ բանալին, որը համապատասխանում է «տաք» շարքին։

vs hash միջակայքերը

Hashed-ը հավասարապես բաժանում է գրառումները։

Ռանգեդը ավելի լավ է միջանկյալ հարցումների համար, բայց հետևեք տաք պոչերին։

Գոտի շարդինգը (www.ranges) կարգավորիչի/www.ru (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" });

Antipatterns

Շառդ բանալին ցածր կարդինալությամբ («status») շարիդների խաչմերուկն է։

Հաճախակի «lookup» -ը շարդիրացված հավաքածուների միջև առանց մեկ բանալին։

Փոփոխված shard key (փոխել դժվար և թանկ)։


Կրկնվող սեթեր, ընթերցանություն և քաղաքականություն read-after-write

Սեթ-սեթ = HA-ը և գործարքների հիմքը։

Read Preference:
  • «primary» քննադատական read-after-write համար;
  • «primium Diferred »/« secondary» - վերլուծաբանների համար/քննադատական։
  • Read/Write concern-ը համաձայնեցրեք SLO-ի և latency բյուջեի հետ։

Change Streams, CDC և Windows

Change Streams: բաժանորդագրությունը 2019/apdeit/2019 - հարմար է

cash շերտերի (Redis),

CRM/ծանուցումներ,

բեռնումը OLAP (ClickHouse/Pinot),

ռեակտիվ էկրաններ։

Windobox-pattern: Քննադատական օրինագծերի համար հրապարակեք իրադարձությունները առանձին հավաքածուի մեջ, որը այնուհետև կարդում է կոնեկտորը և հեռարձակվում է անվադողին (Kafka)։ Սա բարձրացնում է ինտեգրման կանխատեսելիությունը։


Դիտարկումը և SLO

SLO: p99 քարտերի ընթերցում 10-20 մզ; Իրադարձությունների ցանկը 20-40 մզ է։ Լեյտենսիի տարբերությունը շարդի միջև X% -ի սահմաններում։ հասանելիությունը 3699 է։ 9%.

Մետրիկները ՝ op-լատինականություն, queue depth, ymps տոկոսը ստացիոնար, cache/WT վիճակագրություններ, page faul.ru, ww.k-waits, col-ում բաց կուրսորների/w.ru։

Ավելացումը '' 108։ profile "," "executionStats" ", հավաքածուների/ինդեքսների արգելափակումը։

Ալերտներ 'WT cache pressure, դանդաղ վիրահատություններ, որոնք չեն հասել հարցումների ինդեքսին, մնացորդային, chunk migram/հավասարակշռություն։


Արտադրողականություն և թյունինգ

WiredTiger Cache-ը 'լռելյայն 50 տոկոսը RAM-ն է' վալիդիրիրալացրեք պրոֆիլի տակ։

Compression: wwww.appy/zstd հավաքածուների համար, ամսագրերի համար zstd - CPU/IO հավասարակշռություն։

Batch-2019 և bulkWrite հեռուստացույցի համար։

Project ("" field: 1 + ") որպեսզի չշեղվի" հաստ "փաստաթղթեր։

Limit/Skip: Խուսափեք մեծ 'skip 'ts օգտագործեք դասընթացի/մարկերով («createdAt/_ id»)։

Capped հավաքածուներ «օղակաձև» լոգարանների համար։


Անվտանգություն և ընկերակցություն

Auth/RBAC 'հավաքածուի/BD դերերը, նվազագույն անհրաժեշտ արտոնություններ։

TLS-ը տրանզիտում, կոդավորումը (FLE/at-rest)։

PII քաղաքականությունները 'դիմակավորում/կեղծանունացում, անհատական հավաքածուներ զգայուն դաշտերի համար։

Multi-tenanty: prefics/առանձին BD/հավաքածուներ, ֆիլտրեր '«tenantid», դուք կարող եք RMS նման շերտեր։

Աուդիտ 'միացրեք վիրահատությունների աուդիտը քննադատական հավաքածուներում։


Bakaps, PITR և DR

Նկարները (wwww.apshots) հատորների + oplog-bakaps-ի համար Point-in-Time Recovery-ի համար։

Կրկնվող սեթը մեկ այլ տարածքում DR-ի համար։ Վերականգնման ուսմունքները։

Oplog աճի վերահսկումը ներդիրների պիկի տակ (PMS webhuki/delra)։

Շարդ կլաստերում 105 բեքապներ են ՝ 108-104։


Ինտեգրումը մնացած ճարտարապետության հետ

CQRS 'թիմերը ծեծում են SQL (գումար), MongoDB-ում Materialized Views-ի իրադարձությունները։

Event-Streaming: Kafka/Pulsar որպես անվադողեր, Mongo-sink/source կոնեկտորների և Change Streams-ի միջոցով։

Redis: Մոտակայքում է ուլտրա-ցածր լատենտության շերտը (kashi/հաշվիչներ)։

OLAP 'բեռնումը ClickHouse/Pinot-ում երկար սկանների և BI-ի համար։


Ներդրման չեկի ցուցակ

1. Ամրագրեք օրինագծերը 'ինչ է կատարվում Mongo-ում (ճկուն/բարձր TPS/պրոյեկտներ), որը մնում է SQL-ում։

2. Preschema 24rac.ru: JSON Schema Validation, «schemaVersion»։

3. Նախագծեք ինդեքսները իրական հարցումների համար։ Ավելացրեք TL-ը «աղմկոտ» տվյալների համար։

4. Ընտրեք shard key (բարձր կարդինալություն, հավասարություն); անհրաժեշտության դեպքում 'zone-sharding։

5. Պարեք սեթ, Read/Write Concern SLO-ի տակ։ read-after-write քաղաքականությունը։

6. Միացրեք դիտարկումը և ավելացումը, ալտերտերը ինդեքսների վրա/WT cache/oplog։

7. Կազմակերպեք bakaps + PITR, DR կլաստեր և տեխնոլոգիական ուսուցումներ։

8. Միացրեք Change Streams/Disbox-ը քեշի և անվադողերի համաժամացման համար։

9. Սահմանափակեք փաստաթղթերի չափը և ներդրումը։ կիրառեք դասընթացի վարագույրը։

10. Առանձին քաղաքականություններ PII/tenants, ծածկագրում, աուդիտ։


Antipatterns

«Առանց սխեմայի» վաճառքում 'վալիդացիայի և տարբերակների բացակայությունը քաոս է։

Ժամանակի Շարդ բանալին/մոնոտոնը տաք գնդակ է և անկայուն p99։

Ջոյնի «դոլար lookup» -ը հսկայական հավաքածուներում առանց ինդեքսների/երգեցողության։

Օգտագործեք գործարքները ամենուր 'արտադրողականության կորուստ։

TTL/logs-ի բացակայությունը բացատրում է ծավալի և արժեքի աճը։

Պահել կրիտիկական կարևոր դրամավարկներ միայն Mongo-ում առանց խիստ կուռքի։


Արդյունքները

MongoDB-ը հզոր գործիք է iGaming-ի ճկուն ածխաջրածինների համար 'պրոֆիլներ, կոդեր և հեռուստաչափություն, պրոյեկտներ և կերպարներ։ Հաջողության բանալին սխեման պայմանագրերն ու վալիդացիան են, մտածված ինդեքսավորումը, գրագետ www.shard key, գիտակցված Read/Write Concern, Change Streams ինտեգրման համար և կոշտ վիրահատական կարգապահություն (դիտարկումը, bekaps, DR)։ SQL միջուկի և սթրիմինգի անվադողերի հետ միասին դա տալիս է արագ ինտերֆեյսեր և կայունություն էքսպրեսորային պիկի տակ։

Contact

Կապ հաստատեք մեզ հետ

Կապ հաստատեք մեզ հետ ցանկացած հարցի կամ աջակցության համար։Մենք միշտ պատրաստ ենք օգնել։

Սկսել ինտեգրացիան

Email-ը՝ պարտադիր է։ Telegram կամ WhatsApp — ըստ ցանկության։

Ձեր անունը ըստ ցանկության
Email ըստ ցանկության
Թեմա ըստ ցանկության
Նամակի բովանդակություն ըստ ցանկության
Telegram ըստ ցանկության
@
Եթե նշեք Telegram — մենք կպատասխանենք նաև այնտեղ՝ Email-ի дополнение-ով։
WhatsApp ըստ ցանկության
Ձևաչափ՝ երկրի կոդ և համար (օրինակ՝ +374XXXXXXXXX)։

Սեղմելով կոճակը՝ դուք համաձայնում եք տվյալների մշակման հետ։