MongoDB و طرح های داده انعطاف پذیر

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

MongoDB یک ذخیره سازی سند گرا با مدارهای انعطاف پذیر (BSON)، درج سریع، مقیاس افقی و خط لوله قدرتمند Aggregation است. در iGaming، برای پروفایل های بازیکن، کارت های CRM انعطاف پذیر، سیاهههای مربوط به رویداد، تله متری، پیش بینی های جریان تحقق یافته، کاتالوگ های بازی و نمایش های جلو ذخیره شده بسیار عالی است. برای متغیرهای پولی (کیف پول/دفتر کل)، کانتور SQL/CP اغلب باقی می ماند ؛ MongoDB به عنوان یک مدل خواندن و ذخیره سازی اسناد با کارایی بالا مناسب است.

جایی که MongoDB بیشتر از iGaming استفاده می کند

پروفایل و تنظیمات بازیکن: متغیرهای ساختار (تنظیمات محلی، ترجیحات، ابرداده KYC).
کاتالوگ محتوا/بازی/ارائه دهنده: خواندن سریع کارت، فیلترها، برچسب گذاری، متن کامل.
رویدادها/تله متری/سیاهههای مربوط: TPS بالا، پنجره های زمان، ذخیره سازی TTL.
نمایش Materialized (CQRS): صفحه نمایش سریع (مدیران، اقدامات اخیر، aggregates).
شخصی سازی/ویژگی های آنلاین ML: الگوهای KV در مجموعه ها، TTL کوتاه.

اصول یک طرح انعطاف پذیر: نظم و انضباط به جای هرج و مرج

MongoDB «بدون طرح» نیست - طرح در کد و اعتبار سنجی زندگی می کند.

توصیه می شود:

1. طرح به عنوان قرارداد: JSON Schema Validation در مجموعه ها.

2. اسناد نسخهبندی با حوزۀ «schemaVersion».

3. زمینه های اجباری سخت (ID، کلید های جستجو)، «دم» از ویژگی های نادر - اختیاری است.

4. محدود کردن ابعاد آرایه و تودرتو (برای شاخص ها و RAM).

5. مهاجرت در پس زمینه: به روز رسانی توسط 'schemaVersion'، shedulers، back fills.

مثال: اعتبار سنجی طرح 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 مگابایت ؛ binaries بزرگ - ذخیره سازی GridFS/شی.
ممیزی/فراداده: 'ساخته شده'، 'به روز شده' در '،' traceId '،' tenantId '،' idempotencyKey '.

شاخص ها: خواندن کیفیت و ثبات تاخیر

انواع و شیوه های شاخص:

B-درخت (اصلی)

ترکیب: ترتیب فیلدها مربوط به مقادیر و انواع مکرر است.
قانون پیشوند: گزینههای پیشوند برای '(tenantId, playerId, createdAt)' کار میکنند.
مرتب سازی: در انتهای فهرست، «مرتب سازی» را در نظر بگیرید (به عنوان مثال، «createdAt: -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 });

متن/تکمیل خودکار

«متن» برای متن کامل (محدودیت زبان) ؛ برای تکمیل خودکار - 'n-gram '/trigram از طریق زمینه ها و روش های regex یا جستجوی اطلس.

ضد الگوهای شاخص

شاخص «همه» → افت سرعت نوشتن.
کاردینالیتی کم بدون انتخاب جزئی → کم.

ترکیبات تکراری

فیلدهای شاخص در داخل آرایه های غول پیکر بدون محدودیت.

خط لوله جمع آوری: صفحه نمایش سریع و گزارش ها

استفاده از '$ match' → '$ sort' → '$ limit' به عنوان مراحل اولیه ؛ شاخص های پروژه تحت '$ match/$ sort'.
'$ lookup' برای joynes کنترل (نرم، در حجم معقول).
'$ facet' برای معیارهای چندگانه ؛ '$ unionWith' - ادغام مجموعه.
'$ merge '/' $ 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" }
} }
]);

