HTAP - это аббревиатура от гибридной транзакционной/аналитической обработки (Hybrid Transactional/Analytical Processing). Она характеризует системы баз данных, которые могут обрабатывать как транзакционные (OLTP), так и аналитические (OLAP) рабочие нагрузки одновременно на одном и том же наборе данных. Такая возможность позволяет выполнять аналитические запросы к текущим транзакционным данным без необходимости извлекать, преобразовывать и загружать (ETL) данные в отдельное хранилище для последующего анализа.
PostgreSQL является одной из наиболее мощных и универсальных баз данных с открытыми кодами, но установка из коробки не является вполне оптимизированной. Если вас серьезно беспокоит производительность - будь то OLTP, OLAP, смешанная нагрузка или данные временных рядов - важным моментом является настройка параметров конфигурации PostgreSQL.
Эта статья посвящена лучшим практикам настройки ключевых параметров PostgreSQL, обоснованию главных параметров конфигурации и разнообразным инструментам (включая, но не ограничиваясь timescaledb-tune), чтобы помочь автоматизировать или усовершенствовать этот процесс.
Сегодняшняя статья вызвана загадочным наблюдением: пользователи, особенно те, кто использует уровень абстракции наподобие REST или библиотек ORM для взаимодействия с базами данных, часто отключают опцию MergeJoin во всём экземпляре базы данных. Они оправдывают это действие многочисленными случаями снижения производительности.
Учитывая, сколько интересных путей выполнения MergeJoin добавляет в систему, разрабатывая IncrementalSort или порядки сортировки, полученные из лежащего в основе IndexScan, это выглядит странно: ещё одна ошибка искажённого баланса стоимости внутри модели стоимости PostgreSQL?
Как разработчик, я отказался принять такую загадочную веру в злонамеренные алгоритмы и исследовал этот случай. Оказалось, что настоящая причина (или, по крайней мере, одна из них, но довольно частая) кроется в типичной проблеме, с которой сталкивается оптимизатор: соединение по нескольким условиям.
Вы администратор баз данных, эксперт в PostgreSQL, специалист RDS/Aurora или архитектор решений, который борется с внезапным замедлением запросов? Узнайте, как воздействие на планировщик запросов PostgreSQL может преобразовать долгие минуты выполнения запросов в чудо-миллисекунды. Это исследование реального случая в PostgreSQL 14.2 должен помочь в вашем подходе к настройке запросов базы данных.
Вызов: когда быстрые запросы становятся медленными
Недавно я столкнулся со следующей ситуацией. Наша команда разработки приложений заявила о резком падении производительности запроса, который обычно выполнялся за секунды, но внезапно начал отрабатывать за несколько минут. Это исследование предлагает бесценные идеи тем, кто работает с PostgreSQL, вне зависимости от обслуживания локальных установок или же облачных решений типа Amazon RDS или Aurora. Продолжить чтение "Когда планировщик запросов PostgreSQL плутует: погружение в оптимизацию запросов"
PostgreSQL предлагает мощную - но часто неправильно воспринимаемую - возможность, называемую CREATE RULE, которая позволяет вам переписывать и дописывать под капотом запросы SQL. Эта система изначально была предназначена, чтобы сделать представления доступными для записи, но со временем некоторые пользователи попытались изменить ее назначение для общей автоматизации или управления доступом.
В современную цифровую эпоху, где данные являются основой принятия решений, производительность базы данных имеет решающее значение. Одним из ключевых аспектов оптимизации производительности является выявление и устранение запросов с высокой загрузкой процессора (CPU). В конце концов, запрос, чрезмерно потребляющий ресурсы CPU, может существенно повлиять на общую производительность и отзывчивость базы данных PostgreSQL.
При работе с запросами с высокой загрузкой CPU в PostgreSQL важно иметь возможность анализа планов исполнения запросов. Анализируя эти планы, изучая используемые индексы и выявляя последовательные просмотры или дорогостоящие операции, такие как сортировка и соединения, разработчики и администраторы баз данных могут точно определить запросы, вызывающие высокую загрузку CPU. После выявления эти запросы можно оптимизировать, что потенциально приведет к значительному улучшению общей производительности базы данных.
С каждой новой версией SQL Server всегда появляются новые возможности, которые радуют нас тем, что наконец-то мы получили доступ к полезной функции, которая уже повсюду имеется.
Введенная в SQL Server 2025 CTP 1.3 функция PRODUCT() действует подобно SUM(), но не суммирует значения, а перемножает их. Это агрегатная функции в SQL Server и, следовательно, она работает с набором данных, а не с отдельными значениями.
Вычисление произведения без PRODUCT()
До появления этой функции написание на T-SQL перемножение ряда значений в множественной парадигме было возможно, хотя и не совсем красивым. Рассмотрим сценарий, в котором необходимо перемножить множество значений по времени для расчета постоянно растущей мультипликативной метрики, такой как проценты или инфляция. Продолжить чтение "Как использовать новую функцию PRODUCT() в SQL Server 2025"
В PostgreSQL индексы играют решающую роль в оптимизации производительности запросов. Обычно индексы ссылаются на один или более столбцов таблицы. Однако функциональный индекс определяется как результат функции, применяемой к одному или нескольким столбцам одной таблицы. Эти индексы позволяют выполнять быстрый доступ к данным на основе результатов вызова функции.
Без блокировок дисковые таблицы ожидает хаос. Но вы испытываете неудобство от чрезмерных блокировок? Пользователи могут жаловаться на медленную работу приложения или отчеты готовятся целую вечность. Если так, то наличие специальной опции базы данных может ускорить ваши запросы. Но, как обычно, у всякой хорошей вещи есть обратная сторона.
В этой статье исследуется, как включение READ_COMMITTED_SNAPSHOT для вашей базы данных может облегчить чрезмерное блокирование. Сначала мы рассмотрим пример блокировок в нагруженной среде с уровнем изоляции по умолчанию Read Committed. Затем посмотрим на то, как включение уровня изоляции на основе версий строки снижает число блокированных чтений. К концу статьи вы будете готовы к тестированию этой возможности в вашей текущей среде. Продолжить чтение "Снизить блокирование в SQL Server с помощью READ_COMMITTED_SNAPSHOT"
§ Новая задача от selber на футбольную тему выставлена под номером 308 для обсуждения; сложность задачи 1 балл.
Задача 303 (SELECT) перенесена в отрицательные номера (-19).
Новая задача DML (1 балл) заменила задачу под номером 4, которая была перенесена в отрицательные номера (-5).
§ Поскольку решения задач DML с отрицательными номерами не требуется при получении сертификата, они стали доступны для решения получившим бан (при наличии оплаты участия в рейтинге). Пока таких задач немного, но их количество будет расти. Сегодня их уже стало на одну больше.
MCP Toolbox от Google является бесплатной утилитой с открытыми кодами, которая действует как мост между вашими приложениями ИИ и базами данных. Можно представить ее как универсальный транслятор: ваш ИИ может делать простые запросы, а MCP Toolbox преобразует их в запросы к базе данных (например, SQL), используя протокол MCP (Model Context Protocol) - стандартизованный способ взаимодействия инструментов и моделей.
