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

الجدول المشترك

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

مثال

يوضح هذا المثال كيفية تنفيذ نموذج تعدد المستأجرين باستخدام جدول مشترك. أولًا، لنُنشئ جدولًا مشتركًا يتضمن الحقل tenant_id ضمن المفتاح الأساسي.
لنُدرِج بيانات وهمية.
ثم لنُنشئ مستخدمَين user_1 وuser_2.
نُنشئ سياسات الصفوف التي تقيّد user_1 وuser_2 بحيث لا يتمكنان من الوصول إلا إلى بيانات المستأجرين الخاصة بكلٍّ منهما.
ثم امنح امتيازات GRANT SELECT على الجدول المشترك باستخدام دور عام.
الآن يمكنك الاتصال باسم user_1 وتشغيل استعلام SELECT بسيط. لن تُعاد إلا الصفوف التابعة للمستأجر الأول.

جداول منفصلة

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

مثال

هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام جداول منفصلة. أولاً، لننشئ جدولين، أحدهما لأحداث tenant_1 والآخر لأحداث tenant_2.
لنقم بإدراج بيانات وهمية.
ثم لنقم بإنشاء مستخدمَين user_1 وuser_2.
ثم امنح صلاحيات GRANT SELECT على الجدول المقابل.
يمكنك الآن الاتصال بوصفك user_1 وتنفيذ استعلام select بسيط من الجدول المخصص لهذا المستخدم. ستُعاد فقط الصفوف الخاصة بالمستأجر الأول.

قواعد بيانات منفصلة

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

مثال

هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام قواعد بيانات منفصلة. أولًا، لننشئ قاعدتي بيانات، واحدة لـ tenant_1 وأخرى لـ tenant_2.
لنُدرِج بيانات وهمية.
ثم لنُنشئ مستخدمَين هما user_1 وuser_2.
ثم امنح امتياز GRANT SELECT على الجدول المعني.
الآن يمكنك الاتصال باستخدام user_1 وتشغيل استعلام select بسيط على جدول events في قاعدة البيانات المناسبة. لا تُرجع النتيجة إلا الصفوف الخاصة بالمستأجر الأول.

فصل الحوسبة عن الحوسبة

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

خدمة سحابية منفصلة

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

مثال

هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام خدمة منفصلة. لاحظ أن المثال يوضح إنشاء الجداول والمستخدمين على خدمة ClickHouse واحدة، وسيكون عليك تكرار ذلك على جميع الخدمات. أولًا، لننشئ الجدول events
لنُدرِج بيانات تجريبية.
ثم لننشئ مستخدمَين user_1
ثم امنح امتياز GRANT SELECT على الجدول المعني.
الآن يمكنك الاتصال باسم user_1 في الخدمة الخاصة بالمستأجر 1 وتشغيل استعلام SELECT بسيط. لا تُعاد إلا الصفوف التابعة للمستأجر الأول.
آخر تعديل في ٢٥ يونيو ٢٠٢٦