Управление транзакциями в базах данных

1. Что такое транзакции в БД
2. Обработка ошибок и откаты
3. Уровни изоляции
4. Управление блокировками
5. Производительность и оптимизация
6. Распределенные транзакции
7. Инструменты и техники мониторинга

Управление транзакциями в базах данных — один из способов обеспечения достоверности, целостности и консистентности информации. Для программистов понимание этих принципов критически важно, так как позволяет создавать устойчивые и эффективные приложения, способные справляться с большими нагрузками и сложными сценариями работы.

Управление транзакциями позволяет не только обеспечить корректность обработки информации в штатных и ошибочных ситуациях, но и заметно повысить производительность системы. Это особенно актуально в многопользовательских БД, где одновременный нескоординированный доступ к данным может привести к потере информации, нарушению целостности и возникновению конфликтов. 

Знание принципов управления позволяет специалистам по программированию разрабатывать системы, которые соблюдают требования ACID (атомарность, согласованность, изоляция и устойчивость) и являются базой для создания надежных приложений.

Цель статьи — предоставить всесторонний обзор теоретических основ и практических аспектов управления транзакциями в БД. Мы рассмотрим ключевые концепции и методы, которые нужны для эффективного управления, а также реальные сценарии и современные вызовы, с которыми сталкиваются программисты.

Разберем принципы работы транзакций, обсудим уровни их изоляции и влияние на производительность, а также рассмотрим инструменты и средства мониторинга. 

Что такое транзакции в БД

Транзакция — это последовательность операций, которые выполняются как единое целое. Основная цель — гарантировать, что все включенные в транзакцию задачи выполняются успешно или ни одна из них не будет выполнена вовсе. Такое свойство называют атомарностью. Это критически важно для поддержания целостности данных. Особенно в условиях многопользовательских систем, где одновременно может происходить множество изменений.

Ключевые свойства транзакций описывает концепция ACID, которая включает такие характеристики, как: 

• атомарность (atomicity);
• согласованность (consistency);
• изоляция (isolation);
• устойчивость (durability).

Атомарность гарантирует, что не будет таких ситуаций, когда одни данные в БД обновлены, а другие нет. Чтобы добиться этого, завернутые в транзакцию операции, которые требуют изменения информации в несколько шагов, проводят как единое целое, атомарно. И если любая из них вызывает ошибку, то все сделанные в рамках транзакции изменения отклоняются. 

Согласованность обеспечивает перевод базы данных из одного допустимого состояния в другое. То есть сама БД позволяет накладывать ограничения на данные и проверять их. Если все процессы проходят успешно, но по их результатам система оказывается в состоянии противоречия наложенным ограничениям, то транзакцию отклонят, никакие сведения не изменятся. 

Изоляция подразумевает, что операции в группе будут влиять друг на друга ровно в той степени, какую допускает их уровень изолированности. Максимально изолированные друг от друга транзакции могут исполняться параллельно, но с тем же результатом, какой был бы при последовательном исполнении. 

Устойчивость гарантирует, что после успешного завершения группы операций изменения останутся сохраненными, даже если произойдет сбой системы.

Представьте себе интернет-магазин, где покупатель оформляет заказ. Транзакция в этом случае может включать несколько процессов: уменьшение количества товаров на складе, обновление баланса покупателя и запись информации о заказе в базу данных. 

Если одна из этих операций не удалась, транзакцию отменяют. Все изменения откатывают, чтобы исключить возникновение несогласованного состояния, например уменьшение количества товаров без фактического оформления заказа.

Подобным образом работает и перевод средств с одного счета на другой. В одну транзакцию упаковывают дебетование одного счета и кредитование другого. Обе операции надо выполнить успешно, чтобы транзакция была завершена. Система должна гарантировать, что выполнены будут либо обе операции, либо ни одна из них, чтобы избежать потери или двойного списания средств.

Обработка ошибок и откаты

В многопользовательских системах, где множество процессов происходит одновременно, сбои и ошибки становятся нормальной реакцией, способом сохранить согласованность данных. Именно поэтому их обработка и механизмы отката транзакций (rollback) становятся основой надежной работы всей системы.

Методы отката позволяют вернуть информацию в состояние, которое предшествовало началу транзакции в случае, если в процессе произошла ошибка. Это гарантирует, что данные не «развалятся» из-за частично успешных операций. Откат может быть инициирован: 

