لف لف الكود في معاملة أمر ضروري. لكنه ليس هو نفسه جعل العملية آمنة للتوازي.
هنا تكمن أهمية مستويات العزل. فهي تحدد ما يُسمح بمعاينته من قِبل معاملة واحدة بينما تقوم معاملات أخرى بتغيير نفس البيانات.
إذا لم تفكر في ذلك أبدًا، ستصل في النهاية إلى نظام "صحيح" في الاختبارات المحلية ولكنه خاطئ بشكل دقيق تحت حركة مرور متزامنة.
لماذا الافتراضي ليس دائمًا كافيًا
افتراضي PostgreSQL هو READ COMMITTED. وهذا افتراضي جيد للعديد من الأحمال، لكنه لا يزال يسمح بأنماط قد تكون مفاجئة إذا كانت منطق تطبيقك يفترض عرضًا ثابتًا تمامًا للبيانات داخل معاملة.
السؤال الصحيح ليس:
"هل استخدمنا معاملة؟"
بل هو:
"ما هي الأنماط غير الطبيعية التي لا تزال ممكنة عند مستوى العزل هذا لهذه القاعدة التجارية؟"
مثال عملي
تخيل طلبين كليهما يحاولان حجز آخر وحدة متاحة من المخزون.
إذا قرأ التطبيق التوافر أولاً، ثم قرر ما إذا كان سيكتب لاحقًا، فإن سلوك التوازي يعتمد بشكل كبير على كيفية هيكلة المعاملة وما إذا كان يتم استخدام القفل أو العزل الأكثر صرامة.
عادة ما يبدو نمط مبسط مثل هذا:
BEGIN;
SELECT quantity
FROM inventory
WHERE sku = 'book-123';
UPDATE inventory
SET quantity = quantity - 1
WHERE sku = 'book-123';
COMMIT;
ما إذا كان ذلك آمنًا يعتمد على المنطق المحيط، الأقفال، المحاولات، ومستوى العزل. حدود المعاملة وحدها لا تجيب على السؤال.
ما يفعله المهندسون الكبار فعليًا
يختارون من بين:
- عزل افتراضي أبسط مع قفل دقيق
- منطق إعادة المحاولة لفشل التسلسل
- عزل أكثر صرامة فقط حيث تبرر القاعدة التجارية التكلفة
هذه وضعية صحية جدًا مقارنةً بـ "استخدم دائمًا القابل للتسلسل" أو "ربما يكون الافتراضي كافيًا".
المساومات
يمكن أن يعمل العزل الأكثر صرامة على تحسين ضمانات الدقة، لكنه أيضًا:
- يزيد من التنافس
- يرفع من احتمال إعادة المحاولات للمعاملات
- قد يقلل الإنتاجية تحت الحمل
لهذا السبب، يعتبر العزل مقايضة هندسية، وليس خيارًا أخلاقيًا.
قراءة إضافية