DAL, сессия, архитектура кэша

Я пытаюсь создать уровень доступа к данным для моего веб-приложения. В настоящее время все таблицы данных хранятся в сеансе. Когда я закончу, DAL заполнит и вернет таблицы данных. Хорошо ли хранить возвращенные таблицы данных в сеансе? Распределенный / общий кэш? Или просто пинговать базу данных каждый раз? Примечание: обычно число строк в datatable будет небольшим

Дополнительная информация:

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

Подробнее: Количество одновременно работающих пользователей ~50,000

Важная информация: В 99% случаев у двух пользователей не будет одинаковых данных / запросов, однако один и тот же пользователь может выполнить один и тот же запрос/получить одни и те же данные несколько раз. раз.

Спасибо

4 2
c# architecture data-access-layer

4 ответа:

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

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

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

Очень просто пример выборки по требованию: 

T GetCached<T>(string cacheKey, Func<T> getDirect) {
    object value = HttpContext.Current.Cache.Item(cacheKey);
    if(value == null) {
        value = getDirect();
        HttpContext.Current.Cache.Insert(cacheKey, value);
    }
    return (T) value;
}

EDIT: - обновление вопроса

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

Cache vs Session state server - у меня нет данных для резервного копирования, поэтому, пожалуйста, скажите так, если я ошибся, но я бы подумал, что кэширование данных независимо друг от друга в памяти каждого физического сервера домен приложений будет масштабироваться лучше, чем хранить его в общей службе состояния сеанса.

4

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

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

И в отношении опции распределенного кэша я предлагаю вам проверить http://memcached.org . Распределенный кэш, используемый многими крупными проектами по всему миру.

Я знаю, что скорость близка, но пока я знаю, что ей нужна Windows Server 2008, и это что-то очень новое. Обычно продукты Microsoft хороши с версии 2.0: -)

1

Хранитепоисковые запросы/словари - и элементы, которые ваше приложение будет требовать очень часто в Application или Cache объекте; запрашивайте базу данных для данных, которые зависят от роли пользователя.

--EDIT--

Это ответ на ваш комментарий.

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

  1. загрузить неизбежные таблицы при запуске приложения;
  2. загрузка большинства запрашиваемых таблиц в кэш на основе запросов таблиц;
  3. запрос базы данных для наименее запрашиваемых таблиц.

Если у вас нет проблем с производительностью, то пусть SQL обрабатывает все.

1

Хранить такое количество данных в Session - очень плохая идея. Каждый пользователь получит свою собственную версию!

Если это Общие данные (одинаковые для всех пользователей), рассмотрите возможность их перемещения в объект Application.

0