MongoDB ومخططات البيانات المرنة

(القسم: التكنولوجيا والهياكل الأساسية)

موجز موجز

MongoDB هو تخزين موجه نحو المستندات مع دوائر مرنة (BSON) وإدخالات سريعة وتحجيم أفقي وخط أنابيب تجميع قوي. في iGaming، إنه رائع لملفات تعريف اللاعب وبطاقات CRM المرنة وسجلات الأحداث والقياس عن بعد وإسقاطات البث المجسدة وكتالوجات الألعاب والمناظر الأمامية المخبأة. بالنسبة للثوابت النقدية (المحافظ/دفتر الأستاذ)، غالبًا ما يترك محيط SQL/CP ؛ MongoDB مناسب كنموذج قراءة وتخزين مستندات عالي الأداء.

حيث تحقق MongoDB أقصى استفادة من iGaming

ملفات تعريف وإعدادات اللاعب: متغيرات الهيكل (إعدادات الموقع، التفضيلات، البيانات الوصفية KYC).
كتالوجات المحتوى/الألعاب/المزود: قراءة سريعة للبطاقة، مرشحات، وضع العلامات، النص الكامل.
الأحداث/القياس عن بعد/السجلات: نظام تحديد المواقع العالي، والنوافذ الزمنية، وتخزين TTL.
الآراء المجسدة (CQRS): شاشات سريعة (لوحات الصدارة، الإجراءات الأخيرة، المجاميع).
التخصيص/الميزات عبر الإنترنت ML: أنماط KV في المجموعات، TTL قصيرة.

مبادئ المخطط المرن: الانضباط بدلا من الفوضى

MongoDB ليس «بدون مخطط» - المخطط يعيش في رمز والتحقق من الصحة.

يوصى بما يلي:

1. المخطط كعقد: JSON Schema التحقق من صحة المجموعات.

2. إصدار الوثائق بمجال «schemaVersion».

3. الحقول الإلزامية الصارمة (الهوية، مفاتيح البحث)، «ذيل» السمات النادرة - اختياري.

4. يقيد أبعاد المصفوفة والتعشيش (للفهارس وذاكرة الوصول العشوائي).

5. الهجرات في الخلفية: تحديثات بواسطة «schemaVersion»، shedulers، back fills.

مثال: JSON Schema التحقق من صحة

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 أو مجموعة صغيرة من الوثائق.
إلغاء التطبيع: قم بتضمين الأجزاء الفرعية الصغيرة المرفقة (على سبيل المثال، بطاقات صغيرة لمقدمي الألعاب).

الروابط مقابل التضمين:

تضمين - لشظايا وثيقة الصلة وغير محدثة بشكل متكرر.
المراجع («المرجع») - للحجم الكبير/التحديثات المتكررة/إعادة الاستخدام.
الحد الأقصى للحجم: المستند ≤ 16 ميغابايت ؛ ثنائيات كبيرة - GridFS/مخزونات الكائنات.
Audit/metadata: 'created', 'updated' at, 'traceId', 'tenantId',' idempotencyKey '.

الفهارس: قراءة الجودة واستقرار زمن الانتقال

أنواع الفهرس والممارسات:

B-Tree (ابتدائي)

المركب: يتوافق ترتيب الحقول مع الأسس والأنواع المتكررة.
قاعدة البادئة: تعمل خيارات البادئة لـ «(معرف المستأجر، معرف اللاعب، تم إنشاؤه في)».
الفرز: ضع في اعتبارك «فرز» في نهاية المؤشر (على سبيل المثال، «تم إنشاؤه في: -1»).

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

جزئي/متناثر

