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

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

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

расскажите кто делал что то подобное и как вы это решали.

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

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

Если я правильно понял задачу и используется MS SqlServer то почему бы не использовать стандартный механизм System.Web.Caching ASP.NET?
Допустим веб-сайт делает запрос на класс MyClass
Псевдо код:

Где то в глубине конструктора MyClass() происходит ADO.NET запрос такого типа

Использовать метод myMethod для обновления кеша с новыми данными при сбросе старых. Подробности о Cache.Insert
На базе данных провести приказ ALTER DATABASE MyDatabase SET ENABLE_BROKER и в событии Application_Start() файла global.asax спустить прослушивание SqlDependency.Start(connectionString);
По идее теперь когда вин-сервис уложит новые данные в дб, кеш должен автоматически обновлятся. Мне неизвестны подробности дб, поэтоми могут быть проблеммы. Подробности по SqlCachDependency

Ну а если другая дб или другой огород городить то можно наследовать от CacheDependency и делать специальную зависимость кэш.

Это сообщение отредактировал(а) SKrivosein - 25.3.2013, 05:01

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

я только как то не совсем понял как хранить много классов в этом кэше. т.е. к примеру, к нам заходит 100 пользователей, и я хочу их всех сохранить в кэш, я должен из них создать массив какой то? или пихать по отдельности? как тогда искать?

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

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

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

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

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

Это сообщение отредактировал(а) SKrivosein - 26.3.2013, 00:47

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

Для таких целей придуманы OLAP хранилища