Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

Привіт усім! Мене звати Назар, я — Node.js Engineer у компанії Yalantis, працюю на проєкті у сфері IoT.
Тема використання транзакцій в реляційних базах даних є ключовою для розуміння принципів забезпечення цілісності та консистентності даних у системах керування базами даних (СКБД). Розуміння теми дозволяє отримати знання основних принципів та практичного застосування транзакцій в реляційних базах даних, що може мати значний вплив на роботу з даними та розвиток програмного забезпечення.

У цій статті ми розглянемо сутність транзакцій та їхні властивості.

Що таке транзакція

Транзакція у реляційних базах даних — це логічна одиниця роботи, яка об’єднує одну чи кілька операцій з базою даних. Вона має чотири ключові властивості, які визначають її поведінку: атомарність, консистентність, ізоляцію та тривалість (ACID).

У багатьох реляційних базах даних, як-от PostgreSQL, MySQL, Oracle, є можливість використання транзакцій через мову запитів.

SQL

BEGIN TRANSACTION;
-- Виконання операцій з базою даних
COMMIT; -- Підтвердження транзакції
-- АБО
ROLLBACK; -- Скасування транзакції

Якщо розглядати транзакції за допомогою різних ORM:

Typeorm

// використовуємо DataSource або EntityManager:
await myDataSource.manager.transaction(async (transactionalEntityManager) => {
  await transactionalEntityManager.save(users)
  await transactionalEntityManager.save(photos)
  // ...
});
// або QueryRunner:
const queryRunner = dataSource.createQueryRunner();
// нова транзакція:
await queryRunner.startTransaction()
try {
  // виконати деякі операції над цією транзакцією:
  await queryRunner.manager.save(options)
  // Фіксуємо транзакцію:
  await queryRunner.commitTransaction()
} catch (err) {
  // якщо у нас є помилки, відкотимо внесені зміни
  await queryRunner.rollbackTransaction()
}

Sequelize

// Спочатку ми запускаємо транзакцію з з'єднання і зберігаємо її в змінну
const transaction = await sequelize.transaction();
try {
  // Потім ми робимо декілька викликів, що передають цю транзакцію як опцію:
  const user = await User.create({
    firstName: 'Bart',
    lastName: 'Simpson'
  }, { transaction });
  await user.addSibling({
    firstName: 'Lisa',
    lastName: 'Simpson'
  }, { transaction });
  // Якщо виконання дійшло до цього рядка, то помилок не було.
  // Фіксуємо транзакцію.
  await transaction.commit();
} catch (error) {
  // Якщо виконання дійшло до цього рядка, то виникла помилка.
  // Відкочуємо транзакцію.
  await transaction.rollback();
}

Управління транзакціями

Команди керування транзакціями

Команди управління транзакціями використовуються тільки з командами DML, як-от — INSERT, UPDATE та DELETE. Вони не можуть використовуватися під час створення таблиць або їх видалення, оскільки ці операції автоматично фіксуються в базі даних.

Команда COMMIT

Команда COMMIT — це транзакційна команда, що використовується для збереження змін, внесених транзакцією в базу даних. Команда COMMIT зберігає всі транзакції в базі даних з моменту виконання останньої команди COMMIT або ROLLBACK.

Синтаксис команди COMMIT такий:

COMMIT;

Нижче наведено приклад, в якому з таблиці будуть видалені клієнти з віком = 25, а потім ці зміни будуть збережені в базі даних.

DELETE FROM CUSTOMERS
WHERE AGE = 25;
COMMIT;

Команда ROLLBACK

Команда ROLLBACK — це транзакційна команда для скасування транзакцій, які ще не були збережені в базі даних. Ця команда може використовуватися тільки для скасування транзакцій з моменту виконання останньої команди COMMIT або ROLLBACK.

Синтаксис команди ROLLBACK наступний:

ROLLBACK;

Нижче наведено приклад, в якому з бази даних будуть видалені всі записи для яких вік = 25, а потім ці зміни будуть скасовані.

DELETE FROM CUSTOMERS
WHERE AGE = 25;
ROLLBACK;

Команда SAVEPOINT

SAVEPOINT — це точка транзакції, до якої ви можете повернути транзакцію, не відкочуючи її повністю. Синтаксис команди SAVEPOINT наведено нижче:

SAVEPOINT SAVEPOINT_NAME;

Ця команда призначена тільки для створення SAVEPOINT в інших транзакційних операторах. Команда ROLLBACK використовується для скасування групи транзакцій до точки SAVEPOINT.

Синтаксис, який використовується для повернення до SAVEPOINT:

ROLLBACK TO SAVEPOINT_NAME;

Нижче наведено приклад ситуації, коли ми плануємо видалити три різних записи з таблиці CUSTOMERS. Ми можемо створити SAVEPOINT перед кожним видаленням, щоб мати можливість відкотити операцію SAVEPOINT у будь-який час і повернути дані у вихідний стан.

Наступний блок коду містить ряд операцій:

SAVEPOINT SP1;
Savepoint created.
DELETE FROM CUSTOMERS WHERE ID=1;
1 row deleted.
SAVEPOINT SP2;
Savepoint created.
DELETE FROM CUSTOMERS WHERE ID=2;
1 row deleted.
SAVEPOINT SP3;
Savepoint created.
DELETE FROM CUSTOMERS WHERE ID=3;
1 row deleted.

Тепер, після того, як були виконані зміни, припустимо, що ви передумали і вирішили відкотити операцію до точки SAVEPOINT, яку ви визначили як SP2. Оскільки SP2 була створена після першого видалення, останні два видалення будуть скасовані:

ROLLBACK TO SP2;
Rollback complete.

Команда RELEASE SAVEPOINT

Команда RELEASE SAVEPOINT використовується для видалення створеної точки SAVEPOINT. Синтаксис команди RELEASE SAVEPOINT такий:

RELEASE SAVEPOINT <SAVEPOINT_NAME>;

Після того, як SAVEPOINT буде видалена, ви більше не зможете використовувати команду ROLLBACK для скасування транзакцій, виконаних після останньої SAVEPOINT.

Команда SET TRANSACTION

Команда SET TRANSACTION може використовуватися для ініціювання транзакцій бази даних, а також для визначення характеристик транзакцій, яка задається після команди. Наприклад, ви можете задати для транзакції режим тільки читання або читання і запис. Синтаксис команди SET TRANSACTION такий:

SET TRANSACTION [ READ WRITE | READ ONLY ];

Транзакції: основні концепції

Транзакція у реляційних базах даних — це група операцій, які виконуються як один блок. Вони мають чотири важливі властивості, об’єднані під акронімом ACID:

• Атомарність гарантує, що всі операції в транзакції виконуються повністю або жодна з них не застосовується, запобігаючи неприпустимим проміжним станам даних.
• Консистентність визначає, що база даних переходить з одного стану в інший, що відповідає внутрішнім правилам цілісності, забезпечуючи цілісність даних.
• Ізоляція гарантує, що результати однієї транзакції не впливають на результати інших паралельних транзакцій.
• Тривалість (довготривалість) підтверджує, що зміни, внесені транзакцією, є стійкими та зберігаються в базі даних навіть у разі відмови системи.

Проблема паралельного доступу

Існує така річ, як-от проблема паралельного доступу в системах керування базами даних (СКБД). Виникає, коли кілька транзакцій одночасно звертаються та змінюють одні й ті ж дані. Це може призвести до конфліктів, неправильних результатів чи навіть втрати цілісності даних.

Основні проблеми паралельного доступу:

1. Фантомне читання (Phantom Reads): ця проблема виникає, коли транзакція читає набір даних, які вже були змінені чи вставлені іншою транзакцією. Це може призвести до неправильних результатів та неконсистентності відображених даних.
2. Неповторювані читання (Non-Repeatable Reads): коли транзакція читає декілька разів одні й ті ж дані, інша транзакція в цей час вносить зміни, що призводить до того, що перше читання відрізняється від наступних, що може призвести до неконсистентності даних.
3. Втрати оновлень (Lost Updates): коли дві транзакції одночасно оновлюють одні й ті ж дані, одне з оновлень може бути втрачено через конфлікт. Наприклад, якщо обидві транзакції спробують змінити один рядок у базі, тільки одне оновлення може бути застосоване, а інше — втрачене.
4. Аномалії читання-запису (Read-Write Anomalies): це стосується ситуацій, коли транзакція читає дані, які одночасно змінюються іншими транзакціями, що призводить до нестійкості результатів операцій.

Розв’язання проблем паралельного доступу охоплює використання різних рівнів ізоляції транзакцій, де кожен рівень має свої особливості щодо блокування даних для забезпечення консистентності, а також розробку оптимізованих алгоритмів та стратегій доступу до даних для мінімізації конфліктів між транзакціями. Також важливо ретельно проєктувати бази даних та оптимізувати запити до даних для зменшення можливості виникнення конфліктів під час паралельного доступу до них.

Оптимізація використання транзакцій

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

Ось кілька підходів до оптимізації використання транзакцій:

1. Мінімізація тривалості транзакцій: мінімізувати час, протягом якого транзакція утримує блокування на ресурси бази даних. Це можна зробити, обмежуючи обсяг даних, з якими працює транзакція, та оптимізуючи запити до бази даних.
2. Мінімізація блокування ресурсів: використовуйте оптимізовані методи блокування, як-от READ COMMITTED чи REPEATABLE READ, які можуть зменшити конфлікти між транзакціями.
3. Оптимізація структури даних: навіть перед використанням транзакцій, потрібно переконатись, що структура даних та індекси оптимізовані для ефективного доступу та операцій.
4. Масштабування та реплікація: масштабування системи та використання реплікації для розділення навантаження та підвищення продуктивності.
5. Аналіз та моніторинг: аналіз та моніторинг використання транзакцій у системі, щоб виявляти можливі місця для оптимізації та вдосконалення продуктивності.

Кожна система має свої особливості, тому оптимізація використання транзакцій вимагає ретельного аналізу конкретної архітектури та потреб системи для досягнення найкращих результатів.

Рівні ізоляції транзакцій

Рівні ізоляції, як-от READ COMMITTED, REPEATABLE READ, SERIALIZABLE, визначають рівень видимості даних між різними транзакціями. Розуміння цих рівнів є ключовим для запобігання конфліктам та неправильним результатам у паралельних транзакціях.

Read committed — це рівень ізоляції, який надає певний баланс між консистентністю даних і ресурсоємністю системи, забезпечує дві основні гарантії. Перша — жодних брудних операцій читання (Dirty read). Це означає, що під час читання з бази даних клієнт бачить лише зафіксовані дані.

Тобто якісь середні, неузгоджені дані він не може прочитати. І друга гарантія — це жодних брудних операцій запису. Також дозволяє більшій кількості транзакцій працювати паралельно, але потребує уваги до можливості фантомного читання та потенційної нестабільності в деяких умовах. Вибір рівня ізоляції варто розглядати в контексті конкретних вимог вашої системи та важливості стійкості даних.

Основні принципи Read committed:

1. Короткий термін блокування: під час виконання Read committed транзакція блокує тільки ті рядки, які читає в поточний момент. Це означає, що інші транзакції можуть змінювати ті ж самі рядки, поки поточна транзакція читає дані, але не можуть внести зміни, поки поточна транзакція не закінчить свою роботу.
2. Попереднє блокування для змін: якщо транзакція має намір модифікувати певний рядок, вона заблокує його для змін у поточний момент. Це запобігає конфліктам між транзакціями, які намагаються змінити одні й ті ж рядки даних одночасно.
3. Читання поточних даних: транзакція, яка використовує рівень Read committed, читає тільки ті дані, які вже були закомічені (зафіксовані) і не блокуються для змін в момент читання.

REPEATABLE READ — це ще один рівень ізоляції транзакції забезпечує ситуацію, під час якої поточна трансакція завжди бачить дані в тому стані, у якому вони перебували на момент її старту.

Наприклад, якщо в нас є великі запити до яких вкладений величезний об’єм логіки за якої скануються багато таблиць або взагалі вся база даних, і якщо такі запити будуть бачити частину старих даних, а потім додавати частину нових, зрештою ми отримуємо різнобічні дані. У таких варіантах рівень Read committed не підходить, а для запобігання цим проблемам існує рівень ізоляції знімків стану — Snapshot isolation, який ще називають Repeatable read.

В режимі REPEATABLE READ кожна транзакція працює з фіксованою версією даних, відомою як узгоджений знімок (Consistent snapshot) стану бази. Це означає, що коли транзакція починає свою роботу, вона робить «зліпок» всіх даних у базі в певний момент часу і працює із цим набором даних протягом свого життєвого циклу. Навіть якщо під час роботи транзакції інші транзакції внесли зміни в дані, наша транзакція буде працювати з даними так, як вони були на момент її старту, і не побачить цих змін.

Основні принципи REPEATABLE READ:

1. Блокування на читання: транзакція, яка працює на рівні REPEATABLE READ, блокує рядки, які вона читає, до завершення всієї транзакції. Це запобігає будь-яким змінам даних, які можуть вплинути на результати читання протягом життєвого циклу транзакції.
2. Унікальне читання (non-repeatable reads): оскільки транзакція блокує рядки, які вона читає, це запобігає змінам цих даних з боку інших транзакцій, що гарантує те, що транзакція буде читати одні й ті ж дані протягом усього життєвого циклу.
3. Загальне блокування: якщо транзакція виконує операції на декількох рядках, вона блокує всі ці рядки до завершення транзакції, навіть якщо вона читає їх окремо.
4. Високий рівень ізоляції: REPEATABLE READ надає високий рівень ізоляції порівняно з «READ COMMITTED», оскільки блокує рядки для всього життєвого циклу транзакції.

SERIALIZABLE — це ще один рівень ізоляції транзакцій у базах даних, який забезпечує найвищий рівень стійкості даних та ізоляції між транзакціями.

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

Основні принципи SERIALIZABLE:

1. Строге блокування: цей рівень ізоляції застосовує найбільш жорстке блокування, що призводить до блокування всіх даних, до яких звертається транзакція, протягом усього її життєвого циклу.
2. Запобігання «фантомному читанню» та іншим аномаліям: транзакції на рівні SERIALIZABLE гарантують, що жодні нові рядки даних не з’являються під час їхнього виконання, запобігаючи «фантомному читанню» (Phantom read) та іншим аномаліям.
3. Високий рівень консистентності: цей рівень ізоляції дозволяє транзакціям працювати з даними у послідовності, яка відповідає їхньому порядку виконання.

Практичне використання

Приклад 1. Банківська транзакція

Клієнт переказує кошти з одного банківського рахунку на інший. Використання транзакцій в цьому разі є критично важливим, оскільки система повинна гарантувати, що кошти будуть або повністю переведені, або не будуть переведені взагалі. Така атомарність забезпечує цілісність фінансових даних клієнта.

BEGIN TRANSACTION;
UPDATE Рахунки SET Баланс = Баланс - 100 WHERE ID = 123; -- Зняти гроші з рахунку
UPDATE Рахунки SET Баланс = Баланс + 100 WHERE ID = 456; -- Переказати гроші на інший рахунок
COMMIT; -- Підтвердження транзакції
-- АБО
ROLLBACK; -- Скасування транзакції у випадку помилки

Приклад 2. Масове оновлення користувачів з неактивними підписками

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

async updateExpiredSubscriptions(): Promise<void> {
    const expiredSubscriptions = await SubscriptionService.getExpiredSubscriptions();
    
    if (expiredSubscriptions.length) {
      const transaction = await db.connector.transaction();
      try {
        await Promise.all(
          expiredSubscriptions.map((expiredSubscription) =>
            expiredSubscription.update({ status: 'expired' }, { transaction }),
          ),
        );
        await transaction.commit();
      } catch (err) {
        await transaction.rollback();
      }
    }
  }

Висновок

Транзакції у базах даних є невід’ємною складовою для забезпечення надійності та цілісності даних. Розуміння їхніх принципів та правильне використання допомагають підвищити ефективність та надійність системи в будь-якій сфері. Використання транзакцій в системах керування базами даних має свої переваги та недоліки, які варто враховувати під час проєктування та розробки програмного забезпечення.

Переваги використання транзакцій:

1. Забезпечення консистентності даних: транзакції дозволяють гарантувати, що зміни в базі даних відбуваються відповідно до визначених правил, забезпечуючи консистентність і цілісність даних.
2. Атомарність операцій: транзакції забезпечують атомарність, тобто операції виконуються або в повному обсязі, або не виконуються взагалі. Це запобігає втраті чи неправильним станам даних у разі помилок.
3. Ізоляція та паралельність: транзакційна ізоляція дозволяє кільком транзакціям працювати паралельно без взаємовпливу, що підвищує продуктивність та швидкодію системи.
4. Відновлення в разі відмови: транзакційні журнали та механізми анулювання дозволяють відновлювати стан бази даних до попередніх точок часу в разі виникнення помилок або відмов системи.

Недоліки використання транзакцій:

1. Блокування та конфлікти: часте використання транзакцій та блокування ресурсів може призводити до конфліктів та затримок у роботі системи.
2. Великий обсяг пам’яті: транзакційні системи можуть вимагати значних обсягів пам’яті та обчислювальних ресурсів для підтримки ізоляції та відновлення даних.
3. Накладні витрати на управління: підтримка транзакцій вимагає складних механізмів управління та журналізації, що може призводити до додаткових накладних витрат.
4. Можливість втрати продуктивності: неправильне використання транзакцій може призводити до втрати продуктивності через зайві блокування та обробку даних.

А також моніторинг та аудит транзакцій є важливими для виявлення проблем та відстеження змін у базі даних. Сюди входять відстеження виконання транзакцій, аналіз помилок та управління журналами транзакцій. Транзакції у базах даних є невід’ємною складовою для забезпечення надійності та цілісності даних. Розуміння їхніх принципів та правильне використання допомагають підвищити ефективність та надійність системи в будь-якій сфері.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті