اختبار المعاملات وترحيلات قواعد البيانات

المعاملات وخصائص ACID من منظور المختبِر

تجمع المعاملة عدة عبارات بحيث تسري كلها معاً أو لا يسري منها شيء. تبدأ بـ BEGIN (وSTART TRANSACTION في MySQL مكافئة لها)، وتنتهي بـ COMMIT لتثبيت التغييرات أو ROLLBACK لإلغائها، ولا تظهر تغييراتها للجلسات الأخرى قبل التثبيت. تصف خصائص ACID الأربع ما تعد به قاعدة البيانات:

• الذرّية (Atomicity) — كل العبارات أو لا شيء: الطلب وأصنافه وحجز المخزون وسجل الدفع تُكتب معاً، أو لا يُكتب شيء.
• الاتساق (Consistency) — كل معاملة مثبّتة تنقل القاعدة من حالة صالحة إلى أخرى: القيود صامدة والإجماليات ما زالت متطابقة.
• العزل (Isolation) — المعاملات المتزامنة لا يرى بعضها عمل بعض غير المكتمل، بالقدر الذي يعد به مستوى العزل المختار.
• الديمومة (Durability) — ما إن يعود COMMIT حتى يصمد التغيير أمام الانهيار أو إعادة التشغيل.

اختبار الذرّية: التثبيت والتراجع وحقن الأعطال

لا تحتاج إلى إعادة اختبار ضمانات محرك قاعدة البيانات. ما تختبره هو هل يستخدم التطبيق المعاملات بشكل صحيح: هل العبارات المتلازمة مجمّعة في معاملة واحدة، وهل يطلق كل مسار خطأ تراجعاً، وهل يُرسَل شيء خارج المعاملة — بريد، أو رسالة لخدمة أخرى، أو ملف — قبل أن تُثبَّت البيانات فعلاً.

المنهج هو حقن الأعطال (Failure injection): اجعل خطوة تفشل بعد تنفيذ خطوات سابقة، ثم ابحث عن البقايا. وتختلف المحركات هنا اختلافاً مهماً. في PostgreSQL يُجهض الخطأ داخل المعاملة المعاملةَ كلها، وتفشل كل عبارة لاحقة حتى ROLLBACK. أما في MySQL InnoDB فمعظم الأخطاء تتراجع عن العبارة الفاشلة وحدها وتبقى المعاملة مفتوحة — فشيفرة التطبيق التي تلتقط الخطأ ثم تثبّت تُبقي الصفوف المكتوبة قبله. اختبر مسارات الخطأ على المحرك الذي تشحن عليه.

وتنتهي المعاملة كذلك عند حدود قاعدة البيانات. حين تثبّت خدمة الطلبات ثم تستدعي خدمة دفع تفشل، لا يستطيع أي تراجع في القاعدة إلغاء الطلب المثبَّت؛ يحتاج التصميم إلى إجراء تعويضي (مثل Saga تلغي الطلب) أو صندوق صادر (Outbox) لا ينشر الأحداث إلا بعد التثبيت. اختبر هذا التعويض كميزة قائمة بذاتها.

• بيانات غير صالحة في آخر صنف من عدة أصناف — يجب ألا يبقى الطلب ولا الأصناف السابقة.
• انتهاء مهلة مزوّد الدفع بعد كتابة الطلب — ينتهي الطلب في حالة محددة (معلّق أو ملغى)، ولا يكون «مدفوعاً» دون دفعة أبداً.
• إنهاء عملية التطبيق بين خطوتين (في بيئة اختبار) — عند إعادة التشغيل لا يوجد شيء مكتوب نصفه، ولا تُكرّر إعادة المحاولة شيئاً.
• انتهاك مفتاح فريد في منتصف المعاملة — يرى المستخدم خطأً واضحاً ولا تبقى صفوف جزئية.

-- PostgreSQL test database: the order must not survive a failed item
BEGIN;

