بياناتنا كانت تتلف بصمت: كيف أنقذنا فهم ‘مستويات العزل’ من كابوس سباق البيانات؟

يا جماعة الخير، السلام عليكم.

اسمي أبو عمر، و”القهوة واللابتوب” هما رفيقا دربي في عالم البرمجة. اليوم بدي أحكي لكم قصة صارت معي ومع فريقي قبل كم سنة، قصة علمتنا درس قاسي لكنه ثمين، درس عن عدو خفي يعيش في قلب قواعد بياناتنا اسمه “سباق البيانات” أو الـ “Race Condition”.

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

في البداية، فكرناها أخطاء بشرية في المستودع. لكن لما تكررت المشكلة، عرفت إنه “القصة فيها إنّ”. جلسنا نحلل سجلات النظام (logs) لساعات طويلة، وإحنا مش فاهمين شو اللي بصير. الأرقام كانت تتغير بشكل غريب. فجأة، صرخ واحد من الشباب بالفريق: “يا أبو عمر، شوف هدول العمليتين! صاروا بنفس الثانية بالضبط!”.

وهنا كانت لحظة التجلي. عمليتان (Two transactions) حاولتا شراء آخر قطعة من منتج في نفس اللحظة تماماً. كل عملية قرأت إنه في “قطعة واحدة” متوفرة، وكل عملية خصمت “واحد” من المخزون، والنتيجة؟ أصبح رصيد المخزون سالب واحد (-1) في قاعدة البيانات، وتم تأكيد طلبين لمنتج واحد غير متوفر. كنا في قلب كابوس حقيقي، بياناتنا كانت تتلف وتتضارب بصمت، وثقة العميل في مهب الريح. यहीं से हमारी رحلة مع ما يسمى بـ “مستويات العزل” (Isolation Levels) قد بدأت.

ما هي “المعاملة” (Transaction) أصلًا؟

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

فكر فيها زي عملية تحويل بنكي: بدك تحوّل 100 دينار من حسابك لحساب صديقك. العملية هاي بتتكون من خطوتين:

1. خصم 100 دينار من حسابك.
2. إضافة 100 دينار لحساب صديقك.

لو صارت الخطوة الأولى وانقطع الكهرباء قبل الخطوة الثانية، شو بصير؟ كارثة! الـ 100 دينار بتختفي. هنا يأتي دور الـ Transaction ليضمن أن هاتين الخطوتين إما أن تتما معًا بنجاح (Commit) أو يتم التراجع عنهما معًا وكأن شيئًا لم يكن (Rollback). هذا المبدأ جزء من مفهوم أوسع اسمه ACID (Atomicity, Consistency, Isolation, Durability) وهو العمود الفقري لسلامة البيانات.

كابوس التزامن (Concurrency): المشاكل الخفية

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

1. القراءة القذرة (Dirty Read)

تخيل المعاملة (أ) بدأت تحديث سجل معين (مثلاً، غيرت سعر منتج من 10 إلى 15)، لكنها لم تنتهِ بعد (لم تعمل Commit). في هذه الأثناء، تأتي المعاملة (ب) وتقرأ هذا السجل، فترى السعر الجديد (15). بناءً على هذا السعر، تقوم بعملية أخرى. فجأة، المعاملة (أ) تفشل ويتم التراجع عنها (Rollback). السعر يرجع إلى 10. لكن المعاملة (ب) اتخذت قرارها بناءً على معلومة “قذرة” لم تكن نهائية. هذه هي القراءة القذرة.

2. القراءة غير المتكررة (Non-Repeatable Read)

تخيل المعاملة (أ) تقرأ سجلًا معينًا (مثلاً، رصيد منتج = 5). ثم، تأتي المعاملة (ب) وتحدّث نفس هذا السجل وتنهي عملها (مثلاً، تبيع قطعتين، فيصبح الرصيد = 3 وتعمل Commit). الآن، إذا عادت المعاملة (أ) وقرأت نفس السجل مرة أخرى ضمن نفس المعاملة، ستجد أن الرصيد أصبح 3. نفس القراءة أعطت نتيجتين مختلفتين داخل نفس المعاملة! هذا يكسر منطق العملية وقد يؤدي لنتائج كارثية.

3. قراءة الأشباح (Phantom Read)

