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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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