INSERT INTO orders (order_id, customer_id, status, total_amount, created_at)
VALUES (9001, 317, 'PENDING', 150.00, '2026-09-28 10:00:00');

INSERT INTO order_items (order_item_id, order_id, product_sku, quantity, unit_price)
VALUES (90011, 9001, 'SKU-100', 0, 150.00);  -- violates CHECK (quantity > 0)

ROLLBACK;

SELECT COUNT(*) AS leftover FROM orders WHERE order_id = 9001;  -- expect 0

ظواهر التزامن التي يمكنك اختبارها

العزل موازنة بين الصحة والإنتاجية، لذا تسمح قواعد البيانات للمعاملات برؤية بعض آثار غيرها. يسمّي معيار SQL ثلاث ظواهر؛ وتضيف وثائق PostgreSQL شذوذ التسلسل؛ أما الظاهرة التي يلتقيها المختبِرون عملياً أكثر من غيرها فليست في قائمة المعيار أصلاً، وهي التحديث المفقود.

• القراءة القذرة (Dirty read) — تقرأ معاملة بيانات كتبتها معاملة أخرى لم تُثبَّت بعد (وقد تتراجع).
• القراءة غير القابلة للتكرار (Non-repeatable read) — تقرأ معاملة الصف نفسه مرتين فتحصل على قيمتين مختلفتين، لأن معاملة أخرى ثبّتت تغييراً بينهما.
• القراءة الشبحية (Phantom read) — تنفّذ معاملة الاستعلام نفسه مرتين فتحصل على مجموعة صفوف مختلفة، لأن معاملة أخرى أدرجت صفوفاً مطابقة أو حذفتها وثبّتت.
• شذوذ التسلسل (Serialization anomaly) — نتيجة معاملات متزامنة مثبّتة لا تطابق أي ترتيب لتشغيلها واحدة تلو الأخرى (المثال الكلاسيكي Write skew: طبيبان يخرج كل منهما من المناوبة لأنه رأى الآخر ما زال مناوباً).
• التحديث المفقود (Lost update) — تقرأ معاملتان القيمة نفسها، وتحسب كل منهما قيمة جديدة منها، فتطمس الكتابة الثانية الأولى بصمت. يعيد السكربت أدناه إنتاجها بجلستي SQL.

-- Setup on a test database: one unit left
CREATE TABLE inventory (
  sku   VARCHAR(40) NOT NULL PRIMARY KEY,
  stock INTEGER     NOT NULL CHECK (stock >= 0)
);
INSERT INTO inventory (sku, stock) VALUES ('SKU-100', 1);

-- Step 1, session A
BEGIN;
SELECT stock FROM inventory WHERE sku = 'SKU-100';   -- reads 1

-- Step 2, session B
BEGIN;
SELECT stock FROM inventory WHERE sku = 'SKU-100';   -- reads 1
UPDATE inventory SET stock = 0 WHERE sku = 'SKU-100'; -- app computed 1 - 1
COMMIT;

-- Step 3, session A
UPDATE inventory SET stock = 0 WHERE sku = 'SKU-100'; -- app computed 1 - 1
COMMIT;

-- Two sales, one unit: B's update is lost.
-- PostgreSQL READ COMMITTED and MySQL InnoDB REPEATABLE READ: both commits succeed.
-- PostgreSQL REPEATABLE READ: step 3 fails with a serialization error; the app must retry.

مستويات العزل: ما يمنعه كل منها وكيف تختلف المحركات

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