هذه تشبه السابقة لكنها أكثر خبثًا. المعاملة (أ) تنفذ استعلامًا يقرأ مجموعة من السجلات (مثلاً، `SELECT COUNT(*) FROM products WHERE category = ‘electronics’`). النتيجة كانت 50 منتجًا. في هذه الأثناء، تأتي المعاملة (ب) وتضيف منتجًا جديدًا بنفس التصنيف (`electronics`) وتنهي عملها (Commit). الآن، إذا أعادت المعاملة (أ) تنفيذ نفس الاستعلام `COUNT(*)`، ستجد النتيجة 51! ظهر “شبح” جديد في مجموعة البيانات التي كانت تعمل عليها.

المنقذ: فهم مستويات العزل (Isolation Levels)

هنا يأتي دور بطل قصتنا. مستويات العزل هي ببساطة “قواعد” تضعها قاعدة البيانات لتحدد كيف يجب أن تتصرف المعاملات المتزامنة مع بعضها البعض، ومدى “عزل” كل معاملة عن التغييرات التي تحدثها المعاملات الأخرى.

الفكرة هي الموازنة بين أمرين: سلامة البيانات (Consistency) والأداء (Performance). كلما زاد مستوى العزل، زادت سلامة البيانات ولكن قل الأداء (لأن قاعدة البيانات تحتاج لعمل إضافي مثل حجز السجلات أو “Locking”).

دعونا نستعرض المستويات الأربعة القياسية من الأقل للأعلى عزلًا.

المستوى الأول: Read Uncommitted

هذا هو “الغرب المتوحش” في عالم قواعد البيانات. يسمح بجميع المشاكل التي ذكرناها: Dirty Reads, Non-Repeatable Reads, Phantom Reads.

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

-- ضبط مستوى العزل (مثال في SQL Server)
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

BEGIN TRANSACTION;
-- في هذه المعاملة، أي SELECT ستقرأ بيانات غير نهائية من معاملات أخرى.
SELECT * FROM Inventory WHERE ProductID = 123;
COMMIT;

المستوى الثاني: Read Committed

هذا هو المستوى الافتراضي في معظم قواعد البيانات الشهيرة (مثل PostgreSQL و SQL Server). إنه حل وسط جيد.

• ماذا يحل: يحل مشكلة القراءة القذرة (Dirty Read).
• كيف يعمل: المعاملة لا تستطيع قراءة أي تغييرات إلا بعد أن يتم عمل Commit لها. أي أنها تقرأ آخر نسخة “نظيفة” من البيانات.
• ماذا لا يحل: لا يزال يسمح بـ Non-Repeatable Reads و Phantom Reads.
• نصيحة أبو عمر: هذه هي نقطة البداية الجيدة لمعظم التطبيقات. إذا لم تكن متأكدًا، ابدأ من هنا وراقب أداء وسلوك نظامك.

-- هذا هو السلوك الافتراضي غالبًا
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- المعاملة (أ)
BEGIN TRAN;
SELECT Stock FROM Inventory WHERE ProductID = 123; -- النتيجة: 10
-- الآن، المعاملة (ب) تبيع قطعة وتعمل Commit
-- إذا أعادت المعاملة (أ) القراءة
SELECT Stock FROM Inventory WHERE ProductID = 123; -- النتيجة ستكون: 9 (Non-Repeatable Read)
COMMIT;

المستوى الثالث: Repeatable Read

هنا نبدأ بالتشدد أكثر لضمان سلامة البيانات.

• ماذا يحل: يحل مشكلة Dirty Read و Non-Repeatable Read.
• كيف يعمل: عندما تقرأ معاملة سجلًا ما، تضع عليه “قفل قراءة” (Read Lock) يمنع أي معاملة أخرى من تعديل هذا السجل حتى تنتهي المعاملة الأولى. هذا يضمن أنك لو قرأت نفس السجل 10 مرات داخل نفس المعاملة، ستحصل على نفس النتيجة دائمًا.
• ماذا لا يحل: لا يزال يسمح بـ Phantom Reads. لماذا؟ لأنه يقفل السجلات التي قرأها فقط، وليس “الفجوات” بين السجلات. فلو أضافت معاملة أخرى سجلًا جديدًا يطابق شرط البحث، سيظهر هذا “الشبح”.
• نصيحة أبو عمر: استخدم هذا المستوى عندما تكون معاملتك تتخذ قرارات بناءً على بيانات تقرأها في بدايتها، ولا تريد لهذه البيانات أن تتغير أثناء عمل المعاملة. مثال: نظام تقارير يحسب مجاميع معينة.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRAN;
SELECT Stock FROM Inventory WHERE ProductID = 123; -- النتيجة: 10
-- أي محاولة من معاملة أخرى لتحديث هذا السجل ستنتظر حتى تنتهي هذه المعاملة
-- لكن معاملة أخرى يمكنها إضافة منتج جديد
INSERT INTO Inventory (ProductID, Stock) VALUES (456, 20);
-- لو قرأت المعاملة (أ) مجموعة من السجلات، قد ترى هذا الشبح الجديد
SELECT COUNT(*) FROM Inventory; -- قد تتغير النتيجة (Phantom Read)
COMMIT;

