تعال نتخيل مع بعض السيناريو التالي عندك Transaction A تقوم بحساب إجمالي الأرصدة لجميع الحسابات، وفي نفس اللحظة Transaction B تقوم بعملية تحويل أموال بين حسابين.
طيب لو Transaction A بدأت قراءة البيانات بينما Transaction B لسا ما خلصت تعديل الأرصدة.
النتيجة اللي تحصل عليها ممكن تكون غير دقيقة أو غير متسقة inconsistent data. المشكلة ذي تُعرف باسم Read Skew.
سبب المشكلة هو طبيعية قواعد البيانات اللي بتتعامل بشكل Concurrency.
Transaction A ممكن تشوف بيانات تم تعديلها جزئيًا أو تغييرات مش مكتملة من Transaction B. الشيء يظهر بشكل واضح مع مستويات عزل منخفضة زي Read Committed أو Read Uncommitted، لأن قاعدة البيانات في هذه المستويات تسمح للـ Transactions بمشاركة بيانات غير مستقرة أو بيانات لم يتم اعتمادها بالكامل.
عشان نمنع حدوث هذه المشكلة بنحتاج إلى مستويات عزل أعلى. في Repeatable Read، قاعدة البيانات تضمن أن البيانات اللي تقرأها Transaction A تظل ثابتة حتى لو Transaction B أجرت تغييرات أثناء التنفيذ. لكن هذا ما يمنع المشاكل اللي تتعلق بالعمليات اللي فيها aggregation زي SUM أو AVG. في Serializable، كل Transaction يتم تنفيذها وكأنها الوحيدة اللي تعمل، مما يمنع Read Skew تمامًا، لكنه يستهلك أداء أكبر بسبب القيود اللي يفرضها على التوازي.
حل عملي اخر هو استخدام Snapshot Isolation. هنا كل Transaction تعمل على نسخة مستقرة من البيانات عند نقطة زمنية محددة، مما يعني أن أي تغييرات تجريها Transaction B ما تأثر على البيانات اللي تقرأها Transaction A. بهذه الطريقة، نحصل على اتساق أعلى بدون التضحيات الكبيرة بالأداء.
Read Skew مش خطأ بحد ذاته، لكنه نتيجة طبيعية للتعامل مع Concurrency في قواعد البيانات. إذا كنت تعمل على نظام يتطلب Consistency عالي زي الأنظمة المالية، مستويات عزل زي Serializable أو تقنيات مثل Snapshot Isolation ضرورية. أما لو كنت تركز أكثر على الأداء وتستطيع تحمل بعض التناقضات المؤقتة، مستويات عزل أقل قد تكون خيار مناسب. المهم هو فهم طبيعة مشروعك واختيار الحل الأمثل لتحقيق التوازن بين ال performance و consistency.
مصدر المنشور
هذا المحتوى نُشر أصلًا كمنشور على LinkedIn. يمكنك فتحه في تبويب جديد.