يعتمد PostgreSQL افتراضياً READ COMMITTED ولا يسمح بالقراءة القذرة أبداً — فمستوى READ UNCOMMITTED فيه يتصرف مثل READ COMMITTED. ويمنح REPEATABLE READ فيه كل معاملة لقطة (Snapshot) تؤخذ عند بدء أول عبارة فيها غير عبارات التحكم في المعاملة مثل BEGIN، ولا يسمح بالقراءة الشبحية أيضاً، وهذا أشد مما يطلبه المعيار؛ وإن حاولت معاملة كهذه تحديث صف غيّرته معاملة أخرى وثبّتته بعد لقطتها، فإنها تفشل بخطأ تسلسل يجب على التطبيق التقاطه وإعادة المحاولة. أما SERIALIZABLE فيكشف فوق ذلك شذوذ التسلسل ويُجهض إحدى المعاملات المعنية.

يعتمد محرك InnoDB في MySQL افتراضياً REPEATABLE READ. عبارات SELECT العادية في المعاملة تقرأ لقطة متسقة تُنشأ عند أول قراءة؛ أما القراءات المُقفِلة (Locking reads) (SELECT … FOR UPDATE أو FOR SHARE) وUPDATE وDELETE فتعمل على أحدث الصفوف المثبّتة وتأخذ أقفالاً، منها أقفال Next-key (الفجوات) التي تمنع الإدراج في النطاق الممسوح. وعلى خلاف PostgreSQL، لا يفشل تحديث صف غيّرته معاملة أخرى مثبّتة — بل يُطبَّق على أحدث نسخة — فقد يفقد نمط «اقرأ ثم اكتب» في شيفرة التطبيق تحديثاً ما لم يستخدم قراءة مُقفِلة أو عبارة ذرّية. أما SQLite فيطبّق العزل بطريقته الخاصة، فراجع وثائقه بدلاً من افتراض سلوك PostgreSQL أو MySQL.

• READ UNCOMMITTED — يسمح المعيار عنده بالظواهر الثلاث: القراءة القذرة، والقراءة غير القابلة للتكرار (Non-repeatable read)، والقراءة الشبحية (Phantom read).
• READ COMMITTED — يمنع القراءة القذرة (Dirty read)، وتبقى القراءة غير القابلة للتكرار والقراءة الشبحية ممكنتين.
• REPEATABLE READ — يمنع القراءة القذرة والقراءة غير القابلة للتكرار، ويسمح المعيار عنده بالقراءة الشبحية.
• SERIALIZABLE — يمنع الظواهر الثلاث كلها.
• هذه الضمانات الدنيا في معيار SQL، وقد تمنع المحركات أكثر: لا يسمح PostgreSQL بالقراءة القذرة أبداً، ويمنع REPEATABLE READ فيه القراءة الشبحية أيضاً. والتحديث المفقود ليس في جدول المعيار؛ انظر ملاحظات المحركات أعلاه. ويلخّص الجدول أدناه المستويات الأربعة بمصطلحاتها الإنجليزية (possible = ممكنة، prevented = ممنوعة).

Isolation level    Dirty read   Non-repeatable read   Phantom read
READ UNCOMMITTED   possible     possible              possible
READ COMMITTED     prevented    possible              possible
REPEATABLE READ    prevented    prevented             possible
SERIALIZABLE       prevented    prevented             prevented

اختبارات تزامن تشغّلها يدوياً وتؤتمتها

أبسط اختبار تزامن يحتاج إلى جلستي SQL وجدول خطوات مكتوب، كما في السكربت أعلاه. فهو يعيد إنتاج السباق (Race condition) بشكل حتمي، مما يجعله مثالياً لتقرير الخطأ. ثم اختبر التطبيق الحقيقي: أرسل الطلبات المتنافسة بالتوازي عبر API، بسكربت صغير أو أداة حمل مثل k6 أو JMeter بعدد قليل من المستخدمين الافتراضيين، وكرر التشغيل مرات كافية لإصابة النافذة الزمنية.

