المرحلة 1: الأساس · الدرس 2 من 3 · 20 دقيقة

ACID حرف حرف

ACID أشهر 4 حروف في الداتابيز، وأكتر 4 حروف بيتفهموا غلط. الدرس ده بيقولك كل حرف بيضمن إيه بالظبط ومش بيضمن إيه، ومين في الداتابيز مسؤول عنه، وليه الـ C مسؤوليتك إنت أكتر من الداتابيز.

في الدرس ده هتتعلم

تعرّف كل حرف في ACID بدقة، وتعرف الأداة اللي بتحققه
تفهم ليه Consistency معظمها مسؤولية الأبلكيشن
تعرف ليه Isolation مستويات مش ضمان واحد
تفهم إن Durability درجات، وكل درجة ليها تمن

1. الأصل

المصطلح اتعمل سنة 1983 (Haerder و Reuter)، بناءً على شغل Jim Gray عن الترانزاكشنز في السبعينات. والهدف: تحديد إيه اللي “الترانزاكشن الموثوقة” لازم تضمنه حتى لو الأبلكيشن غلط، أو السيرفر وقع، أو ألف مستخدم شغالين مع بعض.

الحرف	بيحمي من	الأداة جوه الداتابيز
Atomicity	وقوع في النص، أو Error، أو ROLLBACK	الـ Undo Log (InnoDB)، أو تعليم الترانزاكشن Aborted (PostgreSQL)
Consistency	داتا بتكسر القواعد	الـ Constraints + الكود بتاعك
Isolation	ترانزاكشنز تانية شغالة في نفس الوقت	الـ Locks + MVCC
Durability	انقطاع الكهربا والـ Crash بعد الـ COMMIT	الـ WAL / Redo Log + الـ fsync

2. Atomicity: يا كله يا مفيش

خد بالك من كلمة “Atomic” هنا: مش معناها “بتحصل في لحظة واحدة” ولا ليها علاقة بالـ Threads. معناها مش بتتقسم لنصين. والاسم الأدق اللي بعض الكتب بتستخدمه: Abortability، يعني تقدر تلغيها بأمان في أي لحظة.

وده بيدّيك حاجة مهمة جداً كمبرمج: لو حصل Error في النص، مش محتاج تعرف أنهي جمل اتنفذت وتصلحها واحدة واحدة. اعمل ROLLBACK وابدأ من الأول. وده اللي بيخلّي الـ Retry آمن.

3. Consistency: الداتا ماشية على القواعد

النقطة اللي ناس كتير مش واخدين بالها منها: الداتابيز ماتعرفش قواعدك. لو الكود بتاعك خصم من حساب وماضافش للتاني وعمل COMMIT، الداتابيز هتثبّت ده بكل سعادة. الـ A و I و D خصائص في الداتابيز، لكن الـ C معظمها خاصية في الأبلكيشن، والداتابيز بتساعدك تطبّقها بالـ Constraints:

constraints.sql

CREATE TABLE wallets (
    id       bigint PRIMARY KEY,
    user_id  bigint NOT NULL REFERENCES users(id),        -- مفيش محفظة لمستخدم مش موجود
    balance  bigint NOT NULL CHECK (balance >= 0),         -- عمره ما يبقى سالب
    currency char(3) NOT NULL DEFAULT 'EGP',
    UNIQUE (user_id, currency)                             -- محفظة واحدة لكل عملة
);

كل قاعدة تقدر تكتبها Constraint، اكتبها. لأنها بتتطبق على كل كود بيكتب في الجدول: الأبلكيشن، والـ Jobs، والـ Scripts، واللي فاتح الداتابيز بإيده. والقواعد اللي ماينفعش تبقى Constraint (زي “مجموع الحسابات ثابت”) بيضمنها الكود، والـ A و I هما اللي بيخلّوا الكود ده يشتغل صح.

Deferred Constraints

ساعات القاعدة بتتكسر مؤقتاً جوه الترانزاكشن وبترجع سليمة في الآخر. مثلاً جدولين بيشاوروا على بعض بـ Foreign Keys، ولازم تضيف صف في كل واحد. PostgreSQL بيسمح تأجّل التحقق لحد الـ COMMIT:

ALTER TABLE employees ADD CONSTRAINT fk_manager
  FOREIGN KEY (manager_id) REFERENCES employees(id)
  DEFERRABLE INITIALLY DEFERRED;   -- بيتشيك وقت الـ COMMIT بس

MySQL مايدعمش Deferred Constraints: الـ FK بيتشيك مع كل جملة. الحل هناك بيبقى ترتيب الـ INSERTs، أو SET FOREIGN_KEY_CHECKS = 0 مؤقتاً (وده خطير لأنه مش بيرجع يتأكد من الداتا).