المستوى الرابع: Serializable

هذا هو “الحصن المنيع”. أعلى مستوى من العزل، يضمن سلامة بيانات مطلقة.

• ماذا يحل: يحل جميع المشاكل: Dirty Read, Non-Repeatable Read, و Phantom Read.
• كيف يعمل: يتصرف وكأن المعاملات تنفذ واحدة تلو الأخرى بشكل متسلسل، على الرغم من أنها تعمل بالتزامن. يقوم بذلك عن طريق استخدام أقفال صارمة جدًا، ليس فقط على السجلات المقروءة، بل على نطاقات كاملة من البيانات لمنع ظهور “الأشباح”.
• الثمن: الأداء. هذا المستوى هو الأبطأ لأنه يقلل من درجة التزامن بشكل كبير وقد يؤدي إلى مشاكل أخرى مثل “الجمود” (Deadlocks) إذا لم تتم إدارته بحكمة.
• نصيحة أبو عمر: لا تلجأ إليه إلا للضرورة القصوى! استخدمه في العمليات الحساسة جدًا التي لا تحتمل أي خطأ، مثل قصتنا الأصلية (تحديث المخزون عند بيع آخر قطعة)، أو في العمليات المالية المعقدة، أو أنظمة الحجوزات.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

BEGIN TRAN;
-- القصة التي بدأت بها المقالة، هكذا كان يجب أن تكون
-- 1. اقرأ المخزون
SELECT Stock FROM Inventory WHERE ProductID = 123; -- النتيجة: 1
-- قاعدة البيانات الآن تقفل هذا السجل أو النطاق
-- لو حاولت معاملة أخرى قراءة أو تحديث نفس السجل، ستنتظر

-- 2. تأكد أن المخزون كافٍ
IF (Stock > 0) THEN
    -- 3. حدث المخزون
    UPDATE Inventory SET Stock = Stock - 1 WHERE ProductID = 123;
END IF;

COMMIT;
-- الآن، لو حاولت معاملتان شراء آخر قطعة في نفس الوقت، واحدة فقط ستنجح
-- والثانية إما ستنتظر وتجد أن المخزون أصبح 0، أو ستفشل مباشرة (حسب تطبيق قاعدة البيانات).

“طب يا أبو عمر، شو أختار؟”

هذا هو سؤال المليون دولار. الجواب، كما هي العادة في البرمجة: “يعتمد”.

قاعدة أبو عمر الذهبية: ابدأ دائمًا بالمستوى الافتراضي لقاعدة بياناتك (غالبًا `Read Committed`). لا ترفع مستوى العزل إلا عندما تواجه مشكلة حقيقية وتثبت أن سببها هو أحد مشاكل التزامن التي لا يحلها المستوى الحالي.

اسأل نفسك هذه الأسئلة:

• ما مدى حساسية هذه العملية؟ هل هي تحديث رصيد بنكي أم إضافة تعليق على مدونة؟
• هل المعاملة تقرأ بيانات ثم تتخذ قرارًا بناءً عليها؟ إذا كان الأمر كذلك، قد تحتاج على الأقل إلى `Repeatable Read`.
• هل المعاملة تعمل على نطاق من البيانات وتخشى من ظهور عناصر جديدة؟ إذا كان الأمر كذلك، فقد تحتاج إلى `Serializable`.
• ما هو تأثير الأداء؟ هل يمكنك تحمل تباطؤ هذه العملية مقابل سلامة البيانات؟

في قصتنا، حللنا المشكلة باستخدام مستوى `Serializable` لعملية تحديث المخزون فقط، بينما بقيت باقي عمليات النظام على `Read Committed` للحفاظ على الأداء العام. لم نطبق الحل على كل شيء كالمجانين!

خلاصة الحكاية ونصيحة من القلب 💡

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

لا تتعامل مع قاعدة البيانات كصندوق أسود. افهم كيف تعمل “تحت الغطاء”. فهم مستويات العزل ليس مجرد معلومة نظرية، بل هو سلاح فعال في ترسانتك كمطور محترف. هو ما يميز المبرمج الذي يبني بيوتًا من ورق عن الذي يبني قلاعًا صلبة.

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

الله يعطيكم العافية ويوفقكم في مشاريعكم. 🙏