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

Question

С этот пост . Одна очевидная проблема - масштабируемость / производительность. Какие еще проблемы будут вызывать использование транзакций?

Не могли бы вы сказать, что существует два набора проблем: одна для длительных транзакций и одна для коротких? Если да, как бы вы их определили?

РЕДАКТИРОВАТЬ: тупик является еще одной проблемой, но несоответствие данных может быть хуже, в зависимости от области приложения. Если предположить, что домен, пригодный для транзакций (банковский, если использовать канонический пример), возможность взаимоблокировки больше похожа на затраты на обеспечение согласованности данных, чем на проблему с использованием транзакций, или вы не согласитесь? Если да, то какие другие решения вы бы использовали для обеспечения согласованности данных, которые без тупиков?

Answer 1

Это во многом зависит от реализации транзакций внутри вашей базы данных, а также может зависеть от уровня изоляции транзакций, который вы используете. Я предполагаю «повторяемое чтение» или выше здесь. Удержание транзакций в течение длительного времени (даже если они ничего не изменили) заставляет базу данных удерживать удаленные или обновленные строки часто меняющихся таблиц (на случай, если вы решите их прочитать), которые в противном случае могли бы быть отброшены.

Кроме того, откат транзакций может быть очень дорогим. Я знаю, что в движке MySQL InnoDB откат большой транзакции может занять FAR дольше, чем ее принятие (мы видели, что откат занял 30 минут).

Другая проблема связана с состоянием соединения с базой данных. В распределенном отказоустойчивом приложении вы никогда не сможете по-настоящему узнать, в каком состоянии находится соединение с базой данных. Соединения с базой данных с сохранением состояния не могут быть легко поддержаны, поскольку в любой момент они могут перестать работать (приложение должно помнить, в каком оно было состоянии). середина делает это и переделывает это). Те, которые не имеют состояния, могут быть просто переподключены, и их (атомарная) команда будет повторно выдана без (в большинстве случаев) прерывистого состояния.

Answer 2

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

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

Answer 3

Одна проблема с транзакциями состоит в том, что возможно (маловероятно, но возможно) получить взаимоблокировки в БД. Вы должны понимать, как ваша база данных работает, блокирует, проводит транзакции и т. Д., Чтобы отладить эти интересные / расстраивающие проблемы.

-Adam

Answer 4

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

Например, я мог бы:

• Создание транзакций внутри хранимых процедур,
• Использование API доступа к данным (ADO.NET) для управления транзакциями
• Использовать некоторую форму неявного отката выше в приложении
• Распределенная транзакция в (через DTC / COM +).

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