هل يجب علي استخدام إعداد قاعدة بيانات واحدة أو متعددة لتطبيق متعدد العملاء؟

StackOverflow https://stackoverflow.com/questions/255616

سؤال

أنا أعمل على تطبيق PHP يهدف إلى تسهيل سير عمل الشركة وإدارة المشاريع، دعنا نقول شيئًا من هذا القبيل معسكر القاعدة و GoPlan.

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

السلبيات المحتملة التي يمكنني التفكير فيها باستخدام قاعدة بيانات واحدة:

  • عدم القابلية للتوسعة
  • مشاكل أمنية (على الرغم من الأخطاء لا ينبغي أن يكون هناك في المقام الأول)

ما هي أفكارك حول هذا؟هل لديك أي أفكار حول الحل الذي من المرجح أن تختاره الشركات المذكورة أعلاه؟

هل كانت مفيدة؟

المحلول

أقوم عادةً بإضافة ClientID إلى جميع الجداول واستخدام قاعدة بيانات واحدة.ولكن بما أن قاعدة البيانات عادة ما تكون صعبة التوسع، فسوف أجعل من الممكن أيضًا تشغيلها على مثيلات قاعدة بيانات مختلفة لبعض العملاء أو جميعهم.

بهذه الطريقة يمكنك الحصول على مجموعة من العملاء الصغار في قاعدة بيانات واحدة والعملاء الكبار على خوادم منفصلة.

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

نصائح أخرى

استمع إلى بودكاست Stackoverflow حيث يتحدث جويل وجيف عن نفس السؤال.يتحدث جويل عن تجربتهم في تقديم نسخة مستضافة من برامجهم.ويشير إلى أن إضافة معرفات العميل في جميع أنحاء قاعدة البيانات الخاصة بك يؤدي إلى تعقيد التصميم والتعليمات البرمجية (هل أنت متأكد من أنك لم تنس عن طريق الخطأ إضافتها إلى بعض فقرات WHERE؟) وتعقيد ميزة الاستضافة، مثل النسخ الاحتياطية الخاصة بالعميل.

كان في الحلقة رقم 20 أو رقم 21 (راجع النصوص للحصول على التفاصيل).

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

فكر في النسخ الاحتياطي لقاعدة البيانات.يقول العميل "أ" "من فضلك أرسل لي نسخة من بياناتي".أسهل بكثير في إعداد قاعدة بيانات منفصلة عما إذا كانت قاعدة بيانات واحدة مشتركة.فكر في إزالة العميل؛مرة أخرى، أسهل بكثير مع قواعد بيانات منفصلة.

(الجزء "البنية التحتية" غير واضح نظرًا لوجود اختلافات كبيرة بين أنظمة إدارة قواعد البيانات المختلفة حول ما يشكل "قاعدة بيانات" مقابل "مثيل الخادم"، على سبيل المثال. يضيف:تم وضع علامة على السؤال "mysql"، لذا ربما لا تكون هذه الأفكار ذات صلة تمامًا.)

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

من الواضح أن StackOverflow (كمثال) لا يحتوي على قاعدة بيانات منفصلة لكل مستخدم؛نحن جميعا نستخدم نفس قاعدة البيانات.ولكن إذا كنت تدير أنظمة محاسبية لشركات مختلفة، فلا أعتقد أنه سيكون من المقبول (للشركات، وربما ليس للأشخاص القانونيين) مشاركة قواعد البيانات.

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

  • أداءللأداء، استخدم قاعدة بيانات للجميع.فكر في تجميع الاتصالات، والذاكرة المشتركة، والتخزين المؤقت، وما إلى ذلك.

  • عملإذا كانت خطة عملك تهدف إلى الحصول على الكثير من العملاء الصغار (مثل hotmail)، فمن المحتمل أن تعمل على قاعدة بيانات واحدة.والقيام بجميع المهام الإدارية مثل التسجيل والحذف وترحيل البيانات وما إلى ذلك.مؤتمتة بالكامل ومكشوفة في واجهة ودية.إذا كنت تخطط للحصول على العشرات أو ما يصل إلى بضع مئات من العملاء الكبار، فيمكنك العمل في قاعدة بيانات واحدة لكل عميل والحصول على نصوص برمجية لإدارة النظام يمكن تشغيلها بواسطة موظفي دعم العملاء لديك.

