Когда одновременно выполняется несколько транзакций, как база данных поддерживает согласованность данных? Вот где вступают в действие уровни изоляции. Они определяют видимость изменений, совершенных одной транзакцией, остальным - и помогают предотвратить проблемы типа грязного чтения, неповторяемого чтения и фантомных чтений.
В этой статье мы исследуем четыре стандартных уровня изоляции, определенных стандартом SQL, и как PostgreSQL реализует их под капотом. Вы узнаете, что позволяет каждый уровень и что он запрещает, и как PostgreSQL обеспечивает целостность данных - особенно посредством своей сериализуемой изоляции (Serializable isolation)
Пользователям нередко трудно подобрать лучший индекс для запроса, особенно
определить правильный порядок столбцов.
Представьте большую таблицу, которую нужно отфильтровать до конкретного
набора данных — всё ещё довольно объёмного. Вы можете использовать простые
условия, вроде эквивалентности или выборки диапазона, но ваш WHERE может
включать и более сложные условия — множественный выбор (IN) и комбинации (OR).
После фильтрации вы хотите показать лишь несколько строк, отсортированных по
некоторым столбцам, и ограничить результат с помощью LIMIT или FETCH FIRST ROWS
— типичный случай разбивки на страницы. Хотя индексы помогают находить
диапазоны значений и упорядочивать результаты, при всех этих условиях трудно
решить, в каком порядке располагать столбцы в индексе.
Если вы похожи на меня, то Regex - это одна из тех древних технологий/инструментов, которые вы никогда в достаточной мере не изучали. Вас может удивить, что Regex (регулярное выражение) на самом деле появились в 1950-х годах в период разработки многих современных компьютеров (Регулярное выражение — Википедия). Конечно, как и многие основные инструменты, они нарастили за последние 70 лет функциональность и области использования.
Использование регулярных выражений в SQL Server было ограничено выходом за пределы SQL Server для выполнения их функций через внешнюю службу, такую как использование процедур CLR. К счастью в 2024 Microsoft наконец начал добавление прямой поддержки, сначала в базах данных Azure SQL, а сейчас такая функциональность доступна в SQL Server 2025. В итоге в SQL Server стали доступными несколько Regex-функций, которые и будут тут рассмотрены. Основой реализации в SQL Server стала библиотека RE2 (RE2 Regular Expression Syntax).
В современных приложениях JSON присутствует повсюду, и разработчики могут применять всю мощь базы данных для обработки многих операций, используя JSON на входе. В этой статье - третьей в серии, посвященной JSON, - мы раскроем потенциал JSON-функций PostgreSQL и узнаем, как они могут расширить наши возможности в написании сложных SQL-запросов.
В сравнении с MSSQL PostgreSQL обладает такими преимуществами, как экономическая эффективность, гибкость и открытые коды, что позволяет распространять ее без лицензионных сборов, в отличие от MSSQL, которая требует коммерческой лицензии. Высокая поддержка стандарта SQL в PostgreSQL выражается в синтаксисе, который знаком пользователям MSSQL.
Естественно, каждая СУБД вводит свой собственный набор функций и функциональность, которые мы можем использовать, и PostgreSQL предлагает широкий выбор функций для запросов и манипуляции объектами JSON.
Люди часто спрашивают: «Как можно автоматически регулярно перестраивать индексы?» или «Когда нужно перестраивать индексы в PostgreSQL?». Каждый раз у меня возникает ощущение, что они пытаются решить проблему, которой нет. Впрочем, оператор REINDEX существует не зря, и иногда перестроить индекс действительно разумно. В этой статье я объясню, когда уместно перестраивать индекс и как получить данные, чтобы принять такое решение.
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. После выявления эти запросы можно оптимизировать, что потенциально приведет к значительному улучшению общей производительности базы данных.
