انتقال للمقال
فهرس المحتويات

مبدأ الـ Durability

السلام عليكم ورحمة الله وبركاته

وقت القراءة: ≈ 5 دقائق

المقدمة

حسنًا لقد وصلنا لأخر مبدأ في الـ ACID وهو مبدأ الـ Durability
لا تقلق لن أطيل عليك سيكون خفيفًا ونظريًا مثل مبدأ الـ Consistency
لأن مبدأ الـ Durability هو مبدأ موجه للأشخاص الذين يقومون بتطوير الـ
Database Management System مثل MySQL أو PostgreSQL أو MongoDB
وكيف يحققون هذا المبدأ في قواعدهم
لكن يمكنك تحقيقه بنفسك عن طريق توفير نوع من الـ Backup لقاعدة البيانات الخاصة بك

مبدأ Durability هو آخر مبدأ من مبادئ الـ ACID، وهو يضمن أن جميع العمليات
التي تمت داخل Transaction لن تُفقد حتى في حالة حدوث عطل أو انقطاع مفاجئ في النظام

بمعنى آخر، عند تنفيذ Transaction بنجاح ووصولها إلى مرحلة COMMIT، فإن جميع
التعديلات على قاعدة البيانات يجب أن تُحفظ فعلًا في الـ Database

لأنك عندما تقول لي أنك قمت بعمل COMMIT بنجاح فهذا يعني أنك فعلًا قمت بتنفيذ الـ
Transaction بنجاح وقمت بحفظ البيانات في الـ Database
لا تقول لي لقد تم العملية بنجاح وبعد لحظات يحدث انقطاع في الكهرباء أو أن الـ
Server تعطل
ثم نفاجيء بأن البيانات لم يتم حفظها فعليًا برغم من أنك قمت بعمل COMMIT وجاءتك
رسالة أن العملية تمت بنجاح

هذا ما يعنيه مبدأ الـ Durability أنك عندما تقول لي أنك قمت بعمل COMMIT بأنك
تضمن لي أن البيانات قد تم حفظها
ولو حدث أي كارثة فإن البيانات ستكون موجودة ولن تفقد

لمن يهم هذا المبدأ ؟

كما قلنا في المقدمة أن هذا المبدأ موجه بشكل أكبر للأشخاص الذين يقومون بتطوير الـ Database Management System مثل MySQL أو PostgreSQL أو MongoDB
وكيف يحققون هذا المبدأ في قواعدهم
لكن يمكنك أنت أيضًا تحقيقه بنفسك عن طريق توفير نوع من الـ Backup لقاعدة البيانات الخاصة بك

كيف يعمل مبدأ Durability ؟

كل أنظمة قواعد البيانات سواء كانت MySQL أو PostgreSQL أو MongoDB تحاول
تحقيق مبدأ Durability بطرق مختلفة

بعض الأنظمة تخزن البيانات في الذاكرة العشوائية RAM وبعد ما تقوم بعمل
COMMIT تقوم بنقل البيانات من الـ RAM إلى الـ Database
وهذا غير مضمون للـ Durability لأن طالما أن البيانات والتعديل في الـ RAM فسوف
تفقدها في حالة حدوث أي عطل

الأسلوب الأفضل هو أن تخزنها في الـ Hard Disk مباشرة ثم بعد الـ COMMIT تقوم
بنقلها إلى الـ Database
لذا في حالة حدوث أي عطل فإن البيانات ستكون موجودة في الـ Hard Disk ويمكنك
استعادتها

تقنيات تحقيق الـ Durability

يمكننا تحقيق مبدأ الـ Durability بعدة تقنيات وأساليب، منها:

Write-Ahead Logging (WAL)

تسجل جميع العمليات في ملف Log File في الـ Hard Disk قبل تنفيذها أو نقلها إلى
الـ Database مما يتيح استعادة البيانات في حال حدوث أي خطأ

يعد الأكثر شيوعًا واستخدامًا في تحقيق مبدأ الـ Durability

وطريقة عمله ببساطة هي أنه يقوم بتسجيل جميع العمليات التي تمت داخل الـ
Transaction في ملف Log قبل تنفيذها
ثم في حالة الـ COMMIT يقوم بنقل البيانات من الـ Log إلى الـ Database
في حالة حدوث أي عطل فإنه يمكنك استعادة البيانات من الـ Log

