معظم قرارات الهندسة المعمارية أرخص في المراجعة منها في التفكير المفرط. يمكنك تبديل قائمة انتظار، استبدال إطار عمل، الانتقال من سحابة إلى أخرى — مكلف، معطّل، لكنه قابل للبقاء.
التعددية مختلفة. كيف تفصل بيانات عميل عن آخر يؤثر على كل استعلام تكتبه، كل ترحيل تجريه، كل إجراء نسخ احتياطي واستعادة، وكل استبيان أمان مؤسسي ترد عليه. تغييره لاحقًا يعني إعادة كتابة طبقة البيانات لنظام حي بينما يعتمد عليه العملاء.
لذا يستحق الأمر ساعة الآن. هذه هي النماذج الثلاثة، مقارنة بصدق.
النموذج 1: مخطط مشترك
قاعدة بيانات واحدة، مجموعة جداول واحدة، عمود tenant_id على كل شيء. كل استعلام يُفلتر حسب المستأجر.
- التكلفة: الأدنى بفارق كبير. قاعدة بيانات واحدة للتشغيل، واحدة للنسخ الاحتياطي، واحدة للضبط.
- العمليات: الأبسط. ترحيل واحد يُطبق مرة واحدة، وكل مستأجر على المخطط الحالي.
- القابلية للتوسّع: ممتازة للعديد من المستأجرين الصغار. هذه هي الطريقة التي تخدم بها عشرة آلاف عميل بشكل مربح.
- العزل: الأضعف. غياب شرط
WHERE tenant_id = ?واحد يؤدي إلى تسرب بيانات بين المستأجرين. - الجيران المزعجون: حقيقة. تقرير ثقيل من مستأجر واحد قد يضعف تجربة الجميع.
- الاستعادة لكل مستأجر: صعبة حقًا. استعادة بيانات عميل واحد من نسخة احتياطية مشتركة عملية معقدة.
خطر العزل قابل للإدارة لكنه يجب أن يُدار هيكليًا وليس بالانضباط. طبق التعددية في أدنى طبقة ممكنة — أمان على مستوى الصف في قاعدة البيانات، أو طبقة وصول بيانات تجعل الاستعلام غير المقيّد مستحيل الكتابة — لا تعتمد على تذكر كل مطور. مراجعة الكود لا تتوسع كضبط أمني.
إذا أخذت شيئًا واحدًا من هذا المقال: اجعل الاستعلام غير المقيّد غير قابل للكتابة، لا مجرد مرفوض. كل خرق لمخطط مشترك قرأنا عنه كان استعلامًا نسي أحدهم تصفيته.
النموذج 2: مخطط لكل مستأجر
قاعدة بيانات واحدة، مخطط منفصل لكل مستأجر. نفس الخادم، مساحات أسماء منفصلة.
- التكلفة: لا تزال منخفضة — مثيل قاعدة بيانات واحد.
- العزل: أفضل بشكل ملموس. الوصول عبر المستأجرين يتطلب خطأً متعمداً بدلاً من شرط منسي.
- استعادة لكل مستأجر: ممكنة، وهو ما لا يتيحه المخطط المشترك.
- العمليات: هنا تكمن المشكلة. يجب تنفيذ الترحيلات لكل مخطط، ويجب أن تكون قادرة على التعامل مع مئات المخططات. ترحيل ينجح جزئياً عبر 400 مخطط هو تجربة سيئة حقاً.
- حدود التوسع: تبدأ قواعد البيانات في المعاناة عند وجود آلاف قليلة من المخططات — تجمع الاتصالات والكتالوج نفسه يصبحان القيد.
هذا هو الحل الوسط العملي، ويناسب المنصات التي تضم عشرات إلى مئات قليلة من المستأجرين حيث يكون كل منهم ذا أهمية تجارية. وهو أيضاً النموذج الأكثر احتمالاً للاعتماد لأسباب خاطئة — لأنه يبدو أكثر أماناً من المخطط المشترك دون أن يكون قد تم تقييم أدوات الترحيل التي يتطلبها.
النموذج 3: قاعدة بيانات لكل مستأجر
يحصل كل مستأجر على قاعدة بيانات خاصة به، وأحياناً على بنية تحتية خاصة به بالكامل.
- العزل: الأقوى المتاحة، والأسهل شرحاً لمراجع الأمان.
- الامتثال: النموذج الذي يلبي متطلبات إقامة البيانات بوضوح — قاعدة بيانات هذا المستأجر في فرانكفورت، وذاك في فيرجينيا.
- النسخ الاحتياطي والاستعادة والتصدير لكل مستأجر: أمر بسيط. وكذلك حذف عميل بالكامل عند مغادرته، وهو أمر أكثر أهمية مما تتوقع الفرق.
- الجيران المزعجون: تم القضاء عليهم. لا يمكن لمستأجر أن يؤثر على أداء مستأجر آخر.
- التكلفة: الأعلى، وتتزايد خطياً مع عدد المستأجرين وليس مع الاستخدام.
- العمليات: الأثقل. الترحيلات، المراقبة، النسخ الاحتياطية والترقيات كلها تتضاعف، وستحتاج إلى أتمتة حقيقية قبل أن تصل إلى أعداد كبيرة من المستأجرين.
هذا النموذج يبرر تكلفته في حالة واحدة بالضبط: العملاء المؤسسيون الذين تتطلب عمليات الشراء لديهم ذلك. إذا كان المشترون يرسلون استبيانات أمان يسألون عن مكان وجود بياناتهم فعلياً وما إذا كانت تشارك البنية التحتية مع أي جهة أخرى، فهذا هو الجواب الذي يريدونه، وقد يكون الفرق بين الفوز أو خسارة الصفقة.
الاختيار
اعمل على هذه النقاط بالترتيب:
- من هو العميل؟ آلاف المستأجرين الصغار تشير إلى المخطط المشترك. عشرات المؤسسات الكبيرة تشير إلى قاعدة بيانات لكل مستأجر. المزيج يشير إلى نموذج هجين — انظر أدناه.
- ما الذي يتطلبه الامتثال فعلاً؟ ليس ما يبدو أكثر أماناً. اقرأ الالتزامات. إقامة البيانات وعدم مشاركة البنية التحتية متطلبات محددة لها إجابات محددة؛ القلق العام ليس منها.
- ما هو سعر البيع؟ قاعدة بيانات لكل مستأجر لها تكلفة أساسية لكل عميل. إذا كانت هذه التكلفة تشكل جزءاً معتبراً من السعر الشهري، فإن النموذج غير مناسب لذلك القطاع.
- ما مدى قدرة العمليات لديك؟ اختيار نموذج عزل لا يستطيع فريقك أتمتته يعني اختيار حدوث توقف.
- ما احتمال الحاجة لاستعادة لكل مستأجر؟ إذا كان من الممكن أن يحذف العميل بياناته عن طريق الخطأ، فإن المخطط المشترك سيكون ضاراً.
النهج الهجين، ولماذا يفوز عادةً
معظم المنصات الناجحة تنتهي بنموذج مختلط: مخطط مشترك للطبقة ذات الخدمة الذاتية، وقواعد بيانات مخصصة للعملاء المؤسسيين الذين يدفعون مقابل ذلك. هذا وجهة شرعية وشائعة.
كما أنه أسهل بكثير الوصول إليها إذا خططت لها مبكراً. بناء طبقة حل مستأجر يمكنها التوجيه إلى قاعدة بيانات مشتركة أو مخصصة يكلف قليلاً في البداية وهو ما يجعل الهجين ممكناً لاحقاً. إعادة تركيبها في قاعدة شفرة افترضت وجود سلسلة اتصال واحدة هو المكان الذي تكمن فيه التكلفة الحقيقية.
إذا كنت غير متأكد، فابنِ مخططاً مشتركاً خلف طبقة تجريد يمكنها التوجيه حسب المستأجر. تحصل على النموذج الرخيص الآن والنموذج المكلف متاح لاحقاً — وهو عكس الموقف الذي ينتهي إليه معظم الفرق.
ما يُقيّدك بغض النظر
أيًا كان النموذج الذي تختاره، فإن هذه القرارات تتصلب معه وتستحق نفس التدقيق:
- هوية المستأجر في طبقة المصادقة لديك. إعادة تركيب تعدد المستأجرين في نموذج مصادقة لمستأجر واحد مؤلم، لذا قرر مسبقاً ما إذا كان يمكن للمستخدم الانتماء لأكثر من مستأجر.
- ما إذا كانت معرفات المستأجر تظهر في عناوين URL وواجهات برمجة التطبيقات. تغيير ذلك لاحقاً يكسر التكاملات التي بنىها عملاؤك.
- أين تعيش إعدادات كل مستأجر. في بيانات المستأجر أم في سجل مركزي؟ كلاهما يعمل؛ المزج بينهما لا يعمل.
- كيف تتعامل مع دمج أو تقسيم مستأجر. نادر، وقاسٍ إذا لم يتوقع نموذج البيانات ذلك — العملاء يشترون بعضهم البعض.
- نموذج الوظائف الخلفية لديك. قوائم انتظار لكل مستأجر، جدولة عادلة، وحدود معدل لكل مستأجر أصعب بكثير إضافتها لاحقاً من تصميمها منذ البداية.
السؤال الكامن وراء السؤال
عادة ما تصل الفرق إلى هذا القرار لأن أحدهم سأل هل بياناتنا آمنة؟ — ويلجأون إلى أقوى عزل متاح كضمان. هذا الغريزة مفهومة لكنها مكلفة.
العزل هو أحد الضوابط بين عدة ضوابط. منصة قاعدة بيانات لكل مستأجر مع تحكم وصول ضعيف، وعدم وجود تسجيل تدقيق، وباب خلفي إداري مشترك أقل أماناً من منصة مخطط مشترك مصممة جيداً مع أمان على مستوى الصف وتفويض مناسب. اختر نموذج التعددية بناءً على المتطلبات والاقتصاد؛ واشتري الأمان بشكل منفصل، وبعناية، وفي أكثر من طبقة.
هذا نوع القرار الذي نعمل عليه قبل كتابة أي سطر شفرة — انظر ما هي التكلفة الحقيقية لمنصة Node.js مخصصة لمعرفة كيف يؤثر ذلك على الميزانية. تقوم ممارسة منصة Node.js وفريق التطوير الشامل بذلك مع العملاء وليس بدلاً عنهم، لأن الجواب يعتمد على حقائق تجارية يحتفظ بها العملاء فقط. حيثما يكون المشترون منظمين — كما في المالية والرعاية الصحية — عادة ما تقرر متطلبات الامتثال.
الأسئلة الشائعة
ما نموذج تعدد المستأجرين الذي ينبغي أن تعتمد عليه خدمة SaaS جديدة؟
مخطط مشترك، خلف طبقة تمييز المستأجر قادرة على التوجيه إلى قاعدة بيانات مخصّصة لاحقًا. هذا يمنحك أرخص نموذج الآن ويُبقي النموذج الأغلى متاحًا كخيار؛ وهو عكس المأزق الذي تُحشر فيه معظم الفرق عادةً.
كيف نمنع تسرب بيانات بين المستأجرين في مخطط مشترك؟
طبق التعددية أدنى من مستوى التطبيق: سياسات أمان على مستوى الصف في قاعدة البيانات، أو طبقة وصول إلى البيانات تجعل كتابة استعلام غير مقيد مستحيلة. الاعتماد على تذكّر المطورين لشرط WHERE ليس ضابطًا، ومراجعة الشيفرة لا تتسنّى كضابط قابل للتوسّع.
متى يستحق نموذج قاعدة بيانات لكل مستأجر التكلفة؟
عندما تطلبه مشتريات المؤسسات — مثل متطلبات موطن البيانات في ولاية قضائية محددة، أو ضمان موثق بعدم مشاركة البنية التحتية. إذا كان المشترون يرسلون استبيانات أمان تتضمن تلك الأسئلة، فذاك النموذج هو من يفوز بالصفقة. وإلا فهو طمأنة مكلفة.
هل يمكننا تغيير نموذج تعدد المستأجرين لاحقًا؟
نعم، بتكلفة كبيرة. يعني ذلك إعادة كتابة طبقة وصول البيانات، وترحيل بيانات العملاء الفعلية وإعادة التحقق من كل استعلام بينما المنصة قيد التشغيل. بناء تجريد توجيه مبكرًا يجعل ذلك أرخص بكثير؛ وغياب مثل هذا التجريد هو ما يجعل القرار يبدو لا رجعة فيه.
هل يؤثر تعدد المستأجرين على الأداء؟
في المخطط المشترك، نعم — حمل عمل ثقيل لمستأجر واحد قد يضعف أداء الآخرين، ولهذا السبب تهم حدود المعدل لكل مستأجر وجدولة المهام العادلة. قواعد البيانات المخصصة تقضي على المشكلة لكنها تستبدلها بسطح تشغيلي أوسع يحتاج إلى صيانة.
اطلب مراجعة القرار قبل التنفيذ
أخبرنا من هم عملاؤك وما الذي تطلبه عمليات الشراء لديهم، وسنخبرك بالنموذج الذي يحتاجه عملك فعلياً — عادة النموذج الأرخص. تحدث إلى فريقنا؛ نرد خلال يوم عمل.