• автоматически при обнаружении ошибки;
• вручную, если приложение обнаруживает неточность, которая требует возврата в исходное состояние.

Представить это можно следующим образом: при обработке запроса система создает копии объектов, которые должны быть изменены при успешном решении задачи. Если во время исполнения транзакции внутри возникает ошибка, то система в качестве результата своей работы возвращает именно ее. А копии объектов, с которыми работала, просто выбрасывает. Если же транзакция успешна, то измененные данные записывают и ее подтверждают. 

Для иллюстрации рассмотрим примеры обработки ошибок и отката транзакций с использованием Platform V Pangolin DB. Допустим, мы разрабатываем приложение для управления заказами в интернет-магазине. При оформлении заказа система выполняет несколько операций: 

• уменьшает количество товаров на складе;
• обновляет баланс пользователя;
• записывает информацию о заказе в базу данных.

Если в процессе одной из операций возникает ошибка, например из-за недостаточного количества товаров на складе, транзакция должна быть отменена. Код может быть примерно таким: 

DO $$
DECLARE
    product_stock INT;
    order_quantity INT := 5; -- Количество, которое пытаемся заказать
    product_to_order INT := 1; -- Идентификатор продукта, который пытаемся заказать
BEGIN
    -- Начало транзакции
    BEGIN
        -- Проверяем количество на складе
        SELECT quantity INTO product_stock FROM products WHERE product_id = product_to_order;

        -- Если на складе недостаточно товаров, вызываем исключение
        IF product_stock < order_quantity THEN
            RAISE EXCEPTION 'Insufficient stock for product ID %', product_to_order;
    END IF;

        -- Если товаров достаточно, уменьшаем количество на складе
        UPDATE products SET quantity = quantity - order_quantity WHERE product_id = product_to_order;

        -- Создаем заказ
        INSERT INTO orders (product_id, order_quantity) VALUES (product_to_order, order_quantity);

        -- Фиксируем транзакцию
        COMMIT;
    EXCEPTION
        WHEN OTHERS THEN
            -- Откат транзакции в случае ошибки
            ROLLBACK;
            -- Выводим сообщение об ошибке
            RAISE NOTICE 'Transaction failed: %', SQLERRM;
    END;
END $$;

Заметим, что вместо прямой проверки мы можем запретить отрицательные значения остатков, создав ограничение: 

ALTER TABLE products
ADD CONSTRAINT positive_quantity CHECK (quantity >= 0);

С его помощью мы переложим ответственность за контроль остатков на базу данных, но код нашей процедуры почти не изменится. По-прежнему для возврата ошибки нужно будет перехватывать исключение и принудительно откатывать транзакцию, а затем уже возвращать ошибку.

Для электронной коммерции этот кейс — нормальная ситуация. Например, во время распродажи, пока одни покупатели разглядывают товары, другие их раскупают. И когда первые решаются сделать покупку, товара на складе может уже и не быть.

Уровни изоляции

Уровни изоляции устанавливают баланс между производительностью и целостностью информации. Существует несколько уровней изоляции для решения определенных задач и предотвращения различных аномалий.

Read Uncommitted

Позволяет транзакциям читать данные, которые еще не были зафиксированы другими транзакциями. Это самый низкий уровень изоляции, который допускает чтение «грязных» сведений и может привести к неконсистентным результатам, зато обеспечивает наивысшую производительность. Он подходит для аналитических приложений, где агрегируется большое количество данных и нужна высокая производительность. Кейс использования допускает чтение промежуточных сведений, поскольку маленькие неточности на фоне значительных объемов сведений существенной роли не играют, зато информация доставляется здесь и сейчас. 

Read Committed 

Предотвращает чтение «грязных» данных, разрешает только чтение зафиксированных. Этот уровень изоляции обеспечивает более высокую степень целостности информации по сравнению с Read Uncommitted, сохраняя при этом хорошую производительность. Read Committed используют по умолчанию. Например, в приложениях для электронной коммерции, когда пользователь просматривает списки товаров с их остатками, не нужна строгая изоляция от других транзакций, которые изменяют информацию в реальном времени. 

Repeatable Read 

