Планировщик запросов PostgreSQL - это сложный инженерный механизм, обычно принимающий блестящие решения относительно того, как выполнять ваши запросы. Однако в сложных сценариях или при необычных распределениях данных вы можете знать лучший способ. Именно в таких ситуациях на помощь приходит pg_hint_plan - мощное расширение, которое позволяет вам руководить, или "советовать", планировщиком для выбора специфичного пути выполнения.
Как специалисты по базам данных, мы все сталкивались с этим ужасным моментом, когда пользователи начинают жаловаться на медленные запросы, и внезапно все смотрят на вас с выражением «исправьте это сейчас же». Настройка производительности Oracle может показаться невероятно сложной, особенно в условиях стресса, но хорошая новость состоит в том, что большинство проблем с производительностью возникают по нескольким распространённым причинам. Позвольте мне рассказать вам о нескольких проверенных методах, которые спасали мне жизнь больше раз, чем я могу сосчитать.
Начнем с самого простого: статистика и планы выполнения
Прежде чем перейти с сложным стратегиям настройки, всегда проверяйте актуальность вашей статистики. Оптимизатор Oracle на основе стоимости всецело опирается на точность статистики для принятия умных решений относительно путей выполнения запросов. Мне приходилось видеть запросы, которые выполнялись в 10 раз медленнее только потому, что кто-то забыл обновить статистику после загрузки большого объема данных.
Continue reading "Настройка производительности в Oracle: практические методы, которыми должен владеть каждый DBA"
При модификации данных в базе данных SQL соответствующие индексы тоже изменяются. Эти изменения приводят к фрагментации индексов. Фрагментация означает, что логический порядок данных на страницах индекса не соответствует физическому порядку. Во фрагментированных индексах информация не располагается логически, что делает операции извлечения данных из индекса более затратными по времени, это приводит к проблемам производительности запросов. Таким образом, фрагментацию индексов следует периодически устранять для поддержания высокой производительности. Операции перестройки и реорганизации индекса как раз направлены на дефрагментацию индексов.
В данной статье мы рассмотрим то, что является общим и различным в этих операциях. Прежде чем начать, мы объясним некоторые важные связанные с ними понятия. В частности, ту информацию, которая стоит за коэффициентом заполнения и статистикой, т.к. эти понятия упоминаются при обсуждении операций по перестроению и реорганизации индекса.
Встроенный в базы данных Oracle “Client Result Cache” (CRC) является эффективным, интегрированным, управляемым кэшем, который резко улучшает производительность запросов и существенно снижает нагрузку на базу данных при повторяющихся запросах к по большей части статическим таблицам, таким как почтовые индексы или номера деталей. Никакие изменения в приложениях не требуются. Никакого отдельное промежуточного кэша устанавливать не нужно. CRC доступен для каждого "толстого" клиента, который использует библиотеки Oracle Client, такие как драйверы для Python, Node.js, Go, PHP, Rust, Ruby и Oracle C API. Он также доступен в JDBC. Эта статья демонстрирует пример для Python.
Преимущества кэширования результатов клиента
Может использоваться без необходимости изменять код приложения.
Улучшенное время отклика запроса.
Операторы не посылаются для выполнения в базу данных.
Лучшая производительность за счет устранения циклов обмена между серверами.
Улучшенная масштабируемость сервера баз данных за счет экономии ресурсов сервера.
Автоматически управляемое аннулирование кэша, поддерживающее соответствие кэша изменениям в базе данных.
Не требуется сервер промежуточного слоя для кэширования.
Разработчикам не требуется создавать или использовать собственный кэш.
Индексы в MySQL являются одним из главных средств улучшения производительности запросов. Они особенно полезны, когда основные операции вашего проекта относятся к чтению данных, хранящихся в базе данных. Мы уже обсуждали нюансы индексов в MySQL, где говорилось, что MySQL предлагает вам для выбора различные типы SQL-индексов.
Основной тип индекса в MySQL - это индекс B-Tree, рассмотренный нами в одной из предыдущих статей. Если вы работаете с MySQL, то определенно знаете также о других нюансах индексов, одним из которых является тот факт, что индексы B-Tree могут строиться на нескольких столбцах (обычно их называют составными индексами). В этом примере мы используем MariaDB, хотя Percona Server для MySQL и MySQL Server будут вести себя идентично.
Пользователям нередко трудно подобрать лучший индекс для запроса, особенно
определить правильный порядок столбцов.
Представьте большую таблицу, которую нужно отфильтровать до конкретного
набора данных — всё ещё довольно объёмного. Вы можете использовать простые
условия, вроде эквивалентности или выборки диапазона, но ваш WHERE может
включать и более сложные условия — множественный выбор (IN) и комбинации (OR).
После фильтрации вы хотите показать лишь несколько строк, отсортированных по
некоторым столбцам, и ограничить результат с помощью LIMIT или FETCH FIRST ROWS
— типичный случай разбивки на страницы. Хотя индексы помогают находить
диапазоны значений и упорядочивать результаты, при всех этих условиях трудно
решить, в каком порядке располагать столбцы в индексе.
HTAP - это аббревиатура от гибридной транзакционной/аналитической обработки (Hybrid Transactional/Analytical Processing). Она характеризует системы баз данных, которые могут обрабатывать как транзакционные (OLTP), так и аналитические (OLAP) рабочие нагрузки одновременно на одном и том же наборе данных. Такая возможность позволяет выполнять аналитические запросы к текущим транзакционным данным без необходимости извлекать, преобразовывать и загружать (ETL) данные в отдельное хранилище для последующего анализа.
PostgreSQL является одной из наиболее мощных и универсальных баз данных с открытыми кодами, но установка из коробки не является вполне оптимизированной. Если вас серьезно беспокоит производительность - будь то OLTP, OLAP, смешанная нагрузка или данные временных рядов - важным моментом является настройка параметров конфигурации PostgreSQL.
Эта статья посвящена лучшим практикам настройки ключевых параметров PostgreSQL, обоснованию главных параметров конфигурации и разнообразным инструментам (включая, но не ограничиваясь timescaledb-tune), чтобы помочь автоматизировать или усовершенствовать этот процесс.
Вы администратор баз данных, эксперт в PostgreSQL, специалист RDS/Aurora или архитектор решений, который борется с внезапным замедлением запросов? Узнайте, как воздействие на планировщик запросов PostgreSQL может преобразовать долгие минуты выполнения запросов в чудо-миллисекунды. Это исследование реального случая в PostgreSQL 14.2 должен помочь в вашем подходе к настройке запросов базы данных.
Вызов: когда быстрые запросы становятся медленными
Недавно я столкнулся со следующей ситуацией. Наша команда разработки приложений заявила о резком падении производительности запроса, который обычно выполнялся за секунды, но внезапно начал отрабатывать за несколько минут. Это исследование предлагает бесценные идеи тем, кто работает с PostgreSQL, вне зависимости от обслуживания локальных установок или же облачных решений типа Amazon RDS или Aurora. Continue reading "Когда планировщик запросов PostgreSQL плутует: погружение в оптимизацию запросов"
В PostgreSQL индексы играют решающую роль в оптимизации производительности запросов. Обычно индексы ссылаются на один или более столбцов таблицы. Однако функциональный индекс определяется как результат функции, применяемой к одному или нескольким столбцам одной таблицы. Эти индексы позволяют выполнять быстрый доступ к данным на основе результатов вызова функции.