النتيجة المتوقعة لاختبار التزامن ليست أبداً «ينجح الاثنان» حين لا يجوز إلا لواحد. ينجح طلب واحد بالضبط؛ ويتلقى الآخر استجابة محددة (تعارض، أو رسالة نفاد مخزون، أو إعادة محاولة شفافة)؛ وبعدها تتطابق البيانات — لا يصبح المخزون سالباً، ولا تُستخدم القسيمة فوق حدها، ويبقى مجموع الأرصدة في التحويل دون تغيير. تكتشف المحركات الجمود (Deadlock) وتُجهض إحدى المعاملات؛ وينبغي أن يعيد التطبيق محاولتها، وألا يرى المستخدم 500 أبداً.

• آخر قطعة في المخزون يشتريها عميلان في اللحظة نفسها.
• نقر مزدوج على زر الإرسال، أو إعادة محاولة من العميل بعد انتهاء مهلة — مع مفتاح عدم تكرار الأثر (Idempotency key) يعيد الطلب الثاني نتيجة الأول بدل إنشاء طلب ثانٍ.
• مسؤولان يحرران السجل نفسه — مع القفل التفاؤلي (Optimistic locking) يُرفض الحفظ الثاني بتعارض بدل أن يطمس الأول بصمت.
• قسيمة محدودة يستخدمها مستخدمون كثيرون في آن واحد.
• تحويلات في اتجاهين متعاكسين بين الحسابين نفسيهما — نمط جمود كلاسيكي.

-- Option 1: lock the row while deciding (PostgreSQL, MySQL; not SQLite)
BEGIN;
SELECT stock FROM inventory WHERE sku = 'SKU-100' FOR UPDATE;
UPDATE inventory SET stock = stock - 1 WHERE sku = 'SKU-100';
COMMIT;

-- Option 2: one conditional, atomic statement; the app checks rows affected = 1
UPDATE inventory
SET stock = stock - 1
WHERE sku = 'SKU-100' AND stock >= 1;

-- Option 3: optimistic locking with a version column; 0 rows affected = conflict
UPDATE orders
SET status = 'SHIPPED', version = version + 1
WHERE order_id = 1042 AND version = 7;

ترحيل المخطط والبيانات: ما الذي يسوء

ترحيل المخطط (Schema migration) يغيّر البنية — يضيف جدولاً أو عموداً أو فهرساً أو قيداً، أو يعيد تسمية شيء أو يحذفه. وترحيل البيانات (Data migration) يغيّر المحتوى — يملأ عموداً جديداً، أو يقسم حقل اسم، أو يحوّل عملات. أدوات الترحيل مثل Flyway وLiquibase أو ترحيلات إطار العمل نفسه تطبّق سكربتات مرقّمة بالترتيب وتسجّل ما نُفّذ. والمخاطر واحدة أياً كانت الأداة:

• الأقفال وإعادة كتابة الجداول — بعض العمليات، مثل تغيير نوع عمود أو بناء فهرس دون خيار المحرك المتاح أثناء التشغيل، تقفل الجدول أو تعيد كتابته. الثواني على قاعدة الاختبار قد تصبح دقائق أو ساعات بحجم الإنتاج. وسلوك كل عملية يعتمد على المحرك وإصداره.
• فقدان البيانات — حذف عمود أو تضييقه، أو تقليل عدد المنازل العشرية، أو تحويل النص إلى أرقام، أو تغيير مجموعة المحارف قد يدمّر القيم أو يفسدها دون خطأ.
• ملء ناقص — السكربت يفوّت قيم NULL أو القيم غير المعتادة أو الصفوف التي أُنشئت أثناء تشغيله.
• التوافق أثناء الطرح — في النشر المتدرّج تعمل نسختا التطبيق القديمة والجديدة على المخطط نفسه في الوقت نفسه، فإعادة تسمية عمود تكسر النسخة القديمة فوراً.
• الفشل الجزئي — يثبّت MySQL ضمنياً قبل عبارات DDL وبعدها، فالترحيل متعدد الخطوات الذي يفشل في منتصفه يترك المخطط نصف معدَّل. ويستطيع PostgreSQL تشغيل معظم DDL داخل معاملة، لكن بعض العبارات مثل CREATE INDEX CONCURRENTLY لا يمكن تشغيلها داخل كتلة معاملة.
• خطوات باتجاه واحد — سكربت التراجع يستطيع إعادة إنشاء عمود محذوف لكن لا يستطيع إعادة بياناته.

