اعثر على الطلب المكلف قبل تغيير قاعدة البيانات
ابدأ من فعل مستخدم: تحميل تصنيف، بحث مقال، إضافة إلى السلة، أو إرسال طلب. سجّل مساره، عدد الاستعلامات، مدة قاعدة البيانات، الصفوف المعادة، ومدة الطلب. يمكن لصفحة بطيئة أن تنتظر أيضًا شفرة التطبيق أو اعتمادًا آخر، لذا لا تشخّص من زمن تحميل الصفحة وحده.
خطة الاستعلام هي مسار قاعدة البيانات خلال الجداول والفهارس والانضمامات والفرز والتجميعات. في PostgreSQL، يظهر EXPLAIN ذلك المسار. EXPLAIN ANALYZE يشغّل البيان ويُبلغ عن الصفوف والأزمنة الفعلية، لذا استخدم استعلامًا ممثلاً آمنًا. الفجوة الكبيرة بين التقدير والصفوف الفعلية سبب للتحقيق في الإحصاءات أو الشروط، وليست طلب فهرس تلقائيًا.
اربِط استعلامًا مرشحًا بمسار ونتيجة، حتى لا يكون تقرير لوحة القيادة وحده أفضل من دفع دفعية الخروج البطيء.
سجّل الأزمنة قبل التغيير وحركة مرورية قابلة للمقارنة دون تسجيل معرّفات العملاء أو رموزهم أو قيم البطاقات.
صمّم الفهارس لمسار الوصول الذي تستخدمه فعليًا
الفهرس بنية مُحافظة يمكن أن تساعد في تحديد الصفوف أو إرجاعها بترتيب؛ إنه ليس مفتاح سرعة شامل. ابدأ بمرشحات الاستعلام المهم ومفاتيح الانضمام وترتيب النتائج ثم أكّد الفهرس المقترح في الخطة. توثّق PostgreSQL أن فهرس B-tree المطابق يمكنه تلبية ORDER BY دون فرز منفصل، خاصة مع LIMIT صغير.
تضيف الفهارس سعة تخزين وعمل كتابة لأن الإدراجات والتحديثات والحذفات تحافظ عليها. بالنسبة لاستعلام يحتاج جزءًا كبيرًا من جدول، قد يكون المسح التسلسلي والفرز الصريح أسرع. اختبر على بيانات شبيهة بالإنتاج واحتفظ بالفهرس فقط عندما يبرّر الفائدة تكلفته.
استخدم مرشحات الاستعلام الفعلية وORDER BY، بما في ذلك فاصل حتمي للفوز (tie-breaker) حيث تحتاج الواجهة إلى ترتيب ثابت.
راجع ما إذا كان الفهرس مستخدمًا وما يكلفه أثناء الكتابات؛ أعد التحقق مع تغير البيانات والحركة.
اجعل ترقيم الصفحات ثابتًا وميسور التكلفة
ترقيم الصفحات برقم الصفحة عادةً يستخدم LIMIT زائد OFFSET. فرض ترتيب قابل للتنبؤ دائمًا. تحذّر PostgreSQL من أنه بدون ORDER BY، قد يُرجع LIMIT مجموعة فرعية غير متوقعة؛ قيم LIMIT أو OFFSET المختلفة قد تعطي مجموعات غير متناسقة لأن المُحسّن قد يختار خططًا مختلفة.
تستحق الإزاحات الكبيرة التدقيق لأن الصفوف المتجاوزة لا تزال تُحسب. لتصفّح كتالوج عميق أو تاريخ طلبات أو أرشيف، فكّر في ترقيم الصفحات بالمسار المفاتيحي (cursor أو keyset): اطلب الصفوف بعد آخر قيمة ترتيب ثابت وفاصل فريد. حدّد كيف تظهر السجلات الجديدة أو المحذوفة قبل تغيير الواجهة.
أعد أصغر صفحة مفيدة بدلًا من نتيجة غير محدودة.
قرّر ما إذا كانت الواجهة حقًا بحاجة إلى إجمالي محدد في كل طلب.
خزن الأعمال المقروءة دون تقديم استجابة خاطئة
التخزين المخبأ يُعيد استخدام نتيجة سابقة بدلًا من إعادة بناءها من قاعدة البيانات. ابدأ على طبقة HTTP للصفحات العامة القابلة للتكرار والأصول المعرّفة بالإصدار، لأن نجاح التخزين المخبأ يمكن أن يجنب العمل في التطبيق وقاعدة البيانات. توصي web.dev بالتخزين طويل العمر لروابط معرّفة بالإصدار؛ تغيير عنوان URL هو آلية الإبطال العملية.
سياسة التخزين المخبأ قرار صحّة. يمكن لذاكرة مخبأ مشتركة إعادة استخدام استجابة واحدة عبر المستخدمين، لذا لا تشارك مخرجات العُملاء أو السلة أو السعر أو المخرجات الخاصة بالتفويض ما لم تُصَمَّم وتُختبر لذلك النطاق. Cache-Control private يقيّد إعادة الاستخدام إلى ذاكرة متصفح، بينما no-store يوجّه ألا يحتفظ أي مخبأ بها.
فصّل إخراج الكتالوج العام أو المقالات عن المخرجات الخاصة بالجلسة، والموقع، والحسّاسة للأذونات.
حدّد من قد يرى قيمة قديمة، ولأي مدة، ومسار الإبطال أو إعادة التحقق.
احمِ سعة الاتصالات بدلاً من رفع السقف فحسب
الاتصال هو جلسة عميل حية تجاه قاعدة البيانات. يمكن للعاملين والوظائف المجدولة والمعاينات أو محاولات الإعادة أن تستنفد الفتحات حتى عندما تبدو الاستعلامات المفردة مقبولة. يتحكّم max_connections في PostgreSQL بالاتصالات المتزامنة، يُعيّن عند بدء الخادم، وزيادته يخصص موارد إضافية بما في ذلك الذاكرة المشتركة. رفعه دون نموذج عبء عمل يمكن أن ينقل الفشل.
حدد ميزانية واحدة عبر عمال الويب والوظائف الخلفية والإدارة والنسخ المتماثلة. استخدم التجميع المحدود حيث يناسب، احفظ هامشًا للتعافي، وطبّق مهلات زمنية حتى لا تنتظر الأعمال المتروكة إلى الأبد. الأرقام الآمنة تعتمد على المحرك والذاكرة ومزيج الاستعلامات وحدود المزود؛ أكّدها مع المشغّل.
ضمّن عمليات الويب والعمليات، والمهام المجدولة، والهجرات، وأدوات التقارير، ووظائف النشر.
حدد التزامن واستخدم التراجع المتصاعد (backoff) حتى لا يتضاعف الطلب على الاتصالات عند حدوث خطأ.
راقب تكلفة الاستعلام مع السياق وضوابط الخصوصية
رتّب عمل قاعدة البيانات بحسب الأثر الكلّي، لا عيّنة بطيئة واحدة. قد يهم استعلام بطيء متوسط يستدعى آلاف المرات أكثر من تقرير نادر. يجمع pg_stat_statements في PostgreSQL بيانات التخطيط والتنفيذ بما في ذلك الاستدعاءات، وإجمالي ووسط زمن التنفيذ، والصفوف، ونشاط البافر. يحتاج إلى تكوين الخادم وإعادة تشغيل لإضافته أو إزالته؛ يمكن أن تضيف متابعة التخطيط حملاً إضافيًا.
اربِط مجموعات الاستعلام بالمسار وإصدار الإصدار ونطاق الوقت. توصي OpenTelemetry بجمع نص الاستعلام افتراضيًا فقط بعد التنظيف الذي يستبدل الحروف الثابتة، واستخدام ملخّص ذي تعددية منخفضة (low-cardinality) للتجميع. يساعد هذا المالكين على رؤية الاتجاهات دون تصدير بيانات العملاء أو إنشاء تسمية لكل قيمة.
راجع المدة، الوقت الكلّي، الاستدعاءات، الأخطاء، الاتصالات، والصفوف؛ كل واحد يكشف نمط فشل مختلف.
استخدم استعلامات مُعلّمة (parameterized) وتحقّق من إزالة الحروف الثابتة قبل مغادرة التتبعات أو السجلات للتطبيق.
أصدر تغييرات قاعدة البيانات كعمل موثوقية قابل للانعكاس
عامل الفهرس أو إعادة الكتابة أو سياسة التخزين المخبأ أو ضبط التجمع أو التغيير في المخطط كعملية إنتاج لها مالك ومقياس نجاح وقرار تراجع. تحقّق في بيئة ممثلة، أطلق لشريحة محدودة، وراقب الرحلة المتأثرة. السرعة ليست نجاحًا إذا أعاد التغيير بيانات خاطئة أو مفقودة أو مكررة أو قديمة.
تحتاج تغييرات المخطط إلى عناية لأن إصدارات التطبيق قد تتداخل. تصف إرشادات Google Cloud تسلسل التوافق: أطلق تطبيقًا يتعامل مع المخطط القديم والجديد، غيّر المخطط، ثم أطلق الميزة التي تستخدمه. هذا يحفظ مسار تراجع التطبيق. يختلف القفل وسلوك التغيير عبر الإنترنت بحسب المحرك والخدمة المُدارة؛ احصل على مراجعة مؤهلة للأنظمة ذات الحجم العالي أو المتعلّقة بالدفع.
سمّ المسار وإشارات الأداء والصحة والعَتبة التي توقف النشر.
تحقّق من الأداء والصحة في شريحة مسيطَر عليها قبل التوسيع؛ درّب مسار العودة خارج الحادث.