الداتابيز بتضمن إنها تثبّت اللي إنت قلته بالظبط. إن اللي إنت قلته صح، دي مسؤوليتك. اكتب القواعد Constraints عشان الداتابيز تمسكك لو غلطت.

4. Isolation: كأنك لوحدك

بس عملياً الـ Isolation مش ضمان واحد، دي مستويات (READ COMMITTED، REPEATABLE READ، SERIALIZABLE)، وكل مستوى بيسمح بأنواع مشاكل معينة مقابل أداء أعلى. والافتراضي في MySQL و PostgreSQL مش Serializable. يعني الـ I اللي معاك افتراضياً أضعف من اللي الكتب بتوصفه.

الموضوع ده ليه Master Topic كامل: Concurrency Control في الداتابيز. فيه كل الـ Anomalies، والـ Locks، والـ MVCC، والفرق بين المستويات في الداتابيزين.

5. Durability: الـ COMMIT مابيضيعش

وده بيتحقق بقاعدة واحدة: قبل ما ترد على الـ COMMIT، اكتب سجل في الـ Log على الديسك واعمل fsync. وتفاصيله في درس الـ Durability.

بس خد بالك من 3 حاجات:

Durability درجات: MySQL و PostgreSQL بيسمحوا تضعّفها مقابل سرعة (innodb_flush_log_at_trx_commit = 2 أو synchronous_commit = off). ساعتها ممكن تضيع آخر ثانية من الترانزاكشنز لو الجهاز وقع.
ديسك واحد مش Durable بجد: لو الديسك نفسه باظ، الـ fsync مالوش لازمة. الـ Durability الحقيقية = Replication على سيرفر تاني + Backups.
الديسك ممكن يكدب: ديسكات وكروت RAID فيها Write Cache بيرد “اتكتب” قبل ما يتكتب فعلاً. من غير بطارية (BBU) أو Power-loss protection، الـ fsync نفسه ممكن يبقى وهم.

6. الأربعة مع بعض

الحرف	سؤال تسأله لنفسك
A	لو الكود وقع في النص هنا، هيفضل فيه نص عملية متسجلة؟
C	فيه قاعدة على الداتا دي مش مكتوبة Constraint؟
I	لو مستخدمين عملوا نفس العملية في نفس اللحظة، النتيجة صح؟
D	لو الكهربا قطعت بعد الـ COMMIT، العملية دي ينفع تضيع؟

A و D شغل الداتابيز وبيشتغلوا لوحدهم. I مستويات لازم تختار منها. C مسؤوليتك، والـ Constraints أحسن صاحب ليك فيها.

7. أسئلة الإنترفيو

فكّر في إجابتك الأول، وبعدين افتح السؤال.

01اشرح ACID.

Atomicity: الترانزاكشن يا كلها يا مفيش. Consistency: بتنقل الداتا من حالة صحيحة لحالة صحيحة حسب قواعد الأبلكيشن. Isolation: الترانزاكشنز المتزامنة ماتأثرش على بعض. Durability: اللي اتعمله COMMIT مابيضيعش حتى لو حصل Crash.

02مين المسؤول عن الـ Consistency؟

معظمها الأبلكيشن، لأن الداتابيز ماتعرفش قواعد البيزنس. الداتابيز بتساعد بالـ Constraints (CHECK و FOREIGN KEY و UNIQUE و NOT NULL)، والـ Atomicity والـ Isolation بيخلّوا الكود الصح يفضل صح تحت الأعطال والضغط.

03الـ Atomicity في ACID ليها علاقة بالـ Atomic Operations بتاعة الـ Threads؟

لأ. في ACID معناها إن الترانزاكشن مش بتتقسم لنصين: لو مخلصتش كل أثرها يتشال (Abortability). أما إن الترانزاكشنز المتزامنة ماتشوفش بعض في النص فده الـ Isolation.

04الـ Durability مضمونة 100%؟

لأ. ممكن تتضعف بإعدادات زي innodb_flush_log_at_trx_commit = 2 أو synchronous_commit = off. والديسك نفسه ممكن يبوظ أو يكون فيه Write Cache بيكدب. الـ Durability الحقيقية محتاجة fsync على ديسك موثوق + Replication + Backups.

05MySQL بيدعم Deferred Constraints؟

لأ. الـ Foreign Keys في InnoDB بتتشيك مع كل جملة. PostgreSQL بيدعمها بـ DEFERRABLE INITIALLY DEFERRED، فالتحقق بيحصل وقت الـ COMMIT.

علّم عليه لما تقدر تجاوب أسئلة الإنترفيو من غير ما تبص.