Рекомендации по производительности базы данных (от Azure PSQL)

Разработка
1

Здравствуйте,

мы размещаем наш форум на базе Discourse в Azure с использованием экземпляра «Azure Database for PostgreSQL». Одним из преимуществ этого сервиса являются рекомендации по производительности, основанные на «характеристиках базы данных» и её использовании.

После миграции в Azure мы получили несколько подсказок относительно отсутствующих и, вероятно, избыточных индексов, которыми я хочу с вами поделиться.

После создания отсутствующих индексов мы заметили незначительное (небольшое) общее повышение производительности, однако не смогли применить рекомендации по удалению индексов (DROP INDEX), так как это могло бы (или может) нарушить будущие обновления или миграции базы данных. В любом случае мы не можем сказать, безопасно ли удалять эти индексы или это негативно скажется на производительности.

Ниже приведены индексы, которые Azure предложила нам создать (влияние «низкое» и «умеренное»):
create-indexes.csv (1.5 КБ)

А вот рекомендации по уже существующим индексам:

Сводка

Удалить индекс 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.

К рекомендациям по удалению («DROP») стоит относиться скептически, так как, по моему мнению, это повлияет лишь на общий размер базы данных, но не повысит производительность. Например: вся наша база данных занимает около 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.

Что касается редко используемых индексов, примерно полгода назад мы проанализировали статистику базы данных, чтобы найти индексы, которые не использовались в нашей инфраструктуре. Мы удалили несколько из них, но эта тема служит хорошим напоминанием о необходимости снова пройти этот процесс.

Спасибо за публикацию.

3

Спасибо за ваш ответ и за то, что указали мне на эти три индекса. Я не заметил этот дубликат, так как рекомендации поступали не сразу, и я применял их по частям в течение нескольких недель.
Даже странно, что они не появляются в рекомендациях по DROP. Похоже, у Azure ещё есть над чем поработать :smiley: (и мне придётся проверять эти рекомендации дважды).

С уважением