متى يمكنك حذف أعمدة قاعدة البيانات القديمة بأمان؟ مرحلة الانكماش في نمط التوسع والانكماش

لقد قمت بترحيل جميع كود تطبيقك لاستخدام تنسيق العمود الجديد. تم النشر بسلاسة. لا توجد أخطاء في السجلات. فريقك مستعد لتنظيف المخطط القديم والانتقال إلى الميزة التالية.

ولكن هل يجب عليك حذف هذا العمود الآن؟

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

المرحلة الأخيرة من نمط التوسع والانكماش تسمى مرحلة الانكماش. يأتي الاسم من فكرة تقليص أو إزالة الهياكل التي لم تعد قيد الاستخدام. لكن الوصول إلى هذه المرحلة يتطلب أكثر من مجرد تأكيد أن تطبيقك الرئيسي قد تحول.

من غيرك لا يزال يلمس الهيكل القديم؟

قبل أن تحذف أي شيء، تحتاج إلى الإجابة على سؤال واحد: من غيرك لا يزال يقرأ من أو يكتب إلى المخطط القديم؟

قد يكون تطبيقك الأساسي قد انتقل. ولكن قد يكون هناك مستهلكون آخرون لم تفكر فيهم:

  • وظيفة مجدولة ليلية لا تزال تشير إلى العمود القديم
  • استعلامات يدوية يقوم بها فريق البيانات للتحليل المخصص
  • نظام تقارير يُنشئ ملفات PDF شهرية باستخدام الجدول القديم
  • أداة داخلية تم نشرها قبل ستة أشهر ولم يتم تحديثها
  • تكامل طرف ثالث يُرسل البيانات بالتنسيق القديم

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

كيفية اكتشاف التبعيات المخفية

أبسط طريقة للعثور على هذه التبعيات هي التحقق من سجلات قاعدة البيانات الخاصة بك. قواعد البيانات مثل PostgreSQL و MySQL و Oracle تسجل جميع الاستعلامات التي تعمل ضدها. يمكنك التصفية للبحث عن الاستعلامات التي تشير إلى العمود أو الجدول الذي تخطط لإزالته.

يلخص المخطط الانسيابي التالي عملية اتخاذ القرار لتحديد ما إذا كان من الآمن حذف عمود قديم:

flowchart TD A[هل تخطط لحذف عمود قديم؟] --> B{هل توجد وظيفة مجدولة؟} B -->|نعم| C[لا تحذف بعد] B -->|لا| D{هل يوجد استعلام تقرير؟} D -->|نعم| C D -->|لا| E{هل توجد أداة داخلية؟} E -->|نعم| C E -->|لا| F{هل يوجد تكامل طرف ثالث؟} F -->|نعم| C F -->|لا| G[احذف العمود]

إذا كانت قاعدة البيانات الخاصة بك لا تسجل الاستعلامات افتراضيًا، يمكنك تمكينها مؤقتًا. PostgreSQL لديه pg_stat_statements لتتبع إحصائيات الاستعلام. MySQL لديه Performance Schema. كلاهما يمكن أن يظهرا لك الاستعلامات التي لا تزال تلمس الهيكل القديم.

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

لهذا السبب فإن فترة الانتظار قبل الحذف مهمة. بعض الفرق تنتظر دورة نشر كاملة واحدة - عادةً أسبوعين بعد أن تتحول جميع التطبيقات. آخرون ينتظرون لفترة أطول، خاصة عندما تكون هناك استعلامات يدوية أو تقارير تُدار من قبل فرق غير تقنية. لا توجد قاعدة عالمية، ولكن كلما زادت التبعيات غير المسيطر عليها، كلما طالت مدة الانتظار.

الحذف الفعلي

بمجرد أن تصبح واثقًا من عدم وجود تبعيات متبقية، يمكنك المتابعة مع الحذف. أوامر SQL واضحة ومباشرة:

إليك مثال عملي على SQL الذي ستشغله، بالإضافة إلى استعلام للتحقق من عدم وجود كائنات قاعدة بيانات أخرى لا تزال تعتمد على العمود:

-- أولاً، تحقق من أي views أو functions أو triggers تشير إلى العمود
SELECT DISTINCT
    OBJECT_SCHEMA,
    OBJECT_NAME,
    OBJECT_TYPE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_DEFINITION LIKE '%old_column_name%'
UNION
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    'VIEW'
FROM INFORMATION_SCHEMA.VIEWS
WHERE VIEW_DEFINITION LIKE '%old_column_name%';

-- بمجرد التأكد من الأمان، احذف العمود
ALTER TABLE users DROP COLUMN old_legacy_status;

-- نظف أي indexes كانت موجودة فقط من أجل العمود القديم
DROP INDEX IF EXISTS idx_old_status ON users;

قم بتشغيل فحص التبعية أولاً، ثم تابع مع الحذف. إذا أعاد الفحص أي صفوف، فقد وجدت مستهلكًا مخفيًا يحتاج إلى تحديث قبل أن تتمكن من الحذف بأمان.

  • للعمود: ALTER TABLE ... DROP COLUMN
  • للجدول: DROP TABLE
  • للقيد: ALTER TABLE ... DROP CONSTRAINT

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

لا تنسَ الفهارس والمحفزات

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

قائمة مراجعة سريعة قبل الانتهاء من مرحلة الانكماش:

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

الخلاصة الحقيقية

مرحلة الانكماش لا تتعلق بالسرعة. إنها تتعلق بالثقة. حذف المخطط القديم مبكرًا جدًا يُدخل مخاطرة يصعب اكتشافها حتى فوات الأوان. فترة الانتظار الإضافية ليست وقتًا ضائعًا - إنها مخزن الأمان الخاص بك ضد التبعيات المخفية التي لم تكن تعلم بوجودها.

بمجرد اختفاء المخطط القديم، يكتمل نمط التوسع والانكماش. لقد أضفت الهيكل الجديد، ورحلت جميع المستهلكين، وأزلت القديم بأمان دون التسبب في حادث إنتاج. هذا هو الهدف الكامل من النمط: جعل تغييرات قاعدة البيانات آمنة بما يكفي حتى لا يخاف منها فريقك.