معاملات، ثبات و idemotency

اتمی تک سند - اتمی آزاد ؛ unariants پیچیده - فکر می کنم پارتیشن بندی سند.
معاملات چند سند (ACID) - در دسترس با مجموعه های ماکت، اما گران تر در تاخیر ؛ عاقلانه استفاده کنید.

نوشتن نگرانی/خواندن نگرانی:

'w: «اکثریت»' برای سوابق بحرانی (هزینه تاخیر);
"readConcern:" اکثریت "برای خواندن مداوم.
Idempotency: کلید های منحصر به فرد در '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 معمولا ترجیح داده می شود. در Mongo - فقط با نظم و انضباط دقیق کلید/idemotence و معاملات محدود.

شاردینگ و انتخاب کلید

قطعات MongoDB با کلید shard. انتخاب مهم است:

توزیع بار: کلید کاردینالیتی بالا و توزیع یکنواخت (به عنوان مثال، '(tenantId، playerId)').
اجتناب از یکنواختی: «ایجاد شده» به عنوان تنها کلید → «داغ» شارد.

محدوده در مقابل هش:

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 («وضعیت») - انحراف از قطعات.
جستجوی مکرر $ بین مجموعه های شاردی بدون اشتراک یک کلید در یک زمان.
کلید قابل تعویض (دشوار و گران قیمت برای تغییر).

Replica مجموعه، خواندن و خواندن پس از نوشتن سیاست

Replica set = HA و مبنای معامله.

خواندن ترجیح:

'primary' for critical read-after-write;
'primaryPreferred '/' ثانویه' - برای تجزیه و تحلیل/غیر بحرانی.
خواندن/نوشتن نگرانی هماهنگ با SLO و بودجه تاخیر.

تغییر جریان، CDC و ادغام

تغییر جریان: اشتراک به درج/به روز رسانی/حذف - مناسب برای:

هماهنگ سازی لایه کش (Redis)
CRM باعث/اطلاعیه ها،
دانلود به OLAP (ClickHouse/Pinot)،
صفحه نمایش واکنشی
الگوی Outbox: برای دامنه های بحرانی، رویدادها را به یک مجموعه جداگانه منتشر کنید، سپس اتصال آن را می خواند و به اتوبوس (کافکا) ترجمه می کند. این قابلیت پیش بینی ادغام را افزایش می دهد.

💡 > قابلیت مشاهده و SLO

SLO: خواندن کارت p99 ≤ 10-20 میلی ثانیه ؛ درج وقایع ≤ 20-40 میلی ثانیه ؛ اختلاف رطوبت بین قطعات در X٪ ؛ دسترسی ≥ 99 9%.
معیارهای: op-latency، عمق صف،٪ از umps در هر ثانویه، آمار کش/WT، گسل صفحه، قفل انتظار، تعداد نشانگر باز/اتصالات.
پروفایل: "سیستم. profile ',' explain ('executionStats') ', مجموعه/فهرست قفلها.
هشدارها: رشد فشار کش WT، عملیات کند، رشد درخواست هایی که در فهرست گنجانده نشده است، عقب افتادن درخواست های ثانویه، مهاجرت های تکه ای/متعادل کننده.

عملکرد و تنظیم

کش WiredTiger: به طور پیش فرض ~ 50٪ RAM - اعتبار برای مشخصات.
فشرده سازی: snappy/zstd برای مجموعه ها، zstd برای سیاهههای مربوط - تعادل CPU/IO.
درج دسته ای و bulkWrite برای تله متری.
طرح ریزی ({فیلد: 1}) به طوری که اسناد «ضخیم» را بکشید.
محدودیت/پرش: اجتناب از پرش بزرگ → استفاده از صفحه بندی مکان نما/نشانگر ('createdAt/_ id').
مجموعه پوش برای «حلقه» سیاهههای مربوط.

ایمنی و انطباق

