Длинные транзакции большого объема плохие

Question

Алло,

Я пишу приложение для базы данных, которое выполняет множество вставок и обновлений с поддельным serialisable уровнем изоляции (snapshot isolation).

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

Наличие больших транзакций должно быть хорошо для WAL, потому что он может сбрасывать большие куски и не должен сбрасывать для мини-транзакций.

1.) Я вижу только положительный эффект от крупной сделки. Но я часто читаю, что они плохие. Почему они могут быть плохими в моем случае использования?

2.) Сколько стоит проверка конфликтов, когда local snapshots объединяется с реальной базой данных? База данных должна будет сравнить все наборы записи возможных конфликтов (параллельная транзакция). Или это делает какой-то высокоскоростной ярлык? Или это все равно довольно дешево?

[ РЕДАКТИРОВАТЬ ] Может быть интересно, если кто-то может внести некоторую ясность в то, как база данных изоляции моментальных снимков проверяет, проверяются ли транзакции, имеющие перекрывающиеся части на временной шкале, на несвязанные наборы записи. Потому что это то, что является ложным сериализуемым уровнем изоляции.

Answer 1

Реальные проблемы здесь в два раза.Первая возможная проблема - раздувание.Крупные транзакции могут привести к появлению множества мертвых кортежей одновременно.Другая возможная проблема связана с длительными транзакциями.Пока выполняется длинная транзакция, таблицы, к которым она прикасается, не могут быть очищены пылесосом, поэтому можно собирать и много мертвых кортежей.

Я бы сказал, просто используйте check_postgresql.pl для проверки на вздутие живота.Пока вы не видите много раздувания таблиц после длинных транзакций, все в порядке.

Answer 2

1) В инструкции сказано, что это хорошо: http://www.postgresql.org/docs/current/interactive/populate.html

Я также могу порекомендовать использовать COPY, удалить индексы (но сначала проверить), увеличить maintenance_work_mem, увеличить checkpoint_segments, запустить ANALYZE (или VACUUM ANALYZE) впоследствии.

Я не буду рекомендовать, если вы не уверены: удалить ограничения внешнего ключа, отключить архивирование WAL и потоковую репликацию.

2) Всегда данные объединяются при фиксации, но нет никаких проверок, данные просто записываются. Прочитайте еще раз: http://www.postgresql.org/docs/current/interactive/transaction-iso.html

Если ваши вставки / обновления не зависят от других вставок / обновлений, вам не нужно «полностью согласованное представление». Вы можете использовать чтение зафиксировано, и транзакция никогда не завершится неудачей.