عزل بيانات المستأجرين في PostgreSQL: الطريقة الصحيحة لبناء SaaS متعدد المستأجرين

كل منتج SaaS متعدد المستأجرين يواجه في نهاية المطاف نفس سؤال التصميم: كيف يجب أن تفصل قاعدة البيانات بيانات المستأجرين عن بعضها؟ الإجابة تشكل ملف الأداء ووضع الامتثال والتعقيد التشغيلي والقدرة على خدمة عملاء المؤسسات الذين يطالبون بعزل صارم للبيانات.

في PostgreSQL هناك ثلاثة مناهج رئيسية: قاعدة بيانات منفصلة لكل مستأجر، مخطط منفصل لكل مستأجر داخل قاعدة بيانات مشتركة، ومخطط مشترك مع Row-Level Security. لكل منها مقايضات حقيقية تبدو مختلفة في نقاط مختلفة من حياة المنتج.

المناهج الثلاثة ومتى يكون كل منها مناسباً

قاعدة بيانات لكل مستأجر تنشئ قاعدة بيانات PostgreSQL واحدة لكل منظمة عميل. بيانات العميل معزولة تماماً على مستوى قاعدة البيانات. خطأ في التطبيق يعيد بيانات خاطئة لن يتجاوز حدود المستأجرين على مستوى قاعدة البيانات.

هذا المنهج مناسب عندما يكون لديك عملاء مؤسسات ذوو متطلبات امتثال صارمة (SOC 2، GDPR، الصناعات المنظمة). التكلفة التشغيلية عالية. توصيف الاتصالات يجب أن يكون لكل قاعدة بيانات. ترحيلات المخطط تتطلب تنفيذ ترحيل منفصل لكل قاعدة بيانات.

مخطط لكل مستأجر ينشئ مخطط PostgreSQL واحداً لكل عميل داخل نفس قاعدة البيانات. جميع المستأجرين يشتركون في نفس خادم قاعدة البيانات ومجمع الاتصالات، لكن جداول كل مستأجر في نطاقها الخاص.

القيد لمخطط لكل مستأجر هو أنه لا يتوسع جيداً بعد حوالي 100 إلى 500 مستأجر في قاعدة بيانات واحدة. عمليات كتالوج PostgreSQL التي تمسح جميع المخططات تتباطأ بشكل متناسب مع زيادة عدد المخططات.

Row-Level Security (RLS) هو المنهج الأصيل في PostgreSQL حيث يشترك جميع المستأجرين في نفس الجداول. كل صف يحتوي على معرف مستأجر (عادةً org_id أو tenant_id)، وسياسات PostgreSQL تفرض أن جلسة قاعدة البيانات يمكنها فقط الوصول إلى الصفوف التي تنتمي إلى مستأجرها.

RLS هو أبسط مناهج التشغيل. مخطط واحد، ترحيل واحد لكل جدول، مجمع اتصالات واحد. يتوسع إلى آلاف المستأجرين دون أي تدهور في التعقيد التشغيلي.

مخاطر RLS حقيقية ومحددة. العزل يُفرض بتعيين متغير جلسة على مستوى التطبيق. خطأ يفشل في تعيين app.current_org_id قبل استعلام سيصل إلى جميع الصفوف عبر جميع المستأجرين، وهو تسريب للبيانات.

كيف تختار بين المناهج الثلاثة

لمعظم منتجات SaaS في مراحلها المبكرة التي تستهدف أسواق لبنان ومنطقة MENA، الاختيار بين RLS وعزل المخطط.

ابدأ بـ RLS إذا: قاعدة عملائك الأولية أقل من 1,000 مستأجر، فريقك لديه انضباط قوي في الاختبار على مستوى التطبيق، متطلبات الامتثال لا تتطلب عزلاً فيزيائياً، وتقدّر بساطة التشغيل.

ابدأ بمخطط لكل مستأجر إذا: تتوقع عملاء مؤسسات سيسألون عن عزل البيانات في محادثات المبيعات، أو إذا كانت لديك متطلبات امتثال في قطاعات منظمة محددة.

الشيء الأهم تجنبه هو تأجيل القرار كلياً، واستخدام فلاتر WHERE org_id = ? العشوائية في كود التطبيق دون آلية تطبيق منهجية. هذه هي الطريقة التي تنتهي بها منتجات SaaS بفلترة غير متسقة عبر مئات نقاط النهاية.

تنفيذ RLS بشكل صحيح في Go مع sqlc

إذا كنت تستخدم sqlc لتوليد كود Go آمن الأنواع من استعلامات SQL، فإن تنفيذ RLS يتطلب نمطاً متسقاً لتعيين سياق المستأجر قبل تنفيذ أي استعلام.

يستخدم SET LOCAL نسخة تعيين متغير الجلسة للمعاملة الحالية فقط، وهو مهم عند استخدام مجمعات الاتصالات حيث يُعاد استخدام الاتصالات عبر الطلبات. بدون LOCAL، يمكن أن يُعاد اتصال عيّن معرف المنظمة للمستأجر A إلى المجمع ويُعاد استخدامه بواسطة طلب من المستأجر B.

استراتيجية الترحيل عند تغيير المناهج

البدء بـ RLS ثم الحاجة إلى الترحيل إلى مخطط لكل مستأجر لاحقاً هو سيناريو حقيقي مع نمو المنتجات واكتساب عملاء المؤسسات.

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

يمكن إجراء هذا الترحيل بشكل تدريجي دون توقف. يمكن ترحيل عملاء المؤسسات الذين يحتاجون عزل مخطط واحداً في كل مرة.