تسريع المجموعات الفرعية المتكررة ("الحالة:" معلقة ")، تقليل الحجم.

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

TTL

للقياس عن بعد/السجلات/الميزات المؤقتة - انتهاء الصلاحية التلقائي.

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

النص/الإكمال التلقائي

'3' النص الكامل (القيود اللغوية) ؛ للإكمال التلقائي - "n-gram'/trigram عبر الحقول ونهج regex أو Atlas Search.

مؤشر المضادات

مؤشر «الكل» → انخفاض في سرعة الكتابة.
كاردينالية منخفضة بدون انتقائية جزئية → منخفضة.
مركبات مكررة.
حقول الفهرسة داخل المصفوفات العملاقة بلا حدود.

خط أنابيب التجميع: شاشات وتقارير سريعة

استخدام '$ تطابق' → '$ serve' → '$ remide' كمراحل مبكرة ؛ أرقام قياسية للمشروع تحت «دولار مطابق/دولار».
«البحث عن الدولار» للأفراح الخاضعة للرقابة (ناعمة، بأحجام معقولة).
«الوجه $» لمقاييس متعددة ؛ «$ Union 'With» - دمج المجموعات.
"اندماج $ "/" $ 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: «الأغلبية» بالنسبة للسجلات الحرجة (تكلفة الكمون) ؛
"ReadConcern:" الأغلبية "للقراءة المتسقة.
الخصوصية: مفاتيح فريدة من نوعها على «الخصوصية »/« pspTx»، عمليات UPSERT («$OnInsert'،» $ inc').

مثال UPSERT:

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

💡 بالنسبة للثوابت النقدية، عادة ما يتم تفضيل SQL. في مونغو - فقط مع الانضباط الصارم للمفتاح/الفطرة والمعاملات المحدودة.

الشحن واختيار المفاتيح

شظايا MongoDB بواسطة مفتاح الشظايا. الخيار حاسم:

توزيع الأحمال: مفتاح الكاردينالية العالية والتوزيع الموحد (على سبيل المثال، '(معرف المستأجر، معرف اللاعب)').
تجنب الرتابة: «تم إنشاؤه» باعتباره المفتاح الوحيد → شظية «ساخنة».

نطاقات مقابل هاش:

Hashed - يوزع السجلات بشكل متساوٍ.
Ranged أفضل لاستفسارات النطاق، ولكن شاهد الذيول الساخنة.
نطاقات العلامات للتنظيم/التوطين (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" });

أنتيباترن:

Shard-key by low cardinality ('status') - انحراف الشظايا.
«البحث المتكرر عن دولار» بين المجموعات القشرية دون تقاطع مفتاح واحد في كل مرة.
مفتاح شظية قابل للتغيير (يصعب تغييره ومكلف).

طقم طبق الأصل، يقرأ، وسياسة القراءة بعد الكتابة

مجموعة نسخ طبق الأصل = HA وأساس المعاملات.

اقرأ التفضيل:

'primary' للقراءة النقدية بعد الكتابة ؛
«PrimaryPrefered »/« ثانوي» - للتحليلات/غير الحرجة.
قراءة/كتابة الاهتمام بالتنسيق مع SLO وميزانية زمن الوصول.

تدفقات التغيير ومركز السيطرة على الأمراض والتكامل

تدفقات التغيير: الاشتراك في الإدراج/التحديثات/الحذف - مناسب لـ:

تزامن طبقة الكاش (Redis)
محفزات/إخطارات إدارة العلاقة مع العملاء،
تنزيلات OLAP (ClickHouse/Pinot)،
شاشات تفاعلية.
نمط Outbox: بالنسبة للمجالات الهامة، انشر الأحداث لمجموعة منفصلة، يقرأها الموصل ثم يترجمها إلى الحافلة (كافكا). وهذا يزيد من إمكانية التنبؤ بعمليات التكامل.

قابلية الملاحظة و SLO

SLO: قراءة بطاقة p99 ≤ 10-20 ms ؛ وإدراج الأحداث ≤ 20-40 مللي ثانية ؛ والفرق بين الشظايا في حدود x في المائة ؛ ≥ 99. 9%.
المقاييس: زمن الانتظار، عمق قائمة الانتظار،٪ من المؤشرات لكل ثانوي، إحصاءات المخبأ/WT، أعطال الصفحات، فترات الانتظار القفل، عدد المؤشرات/الوصلات المفتوحة.
التنميط: 'النظام. profile ',' explay («executionStats») ', collection/index locks.
التنبيهات: نمو ضغط مخبأ WT، والعمليات البطيئة، ونمو الطلبات غير المدرجة في المؤشر، وتراكم الطلبات الثانوية، والهجرات الجزئية/الموازن.

الأداء والضبط

WiredTiger Cache: افتراضيًا ~ 50٪ ذاكرة وصول عشوائي - تحقق من صحة الملف الشخصي.
الضغط: سريع/زستد للمجموعات، زستد للسجلات - رصيد وحدة المعالجة المركزية/IO.
أدرج الدفعة والكتابة بالجملة للقياس عن بعد.
الإسقاط ('{حقل: 1}') حتى لا تسحب الوثائق «السميكة».
الحد/تخطي: تجنب "تخطي" كبير → استخدام المؤشر/وضع علامة ("تم إنشاؤه At/_ id').
مجموعات مغلقة لسجلات «الحلقة».

السلامة والامتثال

Auth/RBAC: الأدوار في جمع/قاعدة البيانات، الحد الأدنى من الامتيازات المطلوبة.
TLS أثناء العبور، التشفير على القرص (FLE/at-rest).
سياسات PII: الإخفاء/التسريح، مجموعات منفصلة للحقول الحساسة.
متعدد الإيجارات: البادئات/قواعد البيانات/المجموعات الفردية، المرشحات بواسطة «معرف المستأجر»، يمكنك وضع طبقات تشبه RLS في التطبيق.
مراجعة الحسابات: تمكين مراجعة حسابات العمليات المتعلقة بالمجموعات الهامة.

النسخ الاحتياطية و PITR و DR

لقطات من المجلدات + نسخ احتياطية من oplog لـ Point-in-Time Recovery.
وضع نسخة طبق الأصل في منطقة أخرى لـ DR ؛ عمليات الإنعاش المنتظمة.
التحكم في نمو oplog لذروة الإدراج (خطافات/بطولات PSP).
في مجموعات القطع - نسخ احتياطية متسقة مع خادم تحضير.

التكامل مع بقية العمارة

CQRS: ضربت الفرق SQL (المال)، الأحداث → الآراء الملموسة في MongoDB.
بث الحدث: كافكا/بولسار كحافلة، مونجو - غرق/مصدر عبر الموصلات و Change Streams.
Redis: في مكان قريب كطبقة زمن انتقال منخفضة للغاية (مخابئ/عدادات).
OLAP: تم تحميله على ClickHouse/Pinot لإجراء فحوصات طويلة و BI.

قائمة التنفيذ المرجعية

1. إصلاح المجالات: ما يحدث في Mongo (مرن/عالي TPS/إسقاط)، ما تبقى في SQL.
2. تعريف عقود المخطط: JSON Schema Validation, «schemaVersion».
3. فهارس تصميم الاستفسارات الحقيقية ؛ إضافة TTL للبيانات الصاخبة.
4. انتقِ shard key (high cardinality, uniformity); إذا لزم الأمر - شحن المناطق.
5. قم بإعداد نسخة طبق الأصل، اقرأ/اكتب القلق لـ SLO ؛ سياسة القراءة بعد الكتابة.
6. تمكين إمكانية الرصد والتنميط، تنبيهات إلى/WT ذاكرة التخزين المؤقت/فهارس oplog.
7. تنظيم نسخ احتياطية + PITR ومجموعة DR وتمارين منتظمة.
8. قم بتوصيل Change Streams/Outbox لمزامنة المخابئ والحافلات.
9. الحد من حجم المستندات والتعشيش ؛ تنفيذ الوثب عن طريق المؤشر.
10. سياسات منفصلة لـ PII/المستأجرين، التشفير، التدقيق.

الأنماط المضادة

«لا يوجد مخطط» في المنتج: نقص التحقق والإصدارات → الفوضى.
شطر المفتاح في الوقت/الرتيب - قطعة ساخنة وغير مستقرة p99.
Joynes '$ lookup' على مجموعات ضخمة بدون فهارس/استعداد.
استخدم المعاملات في كل مكان - فقدت الإنتاجية.
عدم وجود سجلات TTL/الاحتفاظ بها → نمو في الحجم والتكلفة.
قم بتخزين الثوابت النقدية الحرجة فقط في مونغو دون أي إخلال صارم.

موجز

يعد MongoDB أداة قوية لمجالات iGaming المرنة: الملفات الشخصية والأدلة والقياس عن بُعد والإسقاطات والتخصيص. مفتاح النجاح هو مخطط العقد والتحقق من الصحة، والفهرسة المدروسة، ومفتاح القطع المختار جيدًا، وقلق القراءة/الكتابة الواعي، وتدفقات التغيير للتكامل والانضباط التشغيلي الصارم (قابلية الملاحظة، النسخ الاحتياطية، DR). جنبًا إلى جنب مع حافلة SQL الأساسية والمتدفقة، يمنح هذا المنصة واجهات سريعة واستقرارًا لقمم البطولة.