Что такое хороший способ хранить большие временные "сеансовые" данные в веб-приложении

Question

У моей компании есть сторонний веб-сервис, для которого мы разрабатываем интерфейс. «Объекты», используемые этим веб-сервисом, очень велики (и варьируются в зависимости от количества созданных дочерних объектов). Веб-сервис не предоставляет методы для фиксации / загрузки дочерних объектов, только полная иерархия объектов.

Сам пользовательский интерфейс разделен на множество вспомогательных экранов и основных / подробных видов, чтобы иметь возможность эффективно / легко редактировать большой объем данных.

Проблема в том, где хранить все данные, которые вы в данный момент не просматриваете.

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

Как уже упоминалось, данные могут быть довольно большими (от нескольких мегабайт до, возможно, гигабайта данных в крайних случаях)

Это для ASP.Net 4.0 с серверной частью MS-SQL и сторонней веб-службой SOAP.

Изменение контракта на веб-сервис не допускается.

Вот некоторые идеи, которые у нас были. Помогите мне выбрать или определить что-то лучшее!

1) Первоначальный разработчик бросил сериализованный XML в сеанс (сеанс на компьютере). Я быстро определил это как проблему, так как использование сессии таким образом может существенно повлиять на производительность из-за занимаемой памяти, а также из-за проблем с балансировкой нагрузки и т. Д.

2) Сервер сеансов - возможно, но для этого, вероятно, не требуется дополнительная покупка оборудования

3) Сеанс SQL - Производительность хранения такого большого объекта?

4) Записать XML на диск / общий ресурс (в архиве?)

5) Запись XML в SQL (в архиве?)

6) Реляционная база данных SQL - создавайте таблицы для каждого типа сущности. Это позволило бы загружать / сохранять отдельные объекты, что может быть очень важно для производительности. Мы беспокоимся о хрупкости и обслуживании, поскольку не контролируем сторонние сервисы (хотя в любом случае у нас эта проблема действительно существует, поскольку графический интерфейс также будет хрупким)

7) viewstate - слишком большой, идеальный хит

Answer 1

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

Вам также может быть интересно узнать о хранилищах данных, отличных от SQL.Хранилище данных без схемы или на основе документов может сократить ваши расходы на обслуживание, но при этом позволит вам хранить всю модель целиком и извлекать ее фрагменты на основе запросов по факту.