it-swarm.asia

قاعدة بيانات واحدة كبيرة مقابل العديد من الأصغر منها

لدينا موقف حيث يمكننا (أ) نشر مثيلات تطبيقات في قاعدة بيانات MySQL واحدة باستخدام بادئة الجدول أو (ب) استخدام قواعد بيانات MySQL مختلفة لكل مثيل من التطبيق ، على سبيل المثال ،

أعد ال":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

النتيجة النهائية هي ديسيبل كبير مع العديد من الجداول.

الإعداد "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

والنتيجة النهائية هي العديد من قواعد البيانات مع بعض الجداول.

كل الأشياء متساوية (على سبيل المثال ، كمية البيانات ، عدد مثيلات التطبيق ، وما إلى ذلك) ، ما هي إيجابيات وسلبيات الذهاب مع أي من النهجين؟ ما الذي يضر بأداء قاعدة البيانات وصيانتها؟ التطبيق PHP 5 قائم ، يعمل على Apache 2.x ، ونقوم بتشغيل MySQL 5.x.

شكرا جزيلا على وقتك وأفكارك!

14
KM.

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

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

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

السبب الذي جعلني أتبع هذا النهج بدلاً من منهج قاعدة البيانات الضخمة الفردية ، هو الحجم الهائل لقاعدة البيانات المحتملة التي كان سيتم إنشاؤها ... تحتوي كل واحدة من 1000 قاعدة بيانات على 200 جدول ، والعديد من الجداول الفردية داخل كل من تضم قواعد البيانات عدة مئات من ملايين صفوف البيانات!

يتطلب تكوين قاعدة بيانات واحدة جداول معينة (حوالي 8 منها) أن تحتوي على مليارات من صفوف البيانات ، وكان إجمالي حجم قاعدة البيانات أكبر من 10 تيرابايت. تمكنا من امتلاك عدة خوادم بسعة تخزين 5 تيرابايت من RAID 10 ، مع العديد من قواعد البيانات على كل منها.

هذا ما سأفعل! آمل أن يساعدك على اتخاذ القرار ... :)

14
Dave Rix

هل التطبيق الذي تنشئه SaaS تطبيق؟ إذا كان الأمر كذلك ، أقترح عليك التفكير في نهج ثالث - لديه قاعدة بيانات واحدة ، مع بنية مشتركة لجميع مثيلات التطبيق مع اختلاف واحد - إضافة معرف مستخدم عمود/applicationid في جميع الجداول. سيؤدي هذا إلى تقليل تكاليف تطوير/صيانة التطبيق بشكل كبير. وهذا في تجربتي هو أحد أفضل الأساليب لتخزين البيانات متعددة المستأجرين.

انظر أيضًا هذا ورق أبيض رائع من Microsoft على بنية بيانات متعددة المستأجرين

كما يسلط الضوء على مزايا/عيوب النهج التي ذكرتها.

11
Dharmendar Kumar 'DK'

الإعداد B أسهل في الإدارة

كل tablen يجلس في مجلد مختلف. يمكن أن يكون ذلك مفيدًا جدًا إذا كنت لا تريد اختبار حدود نظام التشغيل.

على سبيل المثال ، يستضيف صاحب العمل MySQL لنظام CRM لوكلاء السيارات. العميل لديه 800 وكالة. تحتوي كل قاعدة بيانات لبيع 160 جدولاً. أي 128000 طاولة.

  • تحت الإعداد A ، سيتم وضع كافة الجداول 128000 تحت قاعدة بيانات واحدة.
  • تحت الإعداد B ، كل مجموعة من 160 جدول تقع في مجلد فرعي تحت/var/lib/mysql.

من منظور نظام التشغيل وقدرته على التعامل مع العقد i (أو جداول FAT لنظام التشغيل Windows) ، والتي تتضمن الحد الأقصى من الملفات لكل مجلد:

  • ضمن الإعداد A ، قد تقلق بشأن 128000 ملف ضمن مجلد واحد. هل يمكن لنظام التشغيل الخاص بك دعم العديد من الملفات ضمن مجلد واحد؟
  • تحت الإعداد B ، لا تقلق.

إذا كان عليك تعديل هياكل الجدول باستخدام ALTER TABLE أو بعض DDL:

  • تحت الإعداد A ، يجب عليك كتابة DDL المطلوب باستخدام برنامج PHP (أو نصوص MySQL متخصصة) مقابل اسم الجدول المحدد والاستعلامات المقابلة قبل الوصول إليه وإجراء التغييرات
  • ضمن الإعداد B ، اتصل بقاعدة البيانات الصحيحة ، ثم قم بالوصول إلى نفس الجدول المسمى في كل مرة. سيكون نموذج الوصول نظيفًا دائمًا:
    • قاعدة بيانات محددة
    • مجلد محدد تحت /var/lib/mysql
    • Specfic TableName.

إذا كنت ترغب في وضع قواعد بيانات مختلفة على أقراص مختلفة:

  • تحت الإعداد A ، سيؤدي الارتباط الرمزي لكل جدول يتم نقله إلى قرص منفصل إلى تفاقم مشكلة "عدد وحدات الإرسال في مجلد" فقط. يؤدي إدخال/إخراج القرص وإمكانية الوصول إلى الجدول بشكل عام إلى تعقيد المزيد ويزيد الحمل الإجمالي للخادم منذ .frm يتم الوصول إلى الملفات بشكل متكرر.
  • تحت الإعداد B ، انقل مجلد قاعدة بيانات بالكامل إلى تحميل بيانات منفصل. يمكن توزيع القرص I/O عند الطلب.
  • CAVEAT: غير محبذ للغاية لـ InnoDB

التحدث بشكل مجازي ، أيهما تفضل؟

  • شقة عملاقة بها غرفة نوم واحدة وحمام واحد ومطبخ (ابا)
  • شقق متعددة ، لكل منها غرفة نوم خاصة بها وحمام ومطبخ (SetupB)

عندما يتعلق الأمر بإصلاح المبرد في شقة:

  • مع الإعداد A ، يمكن أن يكون كل مستأجر مزعجًا ويجب أن يشارك لأنه يجب عليك التحدث مع المستأجرين المتضررين أمام الجميع مثل أعمال الجميع
  • مع الإعداد B ، بخلاف سماع بعض الضجيج على الحائط أو في الأنابيب ، يمكن للمستأجرين الاستمرار في حياتهم الخاصة
  • هذه القائمة واستعاراتها يمكن أن تستمر وتطول

IHMO على الرغم من أن الميزانيات قد تكون قوة دافعة لتصميم قرارات/البنية التحتية ، إلا أنني سأؤيد بسهولة قواعد البيانات المنفصلة لكل عميل.

9
RolandoMySQLDBA

لدي أيضًا SaaS منتج واستخدم نفس الإعداد الذي ذكره Dave Rix.

لكل عميل قاعدة بيانات خاصة به

سأقدم بعض الاقتراحات الأخرى:

  • يجب أن يكون لديك قاعدة بيانات "تحكم" متوازنة في التحميل (رئيسية - رئيسية) ، تقوم بتخزين موقع قاعدة البيانات (ip) واسم قاعدة البيانات واسم العميل. وحدة التحكم هذه هي المكان الذي يعرف فيه تطبيقك مكان قاعدة بيانات كل عميل.

  • يمكن أن يكون تطبيقك في أي مكان تريده - يمكن أن يكون لديك قواعد بيانات للعديد من مراكز البيانات حول العالم.

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

  • يمكنك إنشاء عرض/قاعدة بيانات مخصصة لبعض العملاء - دون التأثير على الآخرين. هذا مهم إذا حاولت تقديم التخصيص كجزء من عملك.

  • يمكنك إعداد مجموعتي ويب + مزارع قاعدة بيانات: واحدة لـ "Edge" والأخرى لإصدارات "مستقرة". بعد ذلك ، ستحتاج إلى وجود مجموعة صغيرة من العملاء المستعدين لاختبار الأشياء والتأكد من أن كل شيء يعمل كما هو متوقع (وبعبارة أخرى ، ضمان الجودة [QA]) ، قبل التقدم بطلب إلى جميع عملائك.

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

  • يجب أن يكون لديك خادم آخر للقيام بالنسخ المتماثل. يمكن للمضيف نفسه نسخ العديد من قواعد البيانات (استخدم منافذ مختلفة لكل خادم في نفس المضيف) إذا كنت لا تستطيع تحمل نفس المقدار من خوادم المضيف "الرئيسية" و "التابعة".

    على سبيل المثال ، 5 خوادم رئيسية + 1 خادم تابع مع 5 قواعد بيانات تعمل على منافذ مختلفة - فقط لديك RAM يكفي للقيام بذلك.

  • يجب عليك استخدام أداة "الترحيل" لنقل قاعدة بيانات واحدة إلى خادم آخر في أي وقت تريده.

  • يجب عليك ترحيل VIP العملاء إلى خادم قاعدة بيانات أكثر أمانًا/متوفرًا للحفاظ على أرباحك محمية. تذكر أن 20٪ من العملاء يمثلون 80٪ من أرباحك مرات عديدة. اعتني بالعملاء الخاصين.

  • يجب أن يكون لديك جامع "قمامة" لحذف النسخ الاحتياطي ، للقيام بـ "آخر نسخة احتياطية" وحذف قاعدة البيانات عندما يغادر العميل شركتك.

  • يجب أن يكون لديك صورة قاعدة بيانات حيث تقوم بالتصدير والاستخدام للحسابات الجديدة.

  • يجب أن يكون لديك أداة تصحيح قاعدة بيانات لتطبيق تصحيحات جديدة على الحسابات الموجودة.

  • احتفظ بنسخ من جميع تصحيحات SQL الخاصة بك ، باستخدام أداة إصدار مثل Subversion أو git وإنشاء الترقيم الخاص بك أيضًا. xxx-4.3.0.sql - أحيانًا يحدث التصحيح بشكل خاطئ ويجب أن تعرف كيفية استرداد/إكمال مهمة التصحيح.

حسنًا ، هذا كل ما أفعله في شركتي بمنتج يحتوي على حوالي 5 آلاف من قواعد البيانات مع حوالي 600 جدول لكل منها.

3
b0x