الأتى تسجيل الشاشة يشرح كيف يتم ذلك على salesforce.com.يستخدمون قاعدة بيانات واحدة مع عمود OrgId خاص يحدد بيانات كل مستأجر.هناك الكثير لذلك، لذا يجب عليك النظر في هذا.سأذهب مع نهجهم.

هناك عظيم آخر شرط حول ذلك على MSDN.إنه يشرح بعمق متى يجب عليك استخدام نهج مشترك أو معزول.تذكر أن وجود قاعدة بيانات مشتركة لجميع المستأجرين له بعض الآثار الأمنية المهمة وإذا كانوا جميعًا يشتركون في نفس كائنات قاعدة البيانات، فقد ترغب في استخدام [أمان مستوى الصف] - اعتمادًا على نظام إدارة قواعد البيانات الذي تستخدمه (أنا متأكد من أنه ممكن في MS SQL Server وOracle، وربما في IBM DB2 أيضًا).يمكنك استخدام الحيل مثل الأمان على مستوى الصف في MySQL لتحقيق نتائج مماثلة (مشاهدات + مشغلات).

بالنسبة للإيجارات المتعددة، سيزيد الأداء عادةً كلما زاد عدد الموارد التي تدير مشاركتها بين المستأجرين، راجع

http://en.wikipedia.org/wiki/Multitenancy

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

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

عندما تقوم بتصميم قاعدة بيانات متعددة المستأجرين، يكون لديك بشكل عام ثلاثة خيارات:

  1. لديك قاعدة بيانات واحدة لكل مستأجر
  2. لديك مخطط واحد لكل مستأجر
  3. اطلب من جميع المستأجرين مشاركة نفس الجدول (الجداول)

الخيار الذي تختاره له آثار على قابلية التوسع والتوسعة والعزلة.وقد نوقشت هذه الآثار على نطاق واسع عبر مختلف أسئلة StackOverflow ومقالات قاعدة البيانات.

ومن الناحية العملية، يمكن لكل خيار من خيارات التصميم الثلاثة - بجهد كافٍ - أن يعالج الأسئلة المتعلقة بالحجم، والبيانات التي تختلف بين المستأجرين، والعزلة.يعتمد القرار على البعد الأساسي الذي تقوم بالبناء من أجله.موجز:

  • إذا كنت تقوم بالبناء على نطاق واسع:اطلب من جميع المستأجرين مشاركة نفس الجدول (الجداول)
  • إذا كنت تبني من أجل العزلة:إنشاء قاعدة بيانات واحدة لكل مستأجر

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

يعود القرار إلى البعد الأساسي الذي تعمل على تحسين تصميم قاعدة بياناتك من أجله. هذه المقالة حول تصميم قاعدة بيانات SaaS الخاصة بك على نطاق واسع يتحدث عن المقايضات ويقدم ملخصًا في سياق PostgreSQL.

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

إن وجود قاعدة بيانات لكل عميل لا يتسع بشكل عام.تحتفظ MySQL (وربما قواعد بيانات أخرى) بموارد مفتوحة لكل جدول، وهذا لا يناسب الجداول التي يزيد عددها عن 10 آلاف في مثيل واحد، وهو ما قد يحدث في حالة تعدد الإيجارات واسعة النطاق.

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

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

ومع ذلك، لا تعني المشاركة قاعدة بيانات واحدة (أو مثيلًا) لكل مستأجر، بل تعني قاعدة بيانات واحدة لكل جزء أو مجموعة من الأجزاء، والتي قد تحتوي كل منها على عدة مستأجرين.سوف تحتاج إلى اكتشاف معلمات الضبط المناسبة لنفسك، ربما في الإنتاج (وبالتالي ربما تحتاج إلى أن تكون قابلة للضبط تمامًا منذ البداية)

€ لا أستطيع أن أضمن ذلك.

يمكنك البدء بقاعدة بيانات واحدة وتقسيمها مع نمو التطبيق.إذا قمت بذلك، هناك بعض الأشياء التي أود أن أوصي بها:

1) تصميم قاعدة البيانات بطريقة يمكن تقسيمها بسهولة.على سبيل المثال، إذا كان العملاء سيشاركون البيانات، فتأكد من نسخ البيانات بسهولة عبر كل قاعدة بيانات.

2) عندما يكون لديك قاعدة بيانات واحدة فقط، تأكد من عمل نسخة احتياطية لها على خادم فعلي آخر.في حالة تجاوز الفشل، يمكنك إعادة حركة المرور إلى هذا الخادم الآخر مع الحفاظ على بياناتك سليمة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top