خصائص ACID في قواعد البيانات
الـ ٤ ضمانات اللي بتخلي قواعد البيانات تستحمل crashes, races, و failures من غير ما البيانات تتلخبط.
يعني إيه ACID أصلاً؟
من فين جت الكلمة دي
الفكرة الكبيرة
إيه اللي بيحصل لما transaction تتنفذ بشكل صح؟
كلمة ACID دي اختصار لـ ٤ خصائص لازم أي قاعدة بيانات جادة تضمنهم: Atomicity, Consistency, Isolation, Durability.
المصطلح ده طلع في سنة 1983 من باحثين في IBM (Theo Härder و Andreas Reuter)، عشان يلخص الضمانات اللي كانوا الـ databases بتقدمها. من ساعتها بقى المعيار اللي بنحكم بيه على أي DB جدية.
- transaction: مجموعة عمليات DB بنعتبرها وحدة واحدة (مثلاً: تحويل فلوس = خصم + إضافة)
- commit: تأكيد إن الـ transaction خلصت بنجاح وتطبق نهائياً
- rollback: إلغاء الـ transaction ورجوع البيانات لحالتها قبل البداية
- crash: انهيار مفاجئ (كهربا قطعت، السيرفر بفلش، الـ DB process مات)
تخيل بنك بدون ACID. عميل بيحوّل 1000 جنيه. الـ DB خصمت من حسابه، وقبل ما تضيف لحساب الطرف التاني، السيرفر قطع. الـ 1000 جنيه راحوا فين؟ اختفوا. ده النوع من المشاكل اللي ACID بتمنعه.
- ← البيانات تفضل صحيحة مع أي failure
- ← مفيش لقطة "نص شغالة" أبداً
- ← العمليات المتوازية ما بتفسدش بعض
- ← لما تقول "committed" يعني committed
- ← فلوس بتختفي من الـ balances
- ← orders بدون items، items بدون orders
- ← user اشترى آخر قطعتين سوا
- ← الـ DB بتقول "tmam" والبيانات اتمسحت
ACID ضمانات داخل الـ DB الواحدة. لما تبقى عندك عدة databases أو microservices، ACID بتبقى محدودة، ومحتاج تستخدم patterns تانية زي Saga أو 2PC (هنشوفهم بعدين).