Есть ли недостатки у транзакций?

Question

[Михаил]

Есть ли какие то минусы при использовании транзакций в базах данных?

Answer 1

[Дмитрий Энтелис]

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

А почему так происходит?

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

Comments

[Артём Каретников]

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

[footballer]

Непосредственно от внедрения транзакций ничего медленнее работать не начинает.

Почему не начинает, если еще дополнительно к изменению данных нужно записывать и читать логи об изменении данных?

если выставлены жесткие настройки сохранения на диск

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

[Дмитрий Энтелис]

footballer: Отвечу цитатой из дока

If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1 (the default), the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file. When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.

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

Смысл транзакции в том, что транзакция не может исполниться (и соответствнно записаться на диск) частично. Она или выполнится целиком, или целиком сфейлится.

Answer 2

[ТёмнаяМатерия]

Настоящие транзакции надо сразу сбрасывать на диск, на примере innodb производительность падает приблизительно в 100-200 раз при такой настройке

Comments

[Михаил]

А почему так происходит?