نوصي بهذا النهج لأنه الأسهل من حيث الإدارة، لا سيما عندما يشترك جميع المستأجرين في مخطط البيانات نفسه وتكون أحجام البيانات متوسطة (< TBs)من خلال تجميع جميع بيانات المستأجرين في جدول واحد، تتحسن كفاءة التخزين بفضل تحسين ضغط البيانات وتقليل العبء الإضافي للبيانات الوصفية. بالإضافة إلى ذلك، تصبح تحديثات المخطط أبسط لأن جميع البيانات تُدار مركزيًا. تكون هذه الطريقة فعّالة بشكل خاص عند التعامل مع عدد كبير من المستأجرين (قد يصل إلى الملايين). ومع ذلك، قد تكون الأساليب البديلة أنسب إذا كانت لدى المستأجرين مخططات بيانات مختلفة أو كان من المتوقع أن تتباعد بمرور الوقت. في الحالات التي يوجد فيها تفاوت كبير في حجم البيانات بين المستأجرين، قد يتأثر أداء الاستعلام لدى المستأجرين الأصغر سلبًا بشكل غير ضروري. لاحظ أن هذه المشكلة يجري التخفيف منها إلى حد كبير عبر تضمين حقل المستأجر في المفتاح الأساسي. يوضح هذا المثال كيفية تنفيذ نموذج تعدد المستأجرين باستخدام جدول مشترك. أولًا، لنُنشئ جدولًا مشتركًا يتضمن الحقل
tenant_id ضمن المفتاح الأساسي.
user_1 وuser_2.
user_1 وuser_2 بحيث لا يتمكنان من الوصول إلا إلى بيانات المستأجرين الخاصة بكلٍّ منهما.
GRANT SELECT على الجدول المشترك باستخدام دور عام.
user_1 وتشغيل استعلام SELECT بسيط. لن تُعاد إلا الصفوف التابعة للمستأجر الأول.
جداول منفصلة
يُعد استخدام جداول منفصلة خيارًا جيدًا عندما تختلف مخططات البيانات بين المستأجرين.في السيناريوهات التي تتضمن عددًا قليلًا من المستأجرين مع مجموعات بيانات كبيرة جدًا، حيث يكون أداء الاستعلامات عاملًا حاسمًا، قد يتفوّق هذا النهج على نموذج الجدول المشترك. وبما أنه لا توجد حاجة إلى تصفية بيانات المستأجرين الآخرين، يمكن أن تكون الاستعلامات أكثر كفاءة. بالإضافة إلى ذلك، يمكن تحسين المفاتيح الأساسية بدرجة أكبر، إذ لا حاجة إلى تضمين حقل إضافي (مثل معرّف المستأجر) في المفتاح الأساسي. لاحظ أن هذا النهج لا يتدرّج جيدًا عند التعامل مع آلاف المستأجرين. راجع حدود الاستخدام. هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام جداول منفصلة. أولاً، لننشئ جدولين، أحدهما لأحداث
tenant_1 والآخر لأحداث tenant_2.
user_1 وuser_2.
GRANT SELECT على الجدول المقابل.
user_1 وتنفيذ استعلام select بسيط من الجدول المخصص لهذا المستخدم. ستُعاد فقط الصفوف الخاصة بالمستأجر الأول.
قواعد بيانات منفصلة
يكون هذا النهج مفيدًا إذا كان كل مستأجر يحتاج إلى عدد كبير من الجداول، وربما إلى عروض مادية أيضًا، وكان لديه مخطط بيانات مختلف. ومع ذلك، قد تصبح إدارته صعبة إذا كان عدد المستأجرين كبيرًا.يشبه التنفيذ نهج الجداول المنفصلة، ولكن بدلًا من منح الامتيازات على مستوى الجدول، تُمنَح الامتيازات على مستوى قاعدة البيانات. لاحظ أن هذا النهج لا يتوسع جيدًا عند وجود آلاف المستأجرين. راجع حدود الاستخدام. هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام قواعد بيانات منفصلة. أولًا، لننشئ قاعدتي بيانات، واحدة لـ
tenant_1 وأخرى لـ tenant_2.
user_1 وuser_2.
GRANT SELECT على الجدول المعني.
user_1 وتشغيل استعلام select بسيط على جدول events في قاعدة البيانات المناسبة. لا تُرجع النتيجة إلا الصفوف الخاصة بالمستأجر الأول.
فصل الحوسبة عن الحوسبة
خدمة سحابية منفصلة
قد يكون هذا الأسلوب، وهو أقل شيوعًا، مناسبًا إذا كان من المطلوب تخزين بيانات المستأجرين في مناطق مختلفة لأسباب قانونية أو أمنية أو لقربها الجغرافي.يجب إنشاء حساب مستخدم على كل خدمة، بحيث يتمكن المستخدم من الوصول إلى بيانات المستأجر التابعة له على تلك الخدمة. يصعب إدارة هذا النهج، كما يضيف عبئًا إضافيًا مع كل خدمة، إذ تتطلب كل واحدة منها بنية تحتية خاصة بها للتشغيل. ويمكن إدارة الخدمات عبر ClickHouse Cloud API، مع إمكانية الأتمتة كذلك باستخدام موفّر Terraform الرسمي. هذا مثال على تطبيق نموذج تعدد المستأجرين باستخدام خدمة منفصلة. لاحظ أن المثال يوضح إنشاء الجداول والمستخدمين على خدمة ClickHouse واحدة، وسيكون عليك تكرار ذلك على جميع الخدمات. أولًا، لننشئ الجدول
events
user_1
GRANT SELECT على الجدول المعني.
user_1 في الخدمة الخاصة بالمستأجر 1 وتشغيل استعلام SELECT بسيط. لا تُعاد إلا الصفوف التابعة للمستأجر الأول.