Когда транзакции становятся больше бременем, чем выгодой?

Question

Транзакционное программирование в наше время является основой современного развития. Параллельность и отказоустойчивость имеют решающее значение для долговечности приложений, и справедливо, что транзакционная логика стала легко реализуемой. Однако по мере роста приложений кажется, что транзакционный код становится все более обременительным для масштабируемости приложения, и когда вы подключаетесь к распределенным транзакциям и зеркальным наборам данных, проблемы начинают становиться очень сложными. Мне любопытно, в чем заключается смысл, с точки зрения размера данных или сложности приложения, что транзакции часто начинают становиться источником проблем (вызывающих таймауты, взаимные блокировки, проблемы с производительностью в критически важном коде и т. Д.), Которые более утомительно исправлять, устранять неполадки или обходной путь, чем разработка модели данных, которая сама по себе более отказоустойчива, или использование других средств для обеспечения целостности данных. Кроме того, какие шаблоны проектирования служат для минимизации этих воздействий или для того, чтобы сделать стандартную транзакционную логику устаревшей или неиспользованной?

-

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

Еще одно важное замечание: не все тупики являются результатом плохо закодированных процедур; иногда существуют критически важные операции, которые зависят от схожих ресурсов в разных порядках, или сложные объединения в разных запросах, которые накладываются друг на друга; это проблема, которая иногда может показаться неизбежной, но я участвовал в доработке рабочих процессов, чтобы упростить порядок выполнения, который с меньшей вероятностью может его вызвать.

Answer 1

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

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

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

Answer 2

Я думаю, что ни один шаблон проектирования не может решить эту проблему сам по себе. Хороший дизайн базы данных, хорошее программирование процедур магазина и особенно обучение тому, как сделать ваши транзакции короткими, облегчат большинство проблем. Не существует 100% гарантированного способа избежать проблем.

Практически во всех случаях, которые я видел в своей карьере, тупики и замедления решались путем исправления хранимых процедур:

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

Answer 3

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

Я также знаю, что некоторые решения, такие как FogBugz, не используют принудительные внешние ключи, что, как я считаю, также поможет смягчить некоторые из этих проблем, поскольку план запросов SQL может блокировать связанные таблицы во время операций выбора или обновления, даже если нет данных меняется в них, и если заблокированная таблица с высокой конкуренцией может увеличить вероятность DeadLock или Timeout.

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

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

Answer 4

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

Общее правило - блокировать ресурс как можно дольше. Используя T-SQL, PLSQL, Java в Oracle или любым другим аналогичным способом, вы можете сократить время, в течение которого каждая транзакция блокирует общий ресурс. Фактически, транзакции в базе данных оптимизируются с помощью блокировок на уровне строк, мульти-версий и других интеллектуальных методов. Если вы можете сделать транзакцию в базе данных, вы сохраните сетевую задержку. Помимо других слоев, таких как ODBC / JDBC / OLEBD.

Иногда программист пытается получить хорошие качества базы данных (она транзакционная, параллельная, распределенная), но хранит кэш данных. Затем им нужно вручную добавить некоторые функции базы данных.

Answer 5

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

Нет необходимости в согласованности всего облака, так как это снизит производительность (как вы заметили). Просто следите за тем, что изменилось и где, и обрабатывайте несколько небольших транзакций, когда изменения распространяются через систему.

Ситуация, когда пользователь A обновляет запись R, а пользователь B на другом конце облака не видит ее (пока), такая же, как и ситуация, когда пользователь A еще не внес изменения в текущей среде строгих транзакций. , Это может привести к расхождению в системе с большими объемами обновлений, поэтому системы следует проектировать так, чтобы они работали с обновлениями как можно меньше - перемещая объекты к агрегации данных и вытягивая агрегаты, как только точная цифра становится критической (т. Е. Перемещается требование согласованности от времени записи до критического времени чтения).

Ну, просто мой POV. В этом случае сложно представить систему, которая не зависит от приложения.