תרשימי MongoDB ונתונים גמישים

(סעיף: טכנולוגיה ותשתיות)

סיכום קצר

MongoDB (ראשי תיבות של: MongoDB) הוא מתקן אחסון עם מעגלים גמישים (BSON). ב-iGaming, הוא מצוין עבור פרופילי שחקנים, קלפי CRM גמישים, יומני אירועים, טלמטריה, תחזיות זרם ממשיות, קטלוגי משחקים, ותצוגות מקדימה. עבור אינווריאנטים כספיים (ארנקים/פנקס), קונטור SQL/CP הוא לעתים קרובות יותר; MongoDB מתאים כמודל קריאה ואחסון מסמכים בעלי ביצועים גבוהים.

איפה מונגודב עושה את המירב של iGaming

פרופילי שחקן והגדרות: משתני מבנה (הגדרות מיקום, העדפות, metadata KYC).
קטלוגים של תוכן/משחקים/ספקים: קריאה מהירה בכרטיסים, מסננים, תיוג, טקסט מלא.
אירועים/טלמטריה/יומנים: TPS גבוה, חלונות זמן, אחסון TTL.
תצוגות ממשיות (CQRS): מסכים מהירים (לוחות מובילים, פעולות אחרונות, אגרגטים).
התאמה אישית/מאפיינים מקוונים של ML: תבניות KV באוספים, TTL קצר.

עקרונות של תוכנית גמישה: משמעת במקום כאוס

MongoDB הוא לא ”בלי מזימה” - המזימה חיה בקוד ואימות.

1. סכימה כחוזה: JSON Schema Idiation באוספים.

2. מסמכי ורסינינג עם שדה 'schemaVersion'.

3. שדות חובה קפדניים (id, מפתחות חיפוש), ”זנב” של תכונות נדירות - אופציונלי.

4. מגבלות ממדי מערך וקינון (לאינדקסים ו-RAM).

5. נדודים ברקע: עדכונים על ידי ”תרשים”, שופכים, מילוי גב.

דוגמה: סכימת JSON

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 מסמך או קבוצה קטנה של מסמכים.
Denormalization: כלול תת-דוקומנטים קטנים המצורפים (לדוגמה, מיני-קלפים של ספקי משחקים).

• שיבוץ - לקטעים קרובים ומעודכנים לעתים רחוקות.
• הפניות ('ref') - לגודל גדול/עדכונים תכופים/שימוש חוזר.
• הגבלת גודל: מסמך מצורף 16 MB; מחסומים גדולים של אף-אף-אס/אובייקט.
• ביקורת חשבונות/מטא-נתונים: ” At',” At', ”tracheId',” tenantId', ”idempot Key”.

אינדקסים: איכות קריאה ויציבות אחורית

• B-Tree (ראשי)

תרכובת: סדר השדות תואם לנבואות תכופות.
כלל קידומת: אפשרויות קידומת עובדות עבור '(TenantID, TairID, AT)'.
מיין: שקול ”סוג” בסוף האינדקס (לדוגמה, ” At: -1”).

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

דלילות/חלקי

להאיץ תת-קבוצות תכופות (”status:” indition ””), להפחית את גודלן.

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

TTL

עבור טלמטריה/יומנים/תכונות זמניות - תפוגה אוטומטית.

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

טקסט/השלמה אוטומטית

טקסט לטקסט מלא (הגבלות שפה); להשלמה אוטומטית - n-gram/trigram דרך שדות וגישות רגקס או חיפוש אטלס.

נוגדי דלקת אינדקס

אינדקס ”כל” = טיפה במהירות כתיבה.
קרדינליות נמוכה ללא סלקטיביות נמוכה.
תשכפל תרכובות.
שדות אינדקס בתוך מערכים ענקיים ללא גבולות.

צינור צבירה: מסכים ודוחות מהירים