Гарантирует, что данные, которые прочитала транзакция, останутся неизменными до ее завершения. Это предотвращает такие аномалии, как неповторяющееся чтение, где сведения могут измениться между двумя чтениями в рамках одной транзакции. 

Этот уровень изоляции обеспечивает более высокую целостность информации за счет потенциального снижения производительности. Важно понимать, что производительность снижается не из-за того, что процессоры сервера физически должны выполнять значительно большее количество работы. Причина в другом: для выполнения условия неизменности читаемых данных приходится блокировать больше наборов информации. Соответственно, больше и вероятность того, что другие группы операций столкнутся с этими блокировками и их исполнение приостановят до снятия блокировок. 

Уровень Repeatable Read хорошо подходит для банковских приложений, где нужна согласованность данных в течение всей транзакции. Например, при проверке баланса счета перед переводом средств важно, чтобы сведения оставались неизменными до завершения операции, предотвращали любые изменения другими транзакциями. Иначе есть риск допустить перерасход (овердрафт) по счету. 

Serializable

Представляет собой самый высокий уровень изоляции. Полностью предотвращает все типы аномалий, в том числе фантомные чтения, когда новые строки добавляются другими транзакциями после начала текущей. Этот уровень изоляции гарантирует, что группы операций будут выполняться последовательно, как если бы их выполняли одну за другой. Часто его сопровождает значительное снижение производительности из-за масштабных блокировок данных. 

Такой уровень следует применять выборочно. Он подходит для финансовых систем, где важна абсолютная точность информации. Например, при выполнении сложных финансовых расчетов и отчетов нужно гарантировать, что все транзакции выполняют последовательно, без вмешательства других операций. 

Управление блокировками

Суть — в ограничении доступа к данным при обработке транзакцией, цель — избежать конфликтов и некорректных результатов. Существует два вида блокировок: 

• shared (разделяемые);
• exclusive (исключительные).

Разделяемые блокировки позволяют нескольким транзакциям одновременно читать данные и не мешать друг другу. Этот тип используется, когда транзакции выполняют операции, которые не изменяют сведения. Это обеспечивает высокую степень параллелизма и улучшает производительность системы. 

Исключительные блокировки, напротив, запрещают доступ к информации другим транзакциям до завершения операции, которая изменяет данные. Это предотвращает конфликтующие изменения и гарантирует целостность сведений, но может снизить производительность системы из-за необходимости ждать освобождения блокировки.

Блокировки оказывают значительное влияние на производительность. С одной стороны, правильное их использование позволяет избежать конфликтов и обеспечить согласованность информации. С другой стороны, чрезмерное применение блокировок, особенно исключительных, может привести к задержкам и снижению общей производительности системы. Platform V Pangolin DB автоматически управляет блокировками для большинства процессов, и это рекомендуемый режим работы. Однако бывают случаи, когда ручное управление блокировками необходимо. 

Примеры:

1. Когда группа операций включает несколько шагов, которые затрагивают несколько таблиц, и важно сохранить согласованное состояние на протяжении всей транзакции.
2. Если транзакция включает долгие операции, которые могут вызвать конфликты, ручное управление блокировками может помочь предотвратить проблемы с конкурентным доступом.
3. В ситуациях, где возможны взаимоблокировки, ручное управление может помочь упорядочить доступ к ресурсам.

В Platform V Pangolin DB представлен широкий набор инструментов для  управления блокировками: 

1. ACCESS SHARE используется для операций чтения, таких как SELECT. Эта блокировка не мешает другим транзакциям выполнять операции, но предотвращает выполнение процессов, которые изменяют данные таблицы.
2. ROW SHARE применяется для операций, таких как SELECT FOR UPDATE и SELECT FOR SHARE. Она позволяет другим транзакциям читать информацию и накладывать аналогичные блокировки, но не разрешает выполнять процессы, которые изменяют сведения таблицы.
3. ROW EXCLUSIVE используют для процессов, таких как INSERT, UPDATE, DELETE. Она предотвращает наложение разделяемых и исключительных блокировок на строки, но позволяет накладывать разделяемые блокировки доступа.
4. SHARE UPDATE EXCLUSIVE применяют для операций, таких как ANALYZE. Она предотвращает наложение блокировок, которые изменяют данные или структуру таблицы, но позволяет выполнять процессы чтения и обновления индексов.
5. SHARE используют для операций, которые требуют блокировки таблицы, но не изменяют данные. Примером может быть создание индекса. Эта блокировка совместима с другими разделяемыми блокировками.
6. SHARE ROW EXCLUSIVE применяют для операций, таких как создание триггеров. Она предотвращает выполнение других процессов, которые изменяют информацию, но позволяет чтение.
7. EXCLUSIVE используют для операций, таких как ALTER TABLE. Она блокирует все другие процессы на таблице, кроме тех, которые только читают информацию.
8. ACCESS EXCLUSIVE — самая строгая блокировка, которую используют для таких операций, как DROP TABLE. Она блокирует все другие процессы, в том числе чтение данных.

