هل هناك حاجة إلى سلوك المعاملات خارج قواعد البيانات؟

Question

لن أجرؤ على القيام بأي شيء معقد في قاعدة بيانات بدون معاملات.يوجد دائمًا أمر مدمج سهل الاستخدام.ولكن عندما تبدأ العمل مع البيانات المستمرة الأخرى، فلن تتمكن من استخدام دعم المعاملات بهذه السهولة.بعض الأمثلة هي

• أنظمة الملفات
• خدمات الويب (لم أستخدم أي شيء)

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

ما أود معرفته هو، لماذا تعتبر قواعد البيانات حالة خاصة؟

هل هناك أي روابط مفيدة لموضوع سلوك المعاملات خارج قواعد البيانات؟

Answer 1

يجب أن أختلف بكل احترام:أنظمة المعاملات ليست محركات قواعد بيانات بشكل تلقائي وحصري، بل على العكس تمامًا...

لقد قمت بتنفيذ آلية معاملة التطبيق (في .NET) والتي تختلف عن معاملة قاعدة البيانات.إنه في الواقع سهل إلى حد ما (بضع ساعات من العمل بما في ذلك مجموعة اختبار الوحدة).تمت كتابته بالكامل بلغة C# دون الاعتماد على أي وظيفة لقاعدة البيانات أو أي مكون آخر.لكن أولاً بعض السياق ...

توجد ميزة المعاملات غير المتعلقة بقاعدة البيانات في العديد من المظاهر على منصة Java، مثل EJBs وESBs وJMS وغالبًا ما تكون مقترنة بـ BPM.تستخدم بعض هذه المظاهر قاعدة بيانات أساسية، ولكن ليس دائمًا وليس بدافع الضرورة.منصات أخرى لها مظاهر مماثلة، مثل MSMQ.

لا تقوم معظم أنظمة التحكم في الإصدار القديم بتطبيق دلالات معاملات ACID.كما قال ddaa، CVS لا يفعل ذلك ولكن Subversion (خليفته) يفعل ذلك.المصدر المرئي الآمن لا.إذا قمت بالبحث عن Subversion، يمكنك العثور على مخططات مقارنة توضح ذلك.

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

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

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

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

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

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

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

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

Answer 2

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

دعم المعاملات هو الميزة التي توفرها حامض ملكيات.في مصطلحات الشخص العادي، هذا يعني أن المعاملة هي شيء يسمح بـ 1.تجميع عدد من العمليات السرية في حزمة واحدة إما أن تنجح ككل أو تفشل ككل 2.إخفاء التغييرات غير الملتزم بها للمستخدمين المتزامنين، بحيث 3.يتمتع المستخدمون المتزامنون في جميع الأوقات برؤية "متسقة" للنظام.

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

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

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

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

لذا، باستثناء Clojure، يبدو أن أي نظام يحتاج إلى معاملات إما يستخدم قاعدة بيانات أساسية، أو يحول نفسه إلى قاعدة بيانات.

Answer 3

أنظمة الملفات الحديثة لديها معاملات.إنها شفافة فقط للمستخدم النهائي.

NTFS، XFS، JFS، EXT3، وReiserFS كلها تفعل ذلك، على سبيل المثال لا الحصر.

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

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

Answer 4

كلوجر الاستخدامات ذاكرة المعاملات البرمجية, ، والذي يستخدم المعاملات لتسهيل وأمان كتابة برامج متعددة الخيوط بدون أقفال يدوية.لدى Clojure هياكل بيانات غير قابلة للتغيير مع مراجع قابلة للتغيير إليها، والمعاملات مطلوبة لتغيير المراجع.

Answer 5

تعد أنظمة المراسلة مثالاً آخر على مديري موارد المعاملات.

أي أنه يمكنك التأكد من أن مستهلك الرسالة يعالج رسالة من قائمة الانتظار بنجاح.إذا فشلت المعالجة، فسيتم ترك الرسالة في قائمة الانتظار.

بالإضافة إلى ذلك، يمكن لنظام المراسلة المشاركة في معاملة موزعة مع مدير موارد آخر.

مزيد من المعلومات في

• https://java.sun.com/j2ee/1.4/docs/tutorial/doc/JMS6.html
• http://www.odi.ch/prog/jms-tx.php

Answer 6

تعتبر عمليات التخريب معاملات:إنها ذرية حقًا، لذا فإن الالتزام المتقطع لا يترك المستودع في حالة غير متناسقة.

Answer 7

كان لدي الموقف الذي أحتاجه للتعامل مع نظام الملفات وقاعدة البيانات كوحدة معاملات واحدة.

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

http://www.databasesandlife.com/atomic-operations-over-filesystem-and-database/