Встроенный в базы данных 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 индексы играют решающую роль в оптимизации производительности запросов. Обычно индексы ссылаются на один или более столбцов таблицы. Однако функциональный индекс определяется как результат функции, применяемой к одному или нескольким столбцам одной таблицы. Эти индексы позволяют выполнять быстрый доступ к данным на основе результатов вызова функции.
Без блокировок дисковые таблицы ожидает хаос. Но вы испытываете неудобство от чрезмерных блокировок? Пользователи могут жаловаться на медленную работу приложения или отчеты готовятся целую вечность. Если так, то наличие специальной опции базы данных может ускорить ваши запросы. Но, как обычно, у всякой хорошей вещи есть обратная сторона.
В этой статье исследуется, как включение 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. Вы можете проверить это, выполнив следующую команду в вашей базе данных.
Continue reading "Тайм-аут оператора в PostgreSQL"