Хранение данных в памяти: сессия против кеша против статики

Question

Немного предыстории: я работаю над веб-приложением, которому требуется довольно много времени для подготовки / обработки данных, прежде чем предоставить их пользователю для редактирования / манипулирования. Задача запроса данных ~ 15/20 секунд для завершения и несколько секунд для обработки. Оказавшись там, пользователь может манипулировать vaules на лету. Любая манипуляция значениями потребует полной обработки данных.

Обновление: чтобы избежать путаницы, я делаю вызов данных только 1 раз (удар 15 секунд), а затем хочу сохранить результаты в памяти, чтобы мне не пришлось вызывать его снова, пока пользователь не выполнит 100% работая с этим. Итак, первая попытка займет некоторое время, но, используя Ajax, я собираюсь попасть в данные в памяти, чтобы постоянно обновлять и поддерживать время отклика около 2 секунд или около того (я надеюсь).

Чтобы сделать это эффективным, я перемещаю исходные данные в память и использую обратные вызовы Ajax на сервер, чтобы я мог сократить время обработки для обработки пересчета, который происходит с обновлениями этого пользователя.

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

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

Пока вот мои размышления:

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

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

Статика - Плюсы: Лучший Перф. Легко поддерживать, поскольку я могу напрямую использовать свои текущие классовые структуры. Минусы: нет простого отказоустойчивого шага, кроме записи, основанной на временных интервалах. Глобальный по объему - должен будет гарантировать, что пользователи не сталкиваются с работой друг друга.

Есть ли у кого-нибудь какие-либо предложения / комментарии по поводу того, какой вариант я должен выбрать?

Спасибо!

Обновление: забыл упомянуть, я использую VB.Net, Asp.Net и Sql Server 2005 для выполнения этой задачи.

Answer 1

Я проголосую за секретный вариант № 4: используйте базу данных для этого. Если вы говорите о времени обработки данных более 20 секунд, вы не получите ничего, пытаясь сделать это в памяти, учитывая ограничения представленных вами вариантов. Вы могли бы также установить это в базе данных (дать ей собственную таблицу или даже отдельную базу данных, если требования настолько велики).

Answer 2

Одной из возможных альтернатив тому, что упоминали другие, является хранение данных на клиенте. Предполагая, что набор данных не слишком велик, и код, который управляет им, может обрабатываться на стороне клиента. Вы можете хранить данные в виде острова данных XML или объекта JSON. Эти данные могут затем обрабатываться / обрабатываться и обрабатываться на всей клиентской стороне без каких-либо обращений к серверу. Если вам нужно сохранить эти данные обратно на сервер, конечные результирующие данные могут быть отправлены через AJAX или стандартную обратную передачу.

Если это не работает с вашими требованиями, я бы просто сохранил его на сервере SQL, как и предлагалось в другом комментарии.

Answer 3

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

Для отслеживания изменений, сделанных пользователем, я бы выбрал более старый подход: добавляйте текстовый файл каждый раз, когда пользователь вносит изменения, а затем периодически просматривайте этот файл, чтобы сохранить изменения обратно в БД. Если вы называете файлы, основываясь на имени пользователя / учетной записи или каком-либо другом уникальном для сеанса индикаторе, проблем с конфликтом не возникает, и приложение (или какое-либо другое приложение поддержки, которое может быть лучше в целом) может выполнять поиск по всем таким файлам обновить БД, даже если сеанс окончен.

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

Answer 4

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

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

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

Answer 5

Я думаю, что вы в значительной степени только что ответили на свой вопрос с плюсами / минусами. Но если вы ищете подтверждение со стороны коллег, мой голос за сессию. Хотя производительность ниже (вы знаете, насколько она медленнее?), Ваша обработка займет много времени независимо. Как вы думаете, пользователь будет знать разницу между 15 секундами и 17 секундами? Оба термина «навсегда» в веб-терминах, поэтому воспользуйтесь тем, который проще всего реализовать.

возможно, немного не по теме. Я бы рекомендовал размещать эти длинные вызовы обработки на асинхронных (не путать с асинхронными) страницах AJAX.

Взгляните на эту статью и отзовитесь, если она не имеет смысла.

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

Answer 6

Используйте сессию, но не полагайтесь на нее.

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

Вы не можете полагаться на сеанс просто потому, что он (как правило) привязан к экземпляру браузера пользователя. Если они случайно закрывают браузер (нажимают кнопку X, происходит сбой их ПК и т. Д.), Они теряют всю свою работу. Что было бы противно.

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