DAL, Session, Cache Architecture - PullRequest
Новая
       10

DAL, Session, Cache Architecture

2 голосов
/ 21 апреля 2010

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

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

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

Дополнительная информация: Количество одновременных пользователей ~ 50 000

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

Спасибо

Ответы [ 4 ]

4 голосов
/ 21 апреля 2010

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

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

Я рекомендую хранить таблицы данных в Cache , а также заполнять каждую таблицу только при первом запросе, а не все сразу. Таким образом, если 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;
}

РЕДАКТИРОВАТЬ: - Обновление вопроса

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

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

1 голос
/ 21 апреля 2010

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

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

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

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

1 голос
/ 21 апреля 2010

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

- EDIT -

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

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

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

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

0 голосов
/ 21 апреля 2010

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

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

...