بارادايس كوداستوديو برمجيات
العودة إلى المقالات
هندسة الخلفيةتحديث ١٦ دقيقة قراءة

تصميم مخطط MongoDB لـ SaaS متعدد المستأجرين

التضمين مقابل القرارات المرجعية، ونمذجة المستأجر، والفهارس المركبة، والأنماط التي تصمد أمام النمو وإعداد التقارير.

MongoDBادارة العلاقات معمخططمتعدد المستأجريننمذجة البيانات

علي مرتضوي

مؤسس بارادايس كود

في MongoDB، يعني المخطط أنماط الوصول

لا يسمح اتجاه المستند بأن يكون فوضويًا. يجب أن تتمحور كل مجموعة حول الأسئلة المتكررة حول المنتج: "ما الذي تقرأه لوحة معلومات المستأجر؟" "كيف يتم تصفية قائمة الطلبات؟" إذا قمت بالنمذجة مثل الجداول المقيسة ثم انضممت إلى التطبيق، فإنك تحافظ على التعقيد العلائقي وتفقد مزايا المستند.

قبل النمذجة، اكتب أهم عشرة استعلامات للمنتج. المخطط هو الجواب على تلك القائمة.

التضمين مقابل المرجع

يناسب التضمين البيانات المقروءة/المكتوبة مع الأصل والمحدودة بالنمو: عناوين المستخدمين، وعناصر السطر بترتيب جديد. يناسب المرجع الكيانات المستقلة أو سريعة النمو أو متعددة الوالدين: المنتجات والمستخدمين والملفات.

الحد الأقصى للمستندات البالغ 16 ميجابايت هو سقف التصميم، وليس مجرد حاجز أمان. المصفوفات غير المحدودة (سجلات الأحداث داخل مستند المستخدم) تؤذي لاحقًا. لتحقيق نمو غير محدود، استخدم مجموعة فرعية مرتبطة بمعرف الوالدين.

نمذجة المستأجرين المتعددين

النموذج العملي الشائع: مجموعة واحدة، "معرف المستأجر" في كل مستند، والفهارس الرئيسية في "معرف المستأجر". تنتمي قواعد البيانات لكل مستأجر إلى عزلة المؤسسة أو احتياجات الامتثال الصارمة - فهي تضاعف تكلفة التشغيل.

يجب أن يفرض كل استعلام نطاق المستأجر. في طبقة المستودع، اجعل عوامل تصفية المستأجر غير قابلة للتجاوز حتى لا تتسرب أخطاء IDOR عبر نموذج البيانات. احتفظ ببيانات النظام الأساسي المشتركة (الخطط والترجمات) في مجموعات منفصلة بدون مفاتيح المستأجر.

الفهارس التي تبقي SaaS على قيد الحياة

قم بإنشاء فهارس مركبة ببادئة مستأجر: `{ TenantId: 1, CreateAt: -1 }`, `{ TenantId: 1, Status: 1, UpdateAt: -1 }`. عادةً ما يكون التفرد مركبًا أيضًا: البريد الإلكتروني فريد لكل مستأجر، وليس بالضرورة عالميًا - ما لم ينص المنتج على خلاف ذلك.

تتحكم فهارس TTL في البيانات المؤقتة (الجلسات وأكواد OTP والأحداث الأولية). ابحث عن الفهارس غير المستخدمة باستخدام `$indexStats` وقم بإفلاتها؛ الكتابة ليست مجانية.

المعاملات والاتساق والواقع الموزع

توجد معاملات متعددة المستندات، ولكنها باهظة الثمن ويجب ألا تتم كل عملية كتابة. تفضل النموذج الذي تكون فيه وثيقة واحدة هي وحدة الحقيقة لعملية ما. عندما يجب أن تتغير مستندات متعددة، قم بتعريف الثوابت وإجراءات التعويض بوضوح.

بالنسبة للعدادات والمخزون، استخدم عمليات المستندات الذرية أو قائمة الانتظار/صندوق الصادر؛ تصبح ظروف السباق في SaaS المدفوعة ضررًا ماليًا بسرعة.

النمو والأرشفة وإعداد التقارير

فصل البيانات الساخنة والباردة. إبقاء أحداث التحليلات بعيدة عن المسار عبر الإنترنت؛ إرسالها إلى خط الأنابيب أو مجموعة الأرشيف. بالنسبة لإعداد تقارير المستأجرين، تتفوق تدفقات التجميع المسبق أو التغيير الليلية على المجاميع الثقيلة بناءً على طلبات المستخدمين.

قم بإصدار المخطط على محمل الجد: حقول جديدة اختيارية، وترحيل تدريجي، وقراءات دفاعية في التعليمات البرمجية. تتغير أقفال المخطط غير المحولة بحلول الشهر السادس.

قائمة التحقق النموذجية قبل الإطلاق

قم بتدوين مالك كل مجموعة، وأهم عشرة استعلامات، والفهارس، وأسقف نمو المصفوفة، وسياسة الحذف/TTL. إذا كان أي منها غامضًا، فهذا يعني أن المخطط ليس جاهزًا لـ SaaS.

نموذج البيانات الجيد يكون غير مرئي، حتى لا يكون النموذج السيئ كذلك. الاستثمار المبكر هنا أرخص من إعادة الكتابة في العام المقبل.

الأسئلة الشائعة

هل يجب علينا دائمًا استخدام معاملات MongoDB؟

لا، قم بتفضيل نماذج المستند المفرد الذرية أولاً. المعاملات الاحتياطية للثوابت الحقيقية متعددة المستندات.

هل تضمين العناوين داخل المستخدم صحيح؟

إذا كان يحدها مجموعة وقراءة مع الملف الشخصي، نعم. إذا كانت العناوين كيانات مستقلة لها سجل أو مشاركة، فارجع إليها.

قاعدة بيانات واحدة لكل عميل؟

فقط لاحتياجات العزل/الامتثال الخاصة. بالنسبة لمعظم SaaS، يكون "tenantId" مع الفهارس والتحكم في الوصول كافيًا وأكثر قابلية للتشغيل.

كيف نمنع مشكلات نمو المستندات؟

انقل المصفوفات غير المحدودة إلى المجموعات الفرعية، وأضف TTL/الأرشفة، وتحقق من أسقف النمو في مراجعة النموذج.

المعرفة والمقالات

تحتاج تطبيق هذه المفاهيم في منتجك؟

بارادايس كود معك من الاستشارة حتى التسليم الكامل.

اطلب التعاون