كيف تختبر الترحيل

تمرّن على كل ترحيل مهم على قاعدة بيانات بحجم الإنتاج وشكله — المحرك والإصدار نفسيهما، وأعداد صفوف متقاربة، وتوزيعات قيم متشابهة. ابنِها من بيانات اصطناعية مولّدة، أو من بيانات الإنتاج فقط عبر عملية إخفاء هوية (Anonymisation) اعتمدها مسؤول حماية البيانات؛ فنظام حماية البيانات الشخصية السعودي (PDPL) يسري على البيانات الشخصية في بيئات الاختبار أيضاً. قِس مدة الترحيل وراقب الاستعلامات المحجوبة أثناء تشغيله، ويُفضَّل أن تصل حركة اختبار إلى التطبيق في الوقت نفسه.

تحقق باستعلامات تشغّلها قبل الترحيل وبعده: أعداد الصفوف، ومجاميع أعمدة المبالغ، والتوزيعات حسب الحالة، وفحوص خاصة بالتغيير — لا NULL متبقية في عمود ممتلئ، وقيم مسموح بها فقط، وقيود صالحة. احفظ نتائج «قبل» لتكون المقارنة دقيقة.

خطط للتوافق بنمط التوسيع ثم التقليص (Expand and contract، ويسمى أيضاً Parallel change): أضف البنية الجديدة أولاً مع إبقاء القديمة، واكتب في الاثنتين، واملأ البيانات، وحوّل القراءة إلى البنية الجديدة، ولا تحذف القديمة إلا في إصدار لاحق. تصبح كل خطوة متوافقة مع السابق، ويمكنك اختبار النسخة القديمة من التطبيق على المخطط الجديد. وأخيراً اختبر طريق العودة: شغّل ترحيل التراجع أو إجراء الاستعادة على قاعدة التمرين، وقِس مدته، ودوّن الخطوات ذات الاتجاه الواحد.

-- Fingerprint: run before and after the migration and compare the results
SELECT 'orders' AS table_name, COUNT(*) AS row_count, SUM(total_amount) AS amount_sum FROM orders
UNION ALL
SELECT 'order_items', COUNT(*), SUM(quantity * unit_price) FROM order_items
UNION ALL
SELECT 'payments', COUNT(*), SUM(amount) FROM payments;

-- A distribution that must not change
SELECT status, COUNT(*) AS order_count
FROM orders
GROUP BY status
ORDER BY status;

-- Example: after adding orders.currency with a backfill to 'SAR'
SELECT COUNT(*) AS missing_currency FROM orders WHERE currency IS NULL;

SELECT currency, COUNT(*) AS order_count
FROM orders
GROUP BY currency
ORDER BY currency;

جرّبها: مولّد مجموعات بيانات SQL جرّبها: مدقّق استعلامات SQL

قائمة التحقق لاختبار الترحيل

انسخ هذه القائمة إلى تذكرة كل ترحيل يغيّر البيانات أو يمس جدولاً كبيراً. هي قصيرة عمداً؛ وكل سطر فيها سؤال يجب أن يستطيع أحدهم الإجابة عنه بنعم قبل الإصدار.

قائمة التحقق لاختبار الترحيل: <معرّف الترحيل>

قبل
[ ] تصنيف التغيير: مخطط أو بيانات أو كلاهما
[ ] تحديد الخطوات المدمّرة (DROP، تضييق النوع أو الطول، إعادة كتابة البيانات)
[ ] قاعدة تمرين بحجم قريب من الإنتاج (بيانات اصطناعية أو مخفاة الهوية ومعتمدة)
[ ] تشغيل استعلامات البصمة وحفظ نتائجها (الأعداد والمجاميع والتوزيعات)
[ ] التأكد من النسخة الاحتياطية أو الاستعادة لنقطة زمنية ومعرفة مدة الاستعادة

