قاعدة بيانات النظام الجيد نقطة فصل؟

Question

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

يحتوي النظام B حاليا عملية استدعاء البيانات في جدول DB ويعالج أي صفوف جديدة تم إدراجها.

التصميم المقترح واحد هو للنظام أ على سبيل المثال إدراج البيانات في جدول DB System B ونظام نظام B System B بالصفوف الجديدة من خلال العملية الحالية. السؤال هل هذا الحل يلبي متطلبات فصل النظامين؟ هل تعتبر قاعدة بيانات تعتبر جزءا من نظام B والتي قد تصبح غير متوفرة وتسبب نظام للتفجير؟

حل آخر هو للنظام A لوضع البيانات في قائمة انتظار MQ ولديك عملية من شأنها أن تقرأ من MQ ثم إدراج قاعدة بيانات النظام B. ولكن هل هذا فقط النفقات العامة فقط؟ في النهاية هو قائمة انتظار MQ أي خطأ أكثر تسامحا من جدول DB؟

Answer 1

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

هناك أربعة مستويات شائعة من التكامل:

1. تقاسم قاعدة البيانات
2. مشاركة الملفات
3. إجراء اتصال عن بعد
4. رسالة تمر

والتي يمكن تطبيقها ومجتمعة في المواقف المختلفة، مع توفر مختلف ومقابلته. لديك نظرة عامة ممتازة في موقع أنماط تكامل المؤسسة.

كما هو الحال مع أي بنية تحتية للتكامل المركزية، يجب استضافة MQ في بيئة ذات توفر كبير وفشل كامل & ج. هناك حلول قائمة الانتظار الأخرى التي تسمح لك بتوزيع تنسيق قائمة الانتظار.

Answer 2

استخدام قوائم الانتظار للاتصال. لا "تمر" البيانات من النظام A إلى النظام B من خلال قاعدة البيانات. أنت تستخدم قاعدة البيانات كقائمة انتظار رسائل عملاقة ومكلفة معقدة.

استخدم قائمة انتظار الرسائل كقائمة انتظار الرسائل.

هذا ليس علما "إضافيا". هذه هي أفضل طريقة لتفكيك الأنظمة. يطلق عليه اسم الهندسة المعمارية الموجهة نحو الخدمة (SOA) واستخدام الرسائل أمر أساسي للغاية للتصميم.

قائمة انتظار MQ أبسط بكثير من جدول DB.

لا تقارن "عدم التسامح مع الأخطاء" لأن RDBMS تستخدم نزاعا كبيرا (لا يمكن تصوره تقريبا) لتحقيق مستوى معقول من الضمان بأن معاملتك قد انتهت بشكل صحيح. قفل. التخزين المؤقت. كتابة قوائم الانتظار. ادارة التخزين. إلخ.

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

Answer 3

في SQL Server، سأفعل ذلك من خلال حزمة SSIS أو وظيفة (اعتمادا على عدد السجلات وتعقيد ما كنت تتحرك). قواعد البيانات الأخرى لديها أيضا حلول ETL. أحب محلول ETL لأنني يمكنني الاحتفاظ بسجلات ما تم تغييره وما تم معالجته الأخطاء، يمكنني إرسال سجلات لا تذهب لسبب ما لن يذهب إلى النظام الآخر (نادرا ما تكون هياكل البيانات هي نفسها بين قاعدتين) الجدول دون قتل بقية العملية. يمكنني أيضا إجراء تغييرات على البيانات عند التدفقات لضبط اختلافات قاعدة البيانات (أشياء مثل قيم جدول البحث، قل الحالة المكتملة في DB1 هي 5، وهي 7 في DB2 أو Say DB2 لديه حقل مطلوب DB1 ولا يفعله يجب أن تضيف قيمة افتراضية إلى الملف إذا كان فارغا). إذا كان أحد أو سيء التشغيل الآخر أسفل المهمة قيد التشغيل ستفشل حزمة SSIS ولا يتأثر أي نظام، فهذا يبقي Datbases decoupled كما يستخدم المشغلات أو النسخ المتماثل.