Сегодняшняя статья вызвана загадочным наблюдением: пользователи, особенно те, кто использует уровень абстракции наподобие REST или библиотек ORM для взаимодействия с базами данных, часто отключают опцию MergeJoin во всём экземпляре базы данных. Они оправдывают это действие многочисленными случаями снижения производительности.
Учитывая, сколько интересных путей выполнения MergeJoin добавляет в систему, разрабатывая IncrementalSort или порядки сортировки, полученные из лежащего в основе IndexScan, это выглядит странно: ещё одна ошибка искажённого баланса стоимости внутри модели стоимости PostgreSQL?
Как разработчик, я отказался принять такую загадочную веру в злонамеренные алгоритмы и исследовал этот случай. Оказалось, что настоящая причина (или, по крайней мере, одна из них, но довольно частая) кроется в типичной проблеме, с которой сталкивается оптимизатор: соединение по нескольким условиям.
Вы администратор баз данных, эксперт в PostgreSQL, специалист RDS/Aurora или архитектор решений, который борется с внезапным замедлением запросов? Узнайте, как воздействие на планировщик запросов PostgreSQL может преобразовать долгие минуты выполнения запросов в чудо-миллисекунды. Это исследование реального случая в PostgreSQL 14.2 должен помочь в вашем подходе к настройке запросов базы данных.
Вызов: когда быстрые запросы становятся медленными
Недавно я столкнулся со следующей ситуацией. Наша команда разработки приложений заявила о резком падении производительности запроса, который обычно выполнялся за секунды, но внезапно начал отрабатывать за несколько минут. Это исследование предлагает бесценные идеи тем, кто работает с PostgreSQL, вне зависимости от обслуживания локальных установок или же облачных решений типа Amazon RDS или Aurora. Continue reading "Когда планировщик запросов 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 перемножение ряда значений в множественной парадигме было возможно, хотя и не совсем красивым. Рассмотрим сценарий, в котором необходимо перемножить множество значений по времени для расчета постоянно растущей мультипликативной метрики, такой как проценты или инфляция. Continue reading "Как использовать новую функцию PRODUCT() в SQL Server 2025"
В PostgreSQL индексы играют решающую роль в оптимизации производительности запросов. Обычно индексы ссылаются на один или более столбцов таблицы. Однако функциональный индекс определяется как результат функции, применяемой к одному или нескольким столбцам одной таблицы. Эти индексы позволяют выполнять быстрый доступ к данным на основе результатов вызова функции.
Без блокировок дисковые таблицы ожидает хаос. Но вы испытываете неудобство от чрезмерных блокировок? Пользователи могут жаловаться на медленную работу приложения или отчеты готовятся целую вечность. Если так, то наличие специальной опции базы данных может ускорить ваши запросы. Но, как обычно, у всякой хорошей вещи есть обратная сторона.
В этой статье исследуется, как включение READ_COMMITTED_SNAPSHOT для вашей базы данных может облегчить чрезмерное блокирование. Сначала мы рассмотрим пример блокировок в нагруженной среде с уровнем изоляции по умолчанию Read Committed. Затем посмотрим на то, как включение уровня изоляции на основе версий строки снижает число блокированных чтений. К концу статьи вы будете готовы к тестированию этой возможности в вашей текущей среде. Continue reading "Снизить блокирование в 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) - стандартизованный способ взаимодействия инструментов и моделей.
Двойственные представления таблица-JSON в Oracle Database 23ai позволяют хранить данные в виде строк таблицы для получения преимуществ доступа SQL в реляционной модели, в то же время допуская доступ чтения и записи в виде документов JSON для тех же самых данных. Они могут использоваться из таких языков, как Node.js и ODP.NET. В этой статье показывается, как использовать новые представления в Python.
Реляционная модель великолепна: вы можете избегать дублирования данных; гарантируется согласованность данных; вы имеете доступ посредством очень мощного и очень эффективного языка - SQL. Но от разработчиков требуется определить реляционную схему - таблицы, столбцы и типы данных - прежде, чем начать писать код. Не так легко предсказать будущее использование системы, которое может вызывать затруднения для выбранной схемы.
Вот почему вы так любите JSON. Объект JSON может содержать информацию для одного случая использования без необходимости использовать SQL для соединения таблиц. Доступ через простой запрос или единичное обращение к API базы данных. JSON имеет гибкую схему, поэтому, поскольку ваши случаи использования меняются в процессе жизненного цикла системы, вы можете легко модифицировать приложения. Но есть и недостатки: единственная иерархия может подходить лишь нескольким случаям использования. В данных могут оказаться дубликаты, что не только влияет на занимаемое пространство, но делает очень сложным поддержание согласованности. Более трудной становится оптимизация. Поэтому на первый взгляд простая модель может вызывать сложности в долгосрочной перспективе.
Continue reading "Лучшее из двух подходов - реляционного и JSON - одновременно"
