Technical Tutorials

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

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

تحدي المخططات الصارمة للتدقيق

لنأخذ في الاعتبار تصميم جدول تدقيق تقليدي:

CREATE TABLE audit_logs (
    id SERIAL PRIMARY KEY,
    user_id UUID,
    action VARCHAR(50),
    target_id VARCHAR(100),
    old_value JSONB,
    new_value JSONB,
    created_at TIMESTAMP DEFAULT NOW()
);

بينما يعمل هذا التصميم بشكل جيد لعمليات CRUD القياسية، ماذا يحدث عندما تحتاج إلى تسجيل سير عمل معقد يتضمن بيانات تعريفية من ثلاثة خدمات مختلفة؟ ستنتهي بك الحال مع جدول متفرق مليء بالقيم الفارغة (NULLs) أو، الأسوأ من ذلك، ستقوم بتعديل مخطط الجدول بشكل متكرر، مما يؤدي إلى احتقان القفل في بيئة الإنتاج. يحل JSONB مشكلة عدم كفاءة التخزين والصرامة في المخطط، لكنه يطرح تحدياً جديداً: الاستعلام عن البيانات غير المهيكلة بكفاءة.

الفهرسة للأداء: ميزة GIN

السر في استخدام JSONB بفعالية هو الفهرسة المناسبة. لا تعمل فهارس B-tree القياسية بشكل جيد مع هياكل JSON العميقة. بدلاً من ذلك، يوفر PostgreSQL فهارس مقلوبة عامة (GIN)، والتي تم تحسينها لأنواع البيانات المركبة وJSONB.

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

CREATE INDEX idx_audit_logs_user_id 
ON audit_logs USING gin ((data ->> 'user_id'));

لاحظ استخدام الصيغة (data ->> 'user_id'). يستخرج المشغل ->> الحقل كنص، مما يسمح لفهرس GIN بالعمل بشكل صحيح. بدون هذا الفهرس، ستؤدي الاستعلامات التي تصفي حسب user_id إلى عمليات مسح تسلسلي، مما يدمر الأداء على الجداول الكبيرة.

مثال عملي: التصفية والتجميع

لنفترض أن عمود JSONB data يخزن الأحداث بهذا الشكل:

{
  "user_id": "550e8400-e29b-41d4-a716-446655440000",
  "action": "UPDATE_PROFILE",
  "metadata": {
    "ip_address": "192.168.1.1",
    "device": "iOS"
  },
  "changes": [
    {"field": "email", "old": "a@b.com", "new": "c@d.com"}
  ]
}

لعرض جميع الإجراءات التي قام بها مستخدم معين، تستعلم عن الحقل المفهرس:

SELECT id, data 
FROM audit_logs 
WHERE data ->> 'user_id' = '550e8400-e29b-41d4-a716-446655440000'
ORDER BY created_at DESC 
LIMIT 100;

سيتعرف مخطط PostgreSQL على فهرس التعبير ويستفيد من مسح فهرس Bitmap، مما يضمن تنفيذ الاستعلام في أجزاء من الثانية حتى مع وجود ملايين السجلات.

التحقق من صحة المخطط لضمان سلامة البيانات

على الرغم من أن JSONB لا يحتوي على مخطط، فإن الاعتماد الكلي على المرونة قد يؤدي إلى بيانات غير نظيفة. للحفاظ على السلامة، استخدم قيود CHECK في PostgreSQL مع التحقق من صحة مخطط JSON. يضمن ذلك أن كل كائن JSON يتم إدراجه في سجل التدقيق يتوافق مع بنية أساسية.

ALTER TABLE audit_logs 
ADD CONSTRAINT json_schema_valid 
CHECK (jsonb_schema_valid(data, '{
  "type": "object",
  "required": ["user_id", "action"],
  "properties": {
    "user_id": {"type": "string"},
    "action": {"type": "string"}
  }
}'));

يجمع هذا النهج بين أفضل ما في العالمين: تجربة المطور في NoSQL مع ضمانات سلامة البيانات الصارمة في قواعد البيانات العلائقية.

الخاتمة

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