Auth/RBAC: نقش ها در مجموعه/پایگاه داده، حداقل امتیازات مورد نیاز.
TLS در حال انتقال، رمزگذاری روی دیسک (FLE/در حالت استراحت).
سیاست های PII: ماسک کردن/نام مستعار، مجموعه های جداگانه برای زمینه های حساس.
چند اجاره: پیشوندها/پایگاه داده های فردی/مجموعه ها، فیلترهای «tenantId»، شما می توانید لایه های RLS مانند در برنامه.
حسابرسی: حسابرسی عملیات در مجموعه های مهم را فعال کنید.

پشتیبان گیری، PITR و DR

عکس های فوری از حجم + پشتیبان گیری oplog برای بازیابی نقطه در زمان.

کپی در یک منطقه دیگر برای DR تنظیم شده است ؛ تمرینات بهبودی منظم

کنترل رشد oplog برای قله درج (PSP webhooks/مسابقات).
در shard clusters - پشتیبان گیری سازگار با یک سرور config.

ادغام با بقیه معماری

CQRS: تیم ها به SQL (پول)، events → Materialized Views در MongoDB ضربه می زنند.
رویداد جریان: Kafka/Pulsar به عنوان یک اتوبوس، Mongo - سینک/منبع از طریق اتصالات و تغییر جریان.
Redis: نزدیک به عنوان یک لایه تاخیر فوق العاده کم (caches/counters).
OLAP: آپلود به ClickHouse/Pinot برای اسکن طولانی و BI.

چک لیست پیاده سازی

1. رفع دامنه: آنچه در Mongo می رود (TPS/طرح ریزی انعطاف پذیر/بالا)، آنچه در SQL باقی می ماند.
2. تعریف قراردادهای طرح: اعتبار سنجی طرح JSON، «schemaVersion».
3. شاخص های طراحی برای نمایش داده های واقعی ؛ TTL را برای داده های پر سر و صدا اضافه کنید.
4. انتخاب کلید شارد (کاردینالیتی بالا، یکنواختی) ؛ در صورت لزوم - منطقه برش.

5. تنظیم یک مجموعه ماکت، خواندن/نوشتن نگرانی برای SLO ؛ سیاست خواندن پس از نوشتن

6. قابلیت مشاهده و پروفایل، هشدار به/WT cache/oplog indexes را فعال کنید.
7. سازماندهی پشتیبان گیری + PITR، خوشه DR و تمرینات منظم.
8. Connect Change Streams/Outbox برای همگام سازی کش ها و اتوبوس ها.
9. محدود کردن اندازه سند و تودرتو ؛ پیاده سازی صفحه بندی توسط مکان نما.
10. سیاست های جداگانه برای PII/مستاجران، رمزگذاری، حسابرسی.

ضد الگوهای

«بدون طرح» در محصول: عدم اعتبار و نسخه → هرج و مرج.
کلید شارد در زمان/یکنواخت - شارد داغ و ناپایدار p99.
Joynes '$ lookup' در مجموعه های بزرگ بدون شاخص/صفحه بندی.
استفاده از معاملات در همه جا - بهره وری از دست رفته.
فقدان TTL/retentions برای سیاهههای مربوط → رشد در حجم و هزینه.
ذخیره invariants پولی انتقادی تنها در Mongo بدون idemotency سخت.

خلاصه

MongoDB یک ابزار قدرتمند برای دامنه های انعطاف پذیر iGaming است: پروفایل ها، دایرکتوری ها، تله متری، پیش بینی ها و شخصی سازی. کلید موفقیت یک طرح قرارداد و اعتبار سنجی، نمایه سازی متفکرانه، یک کلید انتخاب شده به خوبی انتخاب شده، نگرانی خواندن/نوشتن آگاهانه، تغییر جریان برای ادغام و نظم و انضباط عملیاتی دقیق (مشاهده، پشتیبان گیری، DR) است. همراه با هسته SQL و جریان اتوبوس، این می دهد رابط پلت فرم سریع و ثبات برای قله مسابقات.