השתמש "$ game" "au '$ סוג'" $ limit "כשלבים מוקדמים; אינדקסים של פרויקט תחת 'משחק $/$ $ סוג'.
'חיפוש $ עבור joynes מבוקר (רך, בכרכים סבירים).
'$ pacet' עבור מדדים מרובים; עם דולר אחד, אוספי מיזוג.
'$ מיזוג '/$ out' - התממשות תוצאות באוסף (לקרוא מודלים).

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

עסקאות, עקביות ואידמפוטנטיות

אטומיות ללא מסמך יחיד; הזמנות מורכבות - תחשבו על חלוקת מסמכים.
עסקאות מולטי-מסמך (ACID) - זמינות עם העתקים, אך יקרות יותר באטיות; ליישם חוכמת נקודה.

• 'w: "רוב" "עבור רשומות קריטיות (עלות latency);
• דאגה: ”הרוב” לקריאה עקבית.
• Idempotency: מפתחות ייחודיים על "idempootsKey "/" pspTx", פעולות UPSERT ("$ StonInsert'," $ inc ").

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

שריטה ובחירת מפתח

• התפלגות טעינה: מפתח קרדינליות גבוה והפצה אחידה (לדוגמה, 'TenantID, Tangid)'.
• הימנע מונוטוניות: " At' כמפתח רק שבר" חם ".

• חשיש - מפיץ רשומות באופן שווה יותר.
• טווח הוא טוב יותר לשאילתות טווח, אבל לצפות זנבות חמים.
• טווח תגיות לרגולציה/לוקליזציה (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" });

• רסיס-מפתח על ידי קרדינליות נמוכה ('סטטוס') - רזה של שברים.
• ”תצפית” תכופה בין אוספי שארדי בלי לדחוף מפתח אחד בכל פעם.
• מפתח רסיס ניתן לשינוי (קשה ויקר לשינוי).

הגדרות העתק, קריאה, ומדיניות קריאה לאחר כתיבה

העתק סט = HA ובסיס עסקה.

• 'Primary' לקריאה ביקורתית אחרי כתיבה;
• 'Primage העדיף '/' משני' - לאנליטיקה/לא קריטי.
• ענייני קריאה/כתיבה מתואמים עם SLO ותקציב Latency.

שינוי זרמים, מרכז לבקרת מחלות ואינטגרציה

• סינכרון שכבות מטמון (רדיס)
• מעורר/הודעות CRM,
• הורדות ל OLAP (ClickHouse/Pinot),
• מסכי תגובה.
• תבנית אאוטבוקס: עבור תחומים קריטיים, פרסמו אירועים לאוסף נפרד, אותו המחבר קורא ומתרגם לאוטובוס (קפקא). זה מגדיל את יכולת החיזוי של אינטגרציה.

יכולת תצפית ו ־ SLO

SLO: p99 כרטיס קריאה סתום 10-20 ms; הכנסת אירועים לבוש 20-40 ms; הפרש בריח בין רסיסים בתוך X%; זמינות 99. 9%.
Metrics: op-latency, תור עומק,% של אמפס למשני, מטמון/WT סטטיסטיקות, דפים פגומים, מנעולים ממתינים, מספר של קורסים/חיבורים פתוחים.
פרופיל: 'מערכת. פרופיל ', הסבר' ("Stats'), מנעולי אוסף/אינדקס.
התראות: גידול של לחץ מטמון WT, פעולות איטיות, גידול של בקשות שאינן כלולות באינדקס, גיבוי של בקשות משניות, נדידת נתח/מאזן.

ביצועים וכוונון

W Tiger Cache: כברירת מחדל ~ 50% RAM - תוקף לפרופיל.
דחיסה: snappy/zstd לאוספים, zstd ליומנים - שיווי משקל מעבד/IO.
מכניסים ומחיצות לטלמטריה.
הקרנה (”field: 1”) כדי לא לגרור מסמכים ”עבים”.
הגבלה/דלג: הימנע מ "דלג" גדול. השתמש בסמן/סמן pagination (" At/_ id').
אוספים של רישומי ”טבעת”.

בטיחות ותאימות

Auth/RBAC: תפקידים על בסיס האוסף/נתונים, מינימום הרשאות נדרשות.
TLS במעבר, הצפנה בדיסק (FLE/at-rest).
מדיניות PII: מיסוך/כינוי, אוספים נפרדים עבור שדות רגישים.
ריבוי שכבות: קדימות/מסדי נתונים/אוספים, מסננים לפי "TenantId', ניתן לבנות שכבות דמויות RLS ביישום.
ביקורת: אפשר ביקורת של פעולות על אוספים קריטיים.

גיבויים, PITR וDR

תמונות של כרכים + גיבויים של אופלוג עבור התאוששות נקודה בזמן.
העתק מוגדר באזור אחר עבור DR; תרגילי התאוששות רגילים.
שליטה על גידול אופלוג עבור פסגות החדרה (PSP webhooks/turniers).
באשכולות שברים - גיבויים עקביים עם שרת הגדרות.

אינטגרציה עם שאר הארכיטקטורה

CQRS: צוותים פגעו ב ־ SQL (כסף), Events # Materialized Views in MongodB.
הזרמת אירועים: קפקא/פולסר כאוטובוס, מונגו - כיור/מקור באמצעות מחברים ושינוי זרמים.
רדיס (Redis), בקרבת מקום, שכבת לייה נמוכה ביותר (caches/counters).
העלאה ל ClickHouse/Pinot לסריקות ארוכות ו BI.

רשימת בדיקות מימוש

1. תיקון תחומים: מה הולך במונגו (גמיש/גבוה TPS/השלכה), מה שנשאר ב SQL.
2. הגדר חוזי סכימה: JSON Schema Validation, ”SchamaVersion”.
3. אינדקסים לעיצוב לשאילתות אמיתיות; הוסף TL למידע רועש.
4. בחר מפתח רסיס (קרדינליות גבוהה, אחידות); במידת הצורך - חדירה לאיזור.
5. הגדרת ערכת העתקים, Read/Write Conservation for SLO; מדיניות קריאה אחרי כתיבה.
6. אפשר יכולת תצפית ואפיון, התראות למטמון/WT/oplog indexes.
7. ארגן גיבויים + PITR, ד "ר אשכול ותרגילים רגילים.
8. חבר בין זרמי שינוי/תיבה חיצונית כדי לסנכרן מטמונים ואוטובוסים.
9. הגבלת גודל מסמך וקינון; יישום פגינציה על ידי סמן.
10. מדיניות נפרדת עבור PII/דיירים, הצפנה, ביקורת.

אנטי דפוסים

”אין מזימה” במוצר: חוסר אימות וגרסאות = תוהו ובוהו.
שברי מפתח בזמן/מונוטוני - רסיס חם ו p99 לא יציב.
”ג 'וינס” תצפית $ על סטים ענקיים ללא אינדקסים/עבודת אלילים.
השתמש בעסקאות בכל מקום - אבדה פרודוקטיביות.
חוסר TTL/Restructions ליומנים * גידול בנפח ובעלות.
לאחסן מזומנים קריטיים רק במונגו ללא אידאות קפדנית.

תוצאות

MongoDB הוא כלי רב עוצמה לתחומי iGaming גמישים: פרופילים, ספריות, טלמטריה, תחזיות ואישיות. המפתח להצלחה הוא ערכת חוזה ואימות, אינדקס מתחשב, מפתח שברי נבחר היטב, קונצרן קריאה/כתיבה מודעת, שינוי זרמים לאינטגרציה ומשמעת תפעולית קפדנית (תצפיות, גיבויים, DR). בשילוב עם ליבת SQL וזרימת אוטובוס, זה נותן לפלטפורמה ממשקים מהירים ויציבות לפסגות טורניר.