Например, в интернет-магазине пользователи могут одновременно добавлять товары в корзину и оформлять заказы. При добавлении нужна только разделяемая блокировка, поскольку операция не изменяет данные о наличии товара на складе. Однако при оформлении заказа понадобится исключительная блокировка, чтобы гарантировать, что количество товаров корректно уменьшится, и избежать конфликта с другими заказами.

В Platform V Pangolin DB доступна возможность явного управления блокировками с помощью команд LOCK. Например, чтобы установить разделяемую блокировку на таблицу products, можно использовать следующую команду:

BEGIN;
LOCK TABLE products IN SHARE MODE;
-- Операции чтения данных из таблицы products
COMMIT;

Для установки исключительной блокировки используют команду:

BEGIN;
LOCK TABLE products IN EXCLUSIVE MODE;
-- Операции изменения данных в таблице products
COMMIT;

Когда вы используете ручные блокировки, обычно это работа с уровнем изоляции Serializable. Применение ручных блокировок позволяет точно контролировать доступ к сведениям, сохранять их согласованность и при этом выигрывать в производительности за счет сложности разработки.

Производительность и оптимизация

Когда множество транзакций выполняются одновременно, это может привести к задержкам из-за блокировок, ожиданию ресурсов и росту времени отклика. 

Транзакции, особенно длительные или сложные, могут блокировать доступ к данным для других групп операций. Это приводит к конфликтам и снижению параллелизма. Например, транзакция, которая обновляет множество записей или выполняет сложные вычисления, может задерживать выполнение других процессов, ожидающих доступа к тем же сведениям. Это вызывает конкуренцию за ресурсы и может привести к снижению общей производительности системы.

Существует несколько методов оптимизации производительности групп операций. Один из наиболее важных подходов — минимизация времени выполнения. Этого можно достичь путем разбивки сложных групп операций на более мелкие, более управляемые части, что позволяет сократить время удержания блокировок и повысить параллелизм.

Использование индексов может значительно ускорить процессы поиска, обновления и удаления данных, снизить нагрузку на БД. Они позволяют быстро находить нужные записи. Это уменьшает время выполнения и минимизирует воздействие на другие операции.

Еще один метод — настройка уровней изоляции транзакций. Выбор уровня изоляции, который соответствует конкретным требованиям приложения, может помочь найти баланс между целостностью данных и производительностью. Чем меньше уровень изоляции, тем быстрее все работает, но тем более вероятны ошибки.

В Platform V Pangolin DB существуют особые приемы оптимизации транзакций. Например, использование команды VACUUM помогает удалять «мертвые» записи и освобождать пространство, что повышает производительность базы данных. Настройка некоторых технических параметров конфигурации СУБД, таких как max_connections, work_mem и maintenance_work_mem, также может значительно влиять на эффективность работы транзакций. И подбирать эти параметры стоит с учетом тех условий, в которых работает база (физический или виртуальный сервер), а также выделенных ресурсов.

Кроме того, для ускорения повышения производительности всей системы можно использовать батчевые операции. Они разбивают длинную по времени исполнения транзакцию на относительно небольшие части, а временная (между батчами) разблокировка пропускает другие транзакции и повышает параллелизм системы. 

Также однотипные операции, например массовые вставки, можно собирать в транзакции. Это снижает накладные расходы, связанные с фиксацией для каждой вставки, что значительно повышает производительность.

Распределенные транзакции

Используются в случаях, когда обрабатываемую информацию хранят в нескольких разнородных базах данных или на различных серверах. В отличие от локальных групп операций, которые ограничиваются одной базой данных, распределенные охватывают несколько БД или других ресурсов, требуют координации и согласованности между ними. Основная задача — обеспечить целостность и согласованность данных во всех участвующих системах.

