Question 1

كيف تُرحّلون قاعدة بيانات حيّة دون توقف؟

Accepted Answer

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

Question 2

هل قد يُفسد التحسين شيئاً؟

Accepted Answer

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

Question 3

هل تحتاجون صلاحية على قاعدة بيانات الإنتاج؟

Accepted Answer

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

Question 4

فاتورة الاستضافة ترتفع رغم ثبات عدد الزيارات، لماذا؟

Accepted Answer

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

Question 5

بعد الانتقال إلى serverless تتكرر أخطاء حد الاتصالات، ما السبب؟

Accepted Answer

دوال serverless تتوسّع أفقياً، وكل نسخة قد تحتفظ باتصالاتها الخاصة، فقاعدة كانت تكفي خادم تطبيق واحداً طويل العمر تستنفد حد اتصالاتها سريعاً. الحل هو موزّع اتصالات (pooler) موضوع في المكان الصحيح، وعميل مهيّأ للتعامل معه، ومعاملات قصيرة، ونقل ما لا يحتاج اتصالاً حياً خارج مسار الطلب. هذه مشكلة تصميم لا مشكلة سعة، ونادراً ما تحلّها ترقية الباقة.

Question 6

كيف تختارون بين التطبيع وتفكيكه؟

Accepted Answer

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

Question 7

كيف تكتشفون الفهارس المفقودة؟

Accepted Answer

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

Question 8

ماذا يحدث لبياناتنا إذا توقف التعاون؟

Accepted Answer

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

Question 9

كيف تتعاملون مع متطلبات إقامة البيانات في أسواق الخليج؟

Accepted Answer

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

Question 10

كيف تُدار النسخ الاحتياطية والاستعادة إلى نقطة زمنية؟

Accepted Answer

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

Question 11

هل تدعمون عزل البيانات في الأنظمة متعددة المستأجرين؟

Accepted Answer

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

كيف يمكننا المساعدة؟

خدمات قواعد البيانات
الأسئلة الشائعة

معلومات
مفيدة

البدء

الجدول الزمني

التسعير

الدعم

لا تزال لديك أسئلة؟

خدمات قواعد البياناتالأسئلة الشائعة

معلوماتمفيدة