شرح تعدد المستأجرين:قاعدة بيانات واحدة لألف عميل

شرح تعدد المستأجرين: تعدد المستأجرين يعني أن عدة عملاء يتشاركون قاعدة بيانات واحدة، لكن كل عميل لا يرى إلا بياناته. هكذا يخدم مؤسس منفرد 1,000 منظمة من تطبيق واحد دون إعادة بناء أي شيء، وهو ينجح بفضل عمود واحد يجب أن يكون في كل جدول من اليوم الأول: organization_id.

إن كنت تبني SaaS بالذكاء الاصطناعي، فهذا من القرارات المعمارية القليلة التي لا يمكنك إصلاحها بثمن زهيد لاحقًا. إليك ما هو تعدد المستأجرين، ولماذا يكلّف الخيار الخاطئ أشهرًا، والقواعد الدقيقة التي تعطيها للذكاء الاصطناعي ليصيب فيها.

شرح تعدد المستأجرين: تشبيه المبنى السكني

فكّر في SaaS الخاص بك كمبنى. كل عميل مستأجر. أمامك خياران.

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

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

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

الطرق الثلاث لخدمة 1,000 عميل

تقنيًا هناك ثلاثة نُهج. واحد فقط منها منطقي للمؤسس المنفرد:

الخيار الثالث هو ما استقر عليه القطاع، وهو موضوع هذا المقال. قاعدة بيانات واحدة للصيانة. وتغيير واحد للتنفيذ حين تحسّن شيئًا. ونسخة احتياطية واحدة. وتستطيع التوسع من عميل واحد إلى 10,000 دون تغيير في البنية.

العمود الواحد الذي يحتاجه كل جدول

إليك القاعدة الذهبية: كل جدول يخزّن بيانات العملاء يجب أن يحتوي عمود organization_id. ليس «ينبغي». وليس «يمكن إضافته لاحقًا». يجب، من اليوم الأول.

لا تحتاج إلى كتابة شيفرة لتفهمه. مفاهيميًا، كل صف في قاعدة بياناتك يحمل وسمًا يقول إلى أي عميل ينتمي. في جدول مهام لمدير مهام، «صمّم الصفحة الرئيسية» يحمل وسم Acme؛ و«راجع أرقام الربع الثالث» يحمل وسم TechStart. وفي كل مرة يقرأ التطبيق بيانات لا يطلب إلا الصفوف التي تحمل وسم العميل الحالي. وفي كل مرة يكتب بيانات يختم الصف الجديد بذلك الوسم. Acme ترى مهام Acme. وTechStart ترى مهام TechStart. الوسم هو مفتاح الشقة.

يبدو هذا مملًّا. لكنه أيضًا الأساس الذي يجعل كل شيء آخر يعمل، بما في ذلك طبقة الأمان التي تفرضه تلقائيًا على مستوى قاعدة البيانات، وهي تستحق مقالها الخاص (وتحصل عليه).

الكتابThe Solopreneur Revolutionلويس غونسالفيس عن بناء مشروع رائد أعمال منفرد بالذكاء الاصطناعي دون ترك وظيفتك.احصل على الكتاب ←

«لكن لدي عميل واحد فقط الآن»

أسمع هذا باستمرار. إليك الفيلم الذي يُعرض حين تتخطى تعدد المستأجرين:

• اليوم 1: تبني لعميل واحد. كل شيء يعمل. لا حاجة إلى وسوم، فكل البيانات تخصه على أي حال.
• اليوم 30: تكسب عميلًا ثانيًا. العميلان الآن يريان بيانات بعضهما. ذعر. إضافة الوسم لاحقًا إلى كل جدول تعني نحو ثلاثة أسابيع من العمل، وتوقف الإنتاج، وعملاء غاضبين.
• الفيلم البديل: تبني بـorganization_id من اليوم 1. في اليوم 30، يعمل العميل الثاني ببساطة. وفي اليوم 300، لديك 100 عميل ولم تُجرِ أي تغيير في قاعدة البيانات.

صديق لي بنى SaaS بدون تعدد المستأجرين. حين وصل إلى عميله العاشر، أمضى ثلاثة أشهر يعيد بناء قاعدة بياناته كلها. ثلاثة أشهر بلا ميزات جديدة بينما ينتظر العملاء. لا تكن ذلك الشخص.

