عارض يشرح متى يعلق ترحيل صفحات SQLite: مشاريع تخرج قواعد البيانات

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

السؤال الذي يجب أن تجيب عنه الواجهة

لا تعرض «حجم WAL» وحده. سجّل وقت كل معاملة، لحظة بدء القراءة، عدد الكتابات، ونوع checkpoint. واجعل المشاهد يميز بين الإطارات المكتوبة إلى WAL وتلك التي نُقلت إلى ملف القاعدة. توثق صفحة PRAGMA في SQLite أن PRAGMA wal_checkpoint يعيد أعمدة تشمل حالة الانشغال وعدد صفحات السجل والصفحات التي تم ترحيلها في العملية. سمّ الأرقام كما في واجهة SQLite ولا تفسرها على أنها عدد صفوف أو بايتات.

جهز قاعدة اختبار صغيرة

أنشئ جدولاً يحوي مفتاحاً وعدداً، شغّل journal_mode=WAL على ملف مؤقت، ثم افتح اتصال قراءة يبدأ معاملة ويقرأ نسخة من الجدول. في اتصال آخر نفّذ دفعات تحديث قصيرة مع تثبيت حجم الصفحة وإصدار SQLite في سجل التجربة. لا تجعل عدد التحديثات ضخماً؛ المطلوب رؤية علاقة الحالات، لا الفوز باختبار سرعة. اجعل زر إعادة الضبط ينشئ قاعدة جديدة من seed ثابت، لأن تشغيل أكثر من حالة على الملف نفسه قد يترك إطارات أو إعدادات تؤثر في المقارنة.

سيناريو قراءة طويلة مقابل قراءة قصيرة

شغّل الحالة الأولى حيث يبدأ القارئ ثم ينهي معاملته بعد عدة كتابات. شغّل الثانية حيث يبقي القارئ المعاملة مفتوحة بينما يحاول الكاتب طلب checkpoint. سجّل نتيجة كل استدعاء للـPRAGMA ولا تفترض أن كل نوع checkpoint يتصرف بالطريقة نفسها. يمكن أن تظهر نتيجة busy أو تقدم جزئي بحسب الوضع والاتصالات. بعد إنهاء القارئ أعد الطلب وقارن عدد الإطارات التي رُحلت. هذا المثال مولد لتعليم السلوك، ولا يثبت أن التطبيق الحقيقي سيعاني من التأخير نفسه.

قارن الأنماط دون خلطها

اعرض PASSIVE وFULL وRESTART وTRUNCATE كاختيارات ذات شروط ونتائج، لا كأزرار «أفضل» و«أسوأ». تشرح مرجعية SQLite أن TRUNCATE قد يصفر ملف WAL بعد نجاح الترحيل، بينما قد ينتظر RESTART القراء كي ينتهوا، ويمكن لنتيجة checkpoint أن تكشف أن العملية لم تكملها بالكامل. نقطة checkpoint الافتراضية مرتبطة بعدد صفحات قابل للتهيئة، وتغيير الإعداد يغير التجربة. لا تضع عتبة واحدة كتوصية لكل مشروع.

اختبارات القبول والحالات التي تكسر الاستنتاج

اختبر قاعدة لا تعمل في WAL، وقارئاً ينهي معاملته، وقارئاً يحتفظ باللقطة، وcheckpoint جزئياً، وملفاً يعاد إنشاؤه من الصفر. تحقق من أن واجهة العرض لا تسمي الصفحات «مرّحلة» إلا بقدر ما أفاد به المحرك. أضف حالة انتهاء اتصال غير متوقع وحالة رفض صلاحية الكتابة، مع عرض الخطأ الحقيقي. قارن خط أساس بلا قارئ طويل بالحالة المقيدة، وكرر كل حالة دون استنتاج أن فرقاً صغيراً يمثل قاعدة عامة. استخدم توثيق WAL hook لتحديد ما يستطيع callback رصده، ولا توحِ أنه يغني عن إدارة checkpoint أو تحليل ملفات SQLite الداخلية.

حدود النسخة الجامعية

التسليم المناسب هو ملف قاعدة مؤقت، برنامج حمل صغير، اتصال قراءة قابل للتحكم، لوحة خط زمني، ونتائج بصيغة CSV مع إصدار المحرك. يعمل WAL ضمن قيود التزامن الخاصة به، ويذكر توثيق SQLite أن آلية shared memory تتطلب أن تكون العمليات المشاركة على الجهاز نفسه ولا تعمل بالطريقة ذاتها على نظام ملفات شبكي. لا تحول نتائج جهاز واحد إلى توصية تخزين إنتاجية، ولا تنسخ ملفات .db و-wal أثناء نشاطها لتدعي أنك اختبرت نسخة احتياطية. يمكن تحديد نطاق مشاريع تخرج مع المشرف، وربط الواجهة بخدمة قواعد البيانات وواجهات البرمجة. القيمة أن الطالب يتتبع قرار checkpoint من حدث إلى رقم مرجعي.

أضف وضع مقارنة يعيد تشغيل workload نفسه مع transaction قصيرة ثم طويلة، مع تسجيل زمن كل commit منفصلاً عن زمن checkpoint. إذا كان القارئ يوقف التقدم، ينبغي أن يربط العرض ذلك بعمر القراءة لا بعدد السجلات وحده. لا تعتبر WAL أصغر بالضرورة مؤشراً على أداء أفضل؛ قد يكون قد حدث checkpoint مبكر أو قد تغيرت إعدادات الصفحة. وفّر تنزيل سجل التجربة مع أسماء الأعمدة ووحداتها، وسجل أي إعداد اختلف بين التشغيلات. هذه القيود تجعل نتيجة الطالب قابلة للمراجعة وتمنع تقديم رسم جميل كأنه قياس إنتاجي.

ضع لوحة النتائج بجوار جدول الأحداث، لا في مخطط زمني منفصل يصعب ربطه بالقرار. لكل commit دوّن وقت البداية والنهاية، وحالة المعاملة، وما إذا كان التطبيق طلب checkpoint أم أن التلقائي بدأ. عند عرض متوسط التأخير أظهر الوسيط والمدى وعدد المحاولات؛ فالـcheckpoint العارض قد يجعل بعض عمليات commit أطول من غيرها. لا تحذف حالات busy من التقرير، بل احتفظ بسببها ومدة القارئ النشط. إذا انتهت التجربة قبل اكتمال النقل، اكتب ذلك صراحةً ولا تصف الملف بأنه عاد إلى حالة مدمجة.