Особенности включают необходимость использования протоколов согласования, таких как двухфазный или трехфазный коммит. Эти протоколы обеспечивают согласованное применение изменений во всех участвующих системах. Двухфазный коммит (2 phase commit, 2PC) состоит из двух этапов: подготовительного и завершающего. 

1. На первом этапе все участники транзакции сообщают координатору о своей готовности применить изменения.
2. На втором этапе координатор либо подтверждает изменения, либо откатывает их в зависимости от ответов участников.

Этот подход позволяет добиться согласованности, но повышает сложность и задержки из-за необходимости координации.

Распределенные транзакции по своей природе работают не очень быстро, поскольку на них влияют такие факторы, как сетевые задержки, сбои узлов и необходимость согласования между разнородными системами. Протокол двухфазного коммита как раз и нужен для того, чтобы бороться с проблемами, которые привносят сетевые соединения. И этот протокол гарантирует, что транзакция либо завершится успешно на всех узлах, либо будет полностью откачена. То есть помогает реализовать свойство атомарности в распределенной системе. 

Еще одна проблема связана с производительностью. Распределенные транзакции могут существенно замедлить систему из-за необходимости координации между узлами. Для решения этой проблемы используют оптимизации, такие как уменьшение числа участвующих узлов, уменьшение объема передаваемых данных и применение асинхронных операций, когда это возможно.

Распределенные транзакции можно реализовать в Platform V Pangolin DB с использованием внешних транзакционных менеджеров или через встроенные механизмы, такие как Foreign Data Wrappers (FDW), которые позволяют Platform V Pangolin DB взаимодействовать с другими базами данных. Правда, FDW не поддерживают двухфазный коммит непосредственно. Потребуется еще использование внешних транзакционных менеджеров.

Инструменты и техники мониторинга

Мониторинг позволяет своевременно выявлять и устранять проблемы, которые влияют на производительность и целостность информации. Он помогает администраторам БД и разработчикам понять, как транзакции взаимодействуют с системой, выявлять узкие места и оптимизировать работу базы данных. В рамках мониторинга собирают сведения о времени выполнения групп операций, использовании ресурсов и возможных конфликтах. Это позволяет принимать обоснованные решения для оптимизации. В условиях высоконагруженных систем, где малейшие задержки могут приводить к значительным потерям производительности, мониторинг становится незаменимым инструментом.

Для решения этой задачи можно использовать внешние решения. Однако в Platform V Pangolin DB уже доступны такие инструменты, как системные представления и утилиты, которые представляют подробную информацию о состоянии транзакций и использовании ресурсов.

Представление pg_stat_activity позволяет отслеживать активные транзакции и их состояние. Оно дает информацию о текущих запросах, времени выполнения, блокировках и многом другом. Это позволяет администраторам оперативно реагировать на проблемы и оптимизировать работу базы данных.

Также можно настроить логирование долгих запросов с помощью параметра log_min_duration_statement. Это позволяет выявлять транзакции, которые занимают слишком много времени, и анализировать причины их замедления.

Для более глубокого анализа можно использовать специализированные инструменты, такие как pg_stat_statements. Этот модуль расширяет возможности мониторинга, предоставляет статистику по выполнению всех SQL-запросов, в том числе частоту, среднее время и другие метрики. 

Рассмотрим пример транзакции и мониторинга в Platform V Pangolin DB с использованием представления pg_stat_activity. Допустим, у нас возникает проблема с производительностью, и мы хотим выяснить, какие группы операций стали причиной замедления системы:

SELECT pid, username, state, query, wait_event, wait_event_type, query_start
FROM pg_stat_activity
WHERE state != 'idle';

Этот запрос позволяет получить информацию обо всех активных транзакциях, их состоянии и времени выполнения. Если мы обнаруживаем группы операций, которые выполняются слишком долго, можно использовать EXPLAIN ANALYZE для анализа плана выполнения запросов и выявления узких мест:

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123;

Еще один пример — использование модуля pg_stat_statements для анализа производительности всех запросов:

SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

Этот запрос позволяет определить самые ресурсоемкие запросы, которые могут быть причиной замедления системы. Анализируя эти данные, можно принимать меры по оптимизации запросов, индексированию и другим улучшениям.