Comments 9
Сразу бросилось в глаза непонимание Consistency. Как раз-таки между шагами транзакции согласованность может нарушаться. Она не должна быть нарушена перед началом транзакции и после окончания транзакции. А то, что в вашем примере - это просто срабатывание логики constraints на уровне БД
Говорит нам о том, что все данные которые записаны уже выполненной транзакцией, не будут отменены. Условно выключили свет, пропал интернет, на данные которые записаны уже завершенной транзакцией, это никак не должно повлиять.
Не понял - вот какое отношение это имеет к ТРАНЗАКЦИИ? Транзакция зафиксирована и завершилась. Дальше - обеспечение сохранения изменённого состояния данных,- не забота транзакции, это проблема программного и аппаратного обеспечения сервера БД, которые обязаны вовремя и правильно сохранить новое состояние данных на носитель.
И очень хочется надеяться, что опечатки в тексте - не следствие безграмотности. Исправьте орфографию, пожалуйста.
Интернеты говорят, что вы не правы. В плане, что везде написано практически то же самое, что в статье. Я не эксперт, но предполагаю, что это часть требований именно к аппаратной части по реализации транзакции.
Ну тут одно из двух - либо по интернету все таскают одну неправильно сказанную или неправильно переведённую фразу, или вы что-то не так поняли.
Подумайте сами. Транзакция зафиксирована и завершена. Проходит неделя. Вырубается свет. От этого накрывается хард, и записанные данные исчезают. Вы правда начнёте кивать на то, что реализация транзакции не проявила требования надёжности?
Забота транзакции о надёжности заканчивается в тот момент, когда она положила изменённые данные в кэш и сообщила, что завершила работу. То есть когда завершилось выполнение оператора COMMIT, и управление передано следующему оператору SQL кода. Пропавшие после этого данные, скажем. по причине того, что ОС не сбросила кэши на диск при аварийной ситуации, никак не делают транзакцию ненадёжной, это не её зона ответственности.
Забота транзакции о надёжности заканчивается в тот момент, когда она положила изменённые данные в кэш и сообщила, что завершила работу
Нет, конечно же. Транзакция (с настройками по умолчанию) считается завершённой когда накопитель отчитался что записал данные. И эти операции сериализуются, так что TPS на пишущих транзакция ограничен сверху IOPS на синхронной записи в имеющейся дисковой подсистеме (а в случае HDD это значение IOPS будет примерно равно оборотам диска, то есть для 7200 RPM у нас будет примерно 120 IOPS и в пределах 120 TPS соответственно).
Поэтому для БД были актуальны raid с bbwc, а сейчас актуальны dc ssd — за счёт наличия механизма plp они могут отчитаться о завершении записи сразу после того, как данные попали в буфер.
Хотите больше информации — гуглите «имя_любимой_бд fsync».
P.S. раз мы про постгрес, в комплекте идёт pg_test_fsync для тестирования производительности синхронной записи.
Транзакция (с настройками по умолчанию) считается завершённой когда накопитель отчитался что записал данные.
Давайте уточним - вот этот процесс записи накопителем данных является составной частью транзакции или внешним (асинхронным, и в общем даже независимым) процессом? а если первое - то не имеем ли мы в виду два совершенно разных понятия, именуемых одним и тем же словом "транзакция", где моё понимание является всего лишь составной частью вашего?
Транзакции PostgreSQL, Требования ACID, примеры. Подготовка к собеседованию, изучение