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

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

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

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

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

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

До сих пор вот мои размышления:

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

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

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

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

Спасибо!

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

Лучшая статья с примерами, которые я прочитал. Вы должны прочитать, это разъясняет, что вы спрашиваете. https://dzone.com/articles/cache-vs-session-store