شكل الملف يكون أشبه بملفات الـ Migration الخاصة بالـ Database التي تحدثنا
عنها في مقالة
شرح الـ Database Migration لإدارة التغييرات

[2025-02-17 10:00:00] TXN-ID: 101 | BEGIN
[2025-02-17 10:00:01] TXN-ID: 101 | UPDATE users SET balance = 500 WHERE id = 5
[2025-02-17 10:00:02] TXN-ID: 101 | COMMIT

[2025-02-17 10:05:00] TXN-ID: 102 | BEGIN
[2025-02-17 10:05:01] TXN-ID: 102 | INSERT INTO orders (product, price) VALUES ('Laptop', 1500)
[2025-02-17 10:05:02] TXN-ID: 102 | COMMIT

هذا مثال بسيط على كيفية تسجيل العمليات في ملف Log
وبالطبع هذا شكل تخيلي لأن الـ Log يحتوي على العديد من المعلومات الأخرى ويختلف
شكل الـ Log من قاعدة بيانات لأخرى

وهذه الطريقة ستجدها في كل DBMS تقريبًا:

  • ملف WAL في PostgreSQL
  • ملف Binlog في MySQL
  • ملفات idf و mdf في SQL Server

معلومة مهمة: هذه الملفات تحتفظ بكل العمليات التي تمت في الـ Database
حتى لو قمت بحذفها من الـ Database
سواء تم تنفيذها داخل Transaction أو لا، لذا أحيانًا تستطيع استعادة البيانات بعد حذفها
لكن استعادتها ستكون بشكل يدوي عن طريق قراءة هذه الملفات وتنفيذ العمليات التي تمت فيها

Asynchronous Snapshots

يقوم بعمل نسخة احتياطية من الـ Database بشكل دوري ومتكرر لضمان عدم فقدان
البيانات في حالة الأعطال
بالتالي عند حدوث أي عطل يمكنك استعادة البيانات من أحدث نسخة احتياطية والأمر يكون أشبه بالـ Backup

فلو افترضنا أن السيرفر تعطل في الساعة 03:00 وآخر نسخة احتياطية Snapshot كانت
في الساعة 02:30
فبديهيًا أنك يمكنك استعادة البيانات من هذه النسخة الاحتياطية فقط بالتالي ستفقد
البيانات التي تمت بعد الساعة 02:30

في Redis تستخدم هذه التقنية مع الـ Append Only Files لتحقيق مبدأ الـ Durability
وبالطبع قد تجمع بعض الـ Database Management System بين Write-Ahead Logging
وAsynchronous Snapshots لتحقيق الـ Durability أيضًا

Append Only Files (AOF)

مثل الـ WAL لكنه يستخدم في Redis وما يشبهها لتسجيل تسلسل العمليات التي تم
تنفيذها
في الحقيقة الـ Append Only Files تم تصميمه ليناسب Redis وشبيهاتها

أعني هنا أنظمة الـ In-Memory Database تستخدم هذه التقنية لتحقيق مبدأ الـ
Durability
عن طريق مزامنة التغيرات التي تحدث في الـ Database مع الـ Append Only Files

كيف تحقق الـ Durability بنفسك ؟

بجانب ما تقدمه قواعد البيانات من آليات داخلية، يمكنك أيضًا:

  1. إعداد نسخ احتياطية دورية لقاعدة البيانات
  2. استخدام خدمات النسخ الاحتياطي السحابية مثل AWS RDS أو Google Cloud SQL
  3. تفعيل الـ Replication لنسخ البيانات على أكثر من سيرفر
  4. استخدام أنظمة تخزين موثوقة مثل RAID للحماية من فشل الأقراص

ملخص

  • مبدأ الـ Durability يضمن أن البيانات المحفوظة لن تُفقد حتى عند حدوث أعطال
  • عندما تحصل على COMMIT ناجح، يجب أن تثق أن البيانات محفوظة فعلًا
  • التقنيات الرئيسية لتحقيقه:
    • Write-Ahead Logging (WAL)
    • Asynchronous Snapshots
    • Append Only Files (AOF)
  • يمكنك تعزيز الـ Durability عن طريق النسخ الاحتياطية والـ Replication