أثناء التمرين
[ ] قياس المدة ومراقبة الأقفال والاستعلامات المحجوبة
[ ] حركة التطبيق تعمل أثناء تشغيل الترحيل
[ ] محاكاة فشل في المنتصف وفهم الحالة الناتجة

بعد
[ ] استعلامات البصمة متطابقة، أو مختلفة كما هو مقصود بالضبط
[ ] الأعمدة الجديدة ممتلئة، ولا NULL غير متوقعة، والقيود صالحة
[ ] النسخة القديمة من التطبيق تعمل على المخطط الجديد
[ ] النسخة الجديدة تجتاز فحوص الدخان والسلامة
[ ] اختبار ترحيل التراجع أو الاستعادة وتوثيق الخطوات ذات الاتجاه الواحد
[ ] خطط الاستعلامات الرئيسية لم تتغير أو تحسّنت

أتمتة اختبارات المعاملات والترحيل في CI

شغّل اختبارات قاعدة البيانات على المحرك نفسه والإصدار الرئيسي نفسه المستخدمين في الإنتاج، مُشغَّلاً من جديد في خط الأنابيب — في حاوية عادةً. استبدال PostgreSQL أو MySQL بـ SQLite أو بقاعدة في الذاكرة يخفي بالضبط السلوك الذي تتناوله هذه الصفحة: العزل والأقفال وDDL داخل المعاملات وفرض القيود كلها تختلف.

ينبغي أن يطبّق خط الأنابيب كل الترحيلات على قاعدة فارغة، ويطبّق الترحيلات الجديدة على قاعدة مزروعة بالإصدار المنشور السابق، ويشغّل اختبارات التكامل بما فيها حالات التزامن، وينتهي باستعلامات السلامة للقراءة فقط. أما تمارين الأحجام الكبيرة فتستغرق وقتاً أطول وتُشغَّل عادةً على جدول زمني أو قبل الإصدار لا مع كل إيداع.

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

جرّبها: مولّد جمل SQL INSERT جرّبها: مولّد مجموعات الأرقام الحدّية

الأسئلة الشائعة

المراجع

• Transactions — PostgreSQL DocumentationPostgreSQL Global Development Groupما المعاملة: عدة خطوات تُطبَّق كلها أو لا شيء عبر BEGIN وCOMMIT وROLLBACK، ولا يراها الآخرون قبل التثبيت.
• Transaction Isolation — PostgreSQL DocumentationPostgreSQL Global Development Groupمستويات العزل في SQL والظواهر التي تسمح بها — القراءة القذرة والقراءة غير القابلة للتكرار والأشباح وشذوذ التسلسل — كما ينفّذها PostgreSQL.
• Transaction Isolation Levels — MySQL 8.4 Reference ManualOracle (MySQL)مستويات العزل الأربعة في SQL كما ينفّذها InnoDB، ومستوى REPEATABLE READ هو الافتراضي فيه.
• Transaction — SQLiteSQLiteكيف يبدأ SQLite المعاملات ويثبّتها ويتراجع عنها، بما في ذلك أنماط التأجيل والفورية والحصرية.
• Constraints — PostgreSQL DocumentationPostgreSQL Global Development Groupقيود التحقق وعدم القيمة الفارغة والتفرّد والمفتاح الأساسي والمفتاح الأجنبي والإقصاء — القواعد التي تفرضها قاعدة البيانات ويتحقق منها المختبِر.
• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023الجزء الإطاري من معيار SQL الدولي، الذي تنفّذه لهجات PostgreSQL وMySQL وSQLite وغيرها بدرجات متفاوتة.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.