ASP.NET OLTP App - создание новой версии записей

Question

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

Я ищу лучшее решение / дизайн для реализации такого сценария.

1. Есть ли лучший способ сохранить "версии" одной и той же записи, особенно когда она создает слишком много дубликатов в нескольких таблицах
2. Я не чувствую, что дизайн сам по себе хорош, так как слишком много записей вставляется для «каждой версии строки», но, по крайней мере, хотел бы решить насущную проблему, «длительную транзакцию», которая иногда вызывает задержку. Возможно, выхода не может быть, но я все еще хотел спросить: если я не помещаю «управление версиями» внутри транзакции, есть ли лучший способ отката в случае ошибки (поскольку транзакция блокирует другие OLTP? запросы - из-за вставки новых версий во все первичные таблицы)

Запрос на управление версиями сейчас выполняется около 10 секунд, но иногда ухудшается. Любые мысли приветствуются

Answer 1

Нужно ли возвращать сообщение «создано» или «не удалось» в режиме реального времени?Следующее также может быть излишним для вашего решения, но оно создает масштабируемое решение.

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

Если вы можете справиться с обработкой, разделенной практически в реальном времени, вы можете изменить свою службу Windows для масштабирования.Вы можете иметь пул потоков для управления запросами - поэтому, возможно, у вас есть только 5 потоков, работающих одновременно, чтобы ограничить нагрузку.Если вы столкнетесь с большим количеством проблем с производительностью, вы можете уменьшить масштаб и разработать систему, которая может иметь 2 или более процессора в очереди (что добавляет свои проблемы / сложность).