Продолжаю серию постов про ACID
Раскроем буковку 🔤:
Consistency или согласованность (C) в контексте транзакций ACID гарантирует, что любая транзакция переведет базу данных из одного допустимого состояния в другое допустимое состояние, никогда не оставляя ее в поврежденном или «недопустимом» состоянии.
Это означает, что все ограничения целостности данных, такие как ограничения первичного ключа (отсутствие повторяющихся идентификаторов), ограничения внешнего ключа (связанные записи должны существовать в родительских таблицах) и проверочные ограничения (возраст не может быть отрицательным), удовлетворяются до и после транзакции.
Если транзакция попытается нарушить эти правила, она не будет зафиксирована, а база данных вернется в предыдущее состояние.
Пример:
В базе данных электронной коммерции есть две таблицы:
• products(со столбцами: product_id, stock_quantity и т.д.)
• orders(со столбцами: order_id, product_id, quantity и т.д.)
Ограничение : Вы не можете разместить заказ на товар, если quantity(кол-во в заказе) больше, чем указано stock_quantity(кол-во на складе) в таблице products - CHECK (stock_quantity >= 0) или через триггер.
Транзакция:
BEGIN TRANSACTION;
INSERT INTO orders (product_id, quantity)
VALUES (101, 10);
-- Next, try to decrement stock from the products table
UPDATE products
SET stock_quantity = stock_quantity - 10
WHERE product_id = 101;
-- Check constraint: If 'stock_quantity' goes below 0, this violates the rule.
COMMIT;
Если у товара stock_quantity было 8 (меньше, чем то, что мы пытаемся заказать), то СУБД видит, что новое значение будет -2, что нарушает правило согласованности (оно не должно быть отрицательным).
Транзакция завершается неудачей и инициируется откат.
Еще пример:
Например, пользователь в системе заполняет карточку: ФИО, Дата рождения, ИНН, Телефон(отдельно код страны, города и номер), Адрес(тоже разбит на несколько полей).
В базе данных у нас есть несколько таблиц: client, phone, address
Так что когда пользователь заполнил форму и нажал «сохранить», система отправляет в базу данных 3 запроса:
insert into client… -- вставить в таблицу клиентов такие-то данные
insert into phone…
insert into address…
Можно отправить 3 разных запроса, но лучше сделать одну транзакцию, внутри которой будут эти 3 запроса.
Атомарность гарантирует, что не получится такого, что адрес с телефоном сохранились, а сам клиент — нет. Это сделало бы базу неконсистентной, ведь у нас бы появились атрибуты, «висящие в воздухе», никому не принадлежащие. Что, в свою очередь, приведет к ошибкам в системе.
❗️Важный момент. За консистентностью должен следить разработчик. Ведь это вопрос скорее бизнес-логики, чем технологий. Разработчик знает, что:
✅если есть телефон в таблице phone, то он должен ссылаться на таблицу client
База об этом не знает ничего, если ей не рассказать. И она легко пропустит запрос «добавь в базу телефон без ссылки на клиента», если сам по себе запрос корректный, а разработчик не повесил на таблицу foreign key.
Разработчик пишет код, пошагово переводящий БД в нужное согласованное состояние и, если где-то посередине возникает ошибка,то откатывает всю транзакцию.
Как реализовать согласованность:
1. Ограничения схемы базы данных
➖ Ограничения NOT NULL , UNIQUE , PRIMARY KEY , FOREIGN KEY , CHECK и другие определения схемы гарантируют, что недопустимые записи не допускаются.
2. Триггеры и хранимые процедуры
➖ Триггеры могут автоматически проверять дополнительные правила при каждой вставке, обновлении или удалении строк.
➖ Хранимая процедура может содержать логику для проверки данных перед их фиксацией.
3. Защитные меры на уровне приложений
➖ В то время как база данных обеспечивает соблюдение ограничений на более низком уровне, приложения часто добавляют дополнительные проверки, например, обеспечивают соблюдение бизнес-правил или проверяют данные еще до того, как они попадут на уровень базы данных.
➖➖➖➖➖➖➖➖➖➖➖➖
Согласованность тесно связана с уровнями изоляции транзакций, о чем расскажу дальше..
it пингвин | data engineer 🐧
#Вопросы_с_собесов #архитектура #acid
Раскроем буковку 🔤:
Consistency или согласованность (C) в контексте транзакций ACID гарантирует, что любая транзакция переведет базу данных из одного допустимого состояния в другое допустимое состояние, никогда не оставляя ее в поврежденном или «недопустимом» состоянии.
Это означает, что все ограничения целостности данных, такие как ограничения первичного ключа (отсутствие повторяющихся идентификаторов), ограничения внешнего ключа (связанные записи должны существовать в родительских таблицах) и проверочные ограничения (возраст не может быть отрицательным), удовлетворяются до и после транзакции.
Если транзакция попытается нарушить эти правила, она не будет зафиксирована, а база данных вернется в предыдущее состояние.
Пример:
В базе данных электронной коммерции есть две таблицы:
• products(со столбцами: product_id, stock_quantity и т.д.)
• orders(со столбцами: order_id, product_id, quantity и т.д.)
Ограничение : Вы не можете разместить заказ на товар, если quantity(кол-во в заказе) больше, чем указано stock_quantity(кол-во на складе) в таблице products - CHECK (stock_quantity >= 0) или через триггер.
Транзакция:
BEGIN TRANSACTION;
INSERT INTO orders (product_id, quantity)
VALUES (101, 10);
-- Next, try to decrement stock from the products table
UPDATE products
SET stock_quantity = stock_quantity - 10
WHERE product_id = 101;
-- Check constraint: If 'stock_quantity' goes below 0, this violates the rule.
COMMIT;
Если у товара stock_quantity было 8 (меньше, чем то, что мы пытаемся заказать), то СУБД видит, что новое значение будет -2, что нарушает правило согласованности (оно не должно быть отрицательным).
Транзакция завершается неудачей и инициируется откат.
Еще пример:
Например, пользователь в системе заполняет карточку: ФИО, Дата рождения, ИНН, Телефон(отдельно код страны, города и номер), Адрес(тоже разбит на несколько полей).
В базе данных у нас есть несколько таблиц: client, phone, address
Так что когда пользователь заполнил форму и нажал «сохранить», система отправляет в базу данных 3 запроса:
insert into client… -- вставить в таблицу клиентов такие-то данные
insert into phone…
insert into address…
Можно отправить 3 разных запроса, но лучше сделать одну транзакцию, внутри которой будут эти 3 запроса.
Атомарность гарантирует, что не получится такого, что адрес с телефоном сохранились, а сам клиент — нет. Это сделало бы базу неконсистентной, ведь у нас бы появились атрибуты, «висящие в воздухе», никому не принадлежащие. Что, в свою очередь, приведет к ошибкам в системе.
❗️Важный момент. За консистентностью должен следить разработчик. Ведь это вопрос скорее бизнес-логики, чем технологий. Разработчик знает, что:
✅если есть телефон в таблице phone, то он должен ссылаться на таблицу client
База об этом не знает ничего, если ей не рассказать. И она легко пропустит запрос «добавь в базу телефон без ссылки на клиента», если сам по себе запрос корректный, а разработчик не повесил на таблицу foreign key.
Разработчик пишет код, пошагово переводящий БД в нужное согласованное состояние и, если где-то посередине возникает ошибка,то откатывает всю транзакцию.
Как реализовать согласованность:
1. Ограничения схемы базы данных
➖ Ограничения NOT NULL , UNIQUE , PRIMARY KEY , FOREIGN KEY , CHECK и другие определения схемы гарантируют, что недопустимые записи не допускаются.
2. Триггеры и хранимые процедуры
➖ Триггеры могут автоматически проверять дополнительные правила при каждой вставке, обновлении или удалении строк.
➖ Хранимая процедура может содержать логику для проверки данных перед их фиксацией.
3. Защитные меры на уровне приложений
➖ В то время как база данных обеспечивает соблюдение ограничений на более низком уровне, приложения часто добавляют дополнительные проверки, например, обеспечивают соблюдение бизнес-правил или проверяют данные еще до того, как они попадут на уровень базы данных.
➖➖➖➖➖➖➖➖➖➖➖➖
Согласованность тесно связана с уровнями изоляции транзакций, о чем расскажу дальше..
it пингвин | data engineer 🐧
#Вопросы_с_собесов #архитектура #acid