it-swarm.asia

تصميم منصة: قاعدة بيانات واحدة أو قواعد بيانات متعددة؟

نحن نبني نظامًا أساسيًا على الويب يشتمل على خدمات متعددة ، لكل منها بياناته الأساسية. يتم بناء هذه الخدمات بشكل مستقل وفقًا لمبادئ الهندسة الموجهة نحو الخدمة ، لكنها تتعامل مع البيانات المحتملة ذات الصلة. نحن ندرس ما إذا كان ينبغي لهذه الخدمات مشاركة قاعدة بيانات كبيرة واحدة أو أن يكون لكل منها قاعدة بيانات خاصة بها. (نحن نخطط لاستخدام SQL Server 2008 Enterprise على مجموعة Windows 2008.)

تشمل بعض المزايا لكل نهج نظرنا فيه بالفعل ما يلي:

قاعدة بيانات واحدة

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

قواعد بيانات متعددة

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

من منظور تشغيلي ، هل من الأفضل أن تحصل كل خدمة في هذا النظام الأساسي على قاعدة بيانات خاصة بها ، أم أنها تذهب جميعها في نفس قاعدة البيانات؟ ما العوامل الرئيسية التي تفيد في الإجابة على هذا السؤال؟

31
Nick Chammas

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

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

أوصي بقراءة مواقع مثل HighScalability.com التي تحفر في البنى المعتمدة من قبل مواقع الويب من النوع الذي لا يفشل أبدًا. واحدة من المفضلة لدي في الآونة الأخيرة كانت قصة Netflix Chaos Monkey التي تم ذكرها في Coding Horror .

معالجة نقطتين في سؤالك:

في حالة وقوع كارثة ، تكون استعادة النظام الأساسي إلى حالة متسقة أسهل.

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

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

يمكن أن تساعد حلول ذاكرة التخزين المؤقت الموزعة (memcached et al) هنا ولكنك تنتهك مبادئ استقلالية الخدمة. قد يكون هذا مشابهًا لوجود خدمتين تتواصلان مع بعضهما البعض بشكل مباشر ، أو الأسوأ من ذلك أن يكون لديهما مخزن بيانات الوصول إلى الخدمة ، متجاوزًا واجهة الخدمة تمامًا. حتمًا ستكون البيانات ذات صلة وسيتم تسليمها بين الخدمات بواسطة النظام الأساسي للاتصال ، وتميل القرارات الصعبة حول الخدمة التي ستمتلك أجزاء البيانات. قد يكون موقع StackOverflow أو مواقع المبرمجين في وضع أفضل للمساعدة في حل المشكلات العامة SOA.

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

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

إذا لم يكن هذا SOA ولديك فقط حالة حيث يتم بناء الخدمات المكونة لهذا النظام الأساسي من قبل فرق/موردين مختلفين لأسباب لوجستية ، والتزم بقاعدة بيانات واحدة وتجاهل كل شيء أعلاه تمامًا ! :)

18
Mark Storey-Smith