وهذا أيضًا سبب إلحاحي على تصميم قاعدة البيانات قبل أن تكتب طلبك: القرارات الرخيصة في اليوم الأول، عمود واحد وعادة واحدة، تصبح باهظة بقسوة في اليوم 300.

القواعد الثلاث التي تُبقيه سريعًا وآمنًا

القاعدة 1: اوسم كل جدول، بلا استثناءات. في اللحظة التي يفتقد فيها جدول واحد organization_id يصبح ذلك الجدول تسريب بيانات ينتظر أن يحدث. حين توجّه الذكاء الاصطناعي، اجعل هذا تعليمة دائمة لا طلبًا لكل مهمة، فهو بالضبط نوع القاعدة التي تنتمي إلى قراراتك على مستوى المعماري، لأن الذكاء الاصطناعي سيتخطاها بسرور ما لم تُصرّ.

القاعدة 2: افهرس الوسم. الفهرس هو دليل هاتف قاعدة البيانات: يتيح لها القفز مباشرةً إلى صفوف عميل واحد بدل قراءة كل صف للتحقق من الوسم. والفرق ليس أكاديميًا: مع مليون صف عبر 1,000 منظمة، يستغرق بحث بلا فهرس نحو 2,000 ميلي ثانية. ومع الفهرس يستغرق البحث نفسه نحو 5. اطلب من الذكاء الاصطناعي إضافة فهرس على organization_id لكل جدول ينشئه.

القاعدة 3: لا تثق بالمتصفح ليقول من يسأل. يجب أن تأتي هوية العميل من جلسة تسجيل الدخول على الخادم، لا من شيء يرسله المتصفح. إذا استطاع مستخدم خبيث أن يقول لتطبيقك «أنا المنظمة X»، فسيقرأ بيانات المنظمة X. الخادم يعرف من سجّل الدخول؛ وهذا هو مصدر الحقيقة الوحيد.

ثلاث قواعد. عمود واحد. هذا هو الفرق بين عرض تجريبي ومنتج تستطيع بيعه لعميلك الثاني والعاشر والألف.

12 أسبوعاًمسيرتك في الشركات لم تكن الخطة أبداًقدّم طلبك إلى Solopreneur Accelerator.قدّم الآن ←

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

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

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

هل أحتاج إلى تعدد المستأجرين إن كان لدي عميل واحد فقط؟

نعم، فهذا بالضبط الوقت الذي يكون فيه رخيصًا. إضافة عمود organization_id في اليوم الأول لا تكلّفك شيئًا. أما إضافته بعد وصول العميل الثاني فتكلّف أسابيع؛ فقد أمضى مؤسس أعرفه ثلاثة أشهر في إعادة البناء عند العميل العاشر. ابنِه من الجدول الأول.

هل يستطيع الذكاء الاصطناعي إعداد تعدد المستأجرين لي إن كنت لا أبرمج؟

نعم، إن أعطيته القاعدة صراحةً: «كل جدول يخزّن بيانات العملاء يجب أن يحتوي عمود organization_id، مع فهرس، وكل استعلام يجب أن يرشّح به». أدوات الذكاء الاصطناعي تتبع هذا النمط بموثوقية حين تُعطى التعليمة، وتتخطاه بشكل غير متوقع حين لا. أنت تقدّم القاعدة، والذكاء الاصطناعي يقدّم التنفيذ.

هل قاعدة بيانات مشتركة واحدة آمنة بما يكفي لبيانات العملاء؟

نعم، حين تُنفَّذ بشكل صحيح. وسم organization_id مع أمان على مستوى قاعدة البيانات (أمان مستوى الصف، الذي يفرض الوسم تلقائيًا على كل استعلام) هو الطريقة التي تعالج بها كل منتجات SaaS الحديثة تقريبًا العزل، وهو النهج نفسه الذي يخدم منتجات فيها آلاف المنظمات. الخيار غير الآمن هو النسخة المبنية جزئيًا: قاعدة بيانات مشتركة بلا وسوم وبلا إنفاذ.