Транзакции и ACID
Тема дорожной карты · Backend разработчик
Транзакции баз данных — механизм, посредством которого база данных гарантирует, что группа связанных SQL-операций либо выполняется целиком, либо не выполняется вовсе, сохраняя целостность данных через четыре свойства ACID: атомарность, согласованность, изоляция и долговечность. В PostgreSQL и MySQL транзакция ограничивается BEGIN (или START TRANSACTION), следующими за ним операторами INSERT, UPDATE или DELETE и завершается COMMIT для сохранения всех изменений или ROLLBACK для их отмены — например, дебетование одного банковского счёта и кредитование другого должны быть обёрнуты в единую транзакцию для предотвращения исчезновения денег при сбое между двумя операторами. Свойство изоляции имеет четыре уровня, определённых стандартом SQL: READ UNCOMMITTED, READ COMMITTED (по умолчанию в PostgreSQL), REPEATABLE READ (по умолчанию в MySQL InnoDB) и SERIALIZABLE — каждый предлагает более сильные гарантии против аномалий конкурентности (грязное чтение, неповторяемое чтение, фантомное чтение) ценой снижения пропускной способности из-за блокировок или накладных расходов MVCC-снимков. Транзакции в ORM обрабатываются через абстракции: sequelize.transaction(async t => { ... }) в Node.js Sequelize, db.session.begin() в SQLAlchemy, аннотация @Transactional в Spring Data JPA и явные блоки transaction в ActiveRecord. Распределённые транзакции через несколько микросервисов не могут использовать единую транзакцию базы данных; вместо этого паттерн Saga с компенсирующими транзакциями или протоколы двухфазной фиксации (через XA-транзакции) применяются для достижения итоговой согласованности в экземплярах PostgreSQL, MySQL или SQLite.
Как это работает
Транзакции и ACID используют ACID-транзакции, декларативный SQL, реляционную схему. PostgreSQL — современный дефолт для новых проектов (богатая типизация, JSON-поддержка, расширения, MVCC); MySQL/MariaDB всё ещё распространён (legacy + WordPress); SQLite — для маленьких single-host (удивительно мощный); CockroachDB / YugabyteDB — для распределённого SQL. Стратегия индексов, план запроса (EXPLAIN), connection pooling — операционные основы. Миграции через Alembic, Flyway, Liquibase или фреймворк-специфичные тулы.
Когда применять
Postgres по умолчанию для любого нового проекта — широкий feature set, зрелая эксплуатация, JSON и full-text встроены. MySQL — только если команда или хостинг уже на нём. SQLite — для embedded или первых 10к юзеров (буквально — масштабируется дальше, чем думают). Distributed SQL (Cockroach, Yugabyte, TiDB) — только когда переросли primary-replica Postgres; эта точка гораздо дальше, чем продают вендоры.
Типичные ошибки
Ловушки Транзакции и ACID: пропущенные индексы на колонках в WHERE / JOIN (один медленный запрос валит БД); N+1 паттерны от ORM (eager-load явно); долгие транзакции держат локи (делите на меньшие записи); не анализируете план запросов перед деплоем (EXPLAIN ANALYZE); pool соединений мал или велик (начните с max_connections / replica_count, тюньте по наблюдениям).