Пользователям нередко трудно подобрать лучший индекс для запроса, особенно
определить правильный порядок столбцов.
Представьте большую таблицу, которую нужно отфильтровать до конкретного
набора данных — всё ещё довольно объёмного. Вы можете использовать простые
условия, вроде эквивалентности или выборки диапазона, но ваш 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 индексы играют решающую роль в оптимизации производительности запросов. Обычно индексы ссылаются на один или более столбцов таблицы. Однако функциональный индекс определяется как результат функции, применяемой к одному или нескольким столбцам одной таблицы. Эти индексы позволяют выполнять быстрый доступ к данным на основе результатов вызова функции.
Без блокировок дисковые таблицы ожидает хаос. Но вы испытываете неудобство от чрезмерных блокировок? Пользователи могут жаловаться на медленную работу приложения или отчеты готовятся целую вечность. Если так, то наличие специальной опции базы данных может ускорить ваши запросы. Но, как обычно, у всякой хорошей вещи есть обратная сторона.
В этой статье исследуется, как включение READ_COMMITTED_SNAPSHOT для вашей базы данных может облегчить чрезмерное блокирование. Сначала мы рассмотрим пример блокировок в нагруженной среде с уровнем изоляции по умолчанию Read Committed. Затем посмотрим на то, как включение уровня изоляции на основе версий строки снижает число блокированных чтений. К концу статьи вы будете готовы к тестированию этой возможности в вашей текущей среде. Continue reading "Снизить блокирование в SQL Server с помощью READ_COMMITTED_SNAPSHOT"
В одном из ответов к ветке об использовании SELECT * Aaron Cutshall заметил, что "еще одним из реальных убийц производительности является SELECT DISTINCT, особенно в сочетании с UNION. У меня есть целый список часто используемых скрытых «убийц» производительности!"
Я начал размышлять... Что происходит, когда вы используете их вместе? А когда вы используете UNION на множестве неуникальных строк, что происходит? Итак, я начал писать.
Pgpool-II является ПО промежуточного уровня, которое находится между серверами PostgreSQL и клиентом баз данных PostgreSQL, обеспечивающего такие функции, как пул подключений, балансировку нагрузки, автоматическую отказоустойчивость, кэширование запросов и многое другое. Оно действует как прокси, обслуживая и распределяя клиентские подключения по множеству серверов баз данных PostgreSQL.
Вот обзор некоторых основных функций pgpool-II:
Пул подключений: pgpool-II поддерживает пул установленных подключений к серверам PostgreSQL, снижая накладные расходы на создание и закрытие подключений для каждого запроса клиента. Это улучшает производительность путем минимизации времени установки соединения и использования ресурсов на сервере баз данных.
Балансировка нагрузки: Распределяет клиентские соединения по множеству серверов PostgreSQL для равномерного распределения нагрузки. Это помогает улучшить масштабирование и производительность путем задействования ресурсов нескольких серверов.
Автоматическая отказоустойчивость: pgpool-II может обнаруживать сбои серверов PostgreSQL и автоматически перенаправлять подключения на резервные серверы в случае отказа главного сервера. Это обеспечивает высокую доступность и отказоустойчивость приложений баз данных.
Кэширование запросов: pgpool-II может кэшировать часто выполняемые запросы и их результаты, снижая рабочую нагрузку на серверы баз данных и улучшая время отклика для повторяющихся запросов.
Параллельное выполнение запросов: Поддерживается распараллеливание выполнения запроса, обеспечивая распределение и параллельное выполнение запросов на множестве серверов PostgreSQL для более быстрой обработки запроса.
Сторожевой таймер: pgpool-II включает функцию сторожевого таймера, который мониторит работоспособность и состояние серверов PostgreSQL и экземпляров pgpool-II, выполняяя по мере необходимости автоматизированные действия по отказоустойчивости и восстановлению для поддержания доступности системы.
Хорошо оптимизированные функции могут значительно улучшить эффективность базы данных. В этой статье будут даны советы и предложены методы для обеспечения наиболее эффективной работы функций в PostgreSQL.
Как функции улучшают производительность
Функции могут улучшить производительность базы данных за счет:
Сокращение сетевой задержки: Выполнение логики на стороне сервера уменьшает необходимость пересылки больших объемов данных по сети.
Минимизация передачи данных: Функции могут обрабатывать данные на сервере и возвращать клиенту только необходимый результат.
Кэширование планов выполнения: PostgreSQL кэширует планы выполнения для функций, уменьшая накладные расходы на повторяющиеся парсинг и построение плана.
Вы добавляете индексы, чтобы ускорить запросы, но как насчет удаления данных? Говорили вам, что индексы замедляют удаление? Это объясняется тем, что чем больше копий данных разбросаны по индексам, тем больше данных должен удалить SQL Server при чистке. Но подтверждается ли это утверждение результатами тестов?
В этой статье мы исследуем важность индексов в улучшении операторов DELETE. Кроме того, многие разработчики полагают, что добавление внешнего ключа создает индекс, а это значит, что они обычно отсутствуют. Как можно определить, какие внешние ключи пропускают индексы? Не беспокойтесь, полезная DMV поможет обнаружить их. Начиная с сегодняшнего дня вы приобретете навыки ускорять ваши операторы DELETE. Continue reading "Добавьте индексы, чтобы улучшить производительность SQL DELETE"
Необходимо предохранять вашу базу данных от долгоиграющих запросов, т.к. они могут подвесить ее. Для защиты вашей базы данных PostgreSQL имеется один конфигурационный параметр, устанавливающий максимально дозволенную длительность любого исполняющегося запроса. Это параметр statement_timeout.
Конфигурационный параметр: statement_timeout
Описание: Устанавливает максимально допустимую продолжительность любого оператора. Значение по умолчанию: 0 (0 означает, что параметр выключен; обычно измеряется в мс; в основном указывается в мс или сек).
PostgreSQL также записывает в журнал запрос, время ожидания которого истекло, если другой параметр log_min_error_statement установлен в ERROR. Вы можете проверить это, выполнив следующую команду в вашей базе данных.
При запросах к большим наборам данных в PostgreSQL сочетание предложений ORDER BY и LIMIT может существенно влиять на производительность. ORDER BY сортирует данные, а LIMIT ограничивает число возвращаемых строк, но вместе они создают узкое место в производительности. Понимание взаимодействия этих операций и оптимизация их использования представляется весьма важным для поддержания эффективной производительности базы данных и гарантии быстрого выполнения запросов.
В этой статье мы рассмотрим, как они могут повлиять на производительность запроса.
В этой статье описываются наиболее общие алгоритмы, которые PostgreSQL может использовать в плане выполнения данного запроса. Примите к сведению, что это не полный список; позднее могут быть добавлены другие алгоритмы.
Алгоритмы пути доступа
Все планы выполнения описывают способ доступа к данным для обеспечения вывода результатов запроса. Поэтому мы обнаружим список операторов, которые выполнялись или будут выполняться для получения результатов.
Мы увидим такие алгоритмы доступа к данным, как Seq Scan, Index Scan, Index-only scan, Bitmap index scan, Bitmap heap scan и их параллельные реализации. В зависимости от условий соединения в JOIN мы увидим алгоритмы комбинации таблиц, такие как Nested loop, Hash-join и Merge. Кроме того, будет представлена информация относительно агрегации, сортировки и буферизации.
Каждый алгоритм имеет свои собственные особенности, которые в зависимости от множества факторов могут оказаться более или менее производительными. Давайте более подробно рассмотрим каждый алгоритм доступа.
Курсоры имеют плохую репутацию в SQL Server, и вполне залуженную. Они находят свое применение в таких областях, как выполнение задач по обслуживанию баз данных. Я избегаю их, когда дело касается стандартного кода T-SQL. Проблемы производительности становятся заметными при работе с таблицами сколь-нибудь заметного размера. Если вы имеете за спиной более процедурный язык, бывает трудно думать не в терминах курсора. Но не беспокойтесь, есть надежда.
В этой статье я хочу сделать обзор типичного паттерна, который мы все видели. Он включает использование курсора или цикл WHILE для вставки или обновления данных. Начнем с того, чтобы разобраться, почему разработчик может по умолчанию начинать с курсора. Далее я построю типичный курсор для решения этой задачи. Затем мы разберемся, как можно быстрей достичь того же вывода с помощью операции на основе множеств. Continue reading "Замена курсоров SQL операциями на основе множеств - OUTPUT и MERGE"
