توصيات أداء قاعدة البيانات (من Azure PSQL)

مطور
1

مرحبًا،

نحن نستضيف منتدى Discourse الخاص بنا على Azure باستخدام مثيل “Azure Database for PostgreSQL”. تتمثل إحدى مزايا هذه الخدمة في توصيات الأداء المبنية على “خصائص قاعدة البيانات” والاستخدام.
منذ الانتقال إلى Azure، تلقينا بعض التلميحات حول فهارس مفقودة يُفترض أنها زائدة عن الحاجة، وأود مشاركتها معكم.
لاحظنا زيادة طفيفة (ليست كبيرة) في الأداء العام بعد إنشاء هذه الفهارس المفقودة، لكننا لم نتمكن من تطبيق توصيات DROP INDEX لأنها قد/ستؤدي على الأرجح إلى تعطيل التحديثات القادمة أو عمليات ترحيل قاعدة البيانات. على أي حال، لا يمكننا الجزم فيما إذا كانت هذه الفهارس آمنة للحذف أم أنها ستؤثر سلبًا على الأداء.

فيما يلي الفهارس التي اقترحها Azure علينا إنشاؤها (تأثير “منخفض” و"متوسط"):
create-indexes.csv (1.5 KB)

أما فيما يتعلق بتوصيات الفهارس “المغطاة بالفعل”:

ملخص

احذف الفهرس index_optimized_images_on_upload_id من الجدول public.optimized_images.
السبب: الفهرس مغطى بواسطة index_optimized_images_on_upload_id_and_width_and_height.

احذف الفهرس index_post_revisions_on_post_id من الجدول public.post_revisions.
السبب: الفهرس مغطى بواسطة index_post_revisions_on_post_id_and_number.

احذف الفهرس post_timings_summary من الجدول public.post_timings.
السبب: الفهرس مغطى بواسطة post_timings_unique.

احذف الفهرس index_topic_links_on_topic_id من الجدول public.topic_links.
السبب: الفهرس مغطى بواسطة unique_post_links.

احذف الفهرس index_post_uploads_on_post_id من الجدول public.post_uploads.
السبب: الفهرس مغطى بواسطة idx_unique_post_uploads.

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

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

مع أطيب التحيات،
ساسكا

2

شكرًا لمشاركتك، بعض التوصيات تبدو غريبة قليلاً…

CREATE INDEX index_topics_on_category_id ON public.topics USING btree (category_id)
CREATE INDEX index_topics_on_category_id_and_id ON public.topics USING btree (category_id, id)
CREATE INDEX index_topics_on_id_and_category_id ON public.topics USING btree (category_id, id)

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

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

شكرًا لمشاركتك هذا المنشور.

3

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

مع أطيب التحيات