Здравствуйте, Serpenter_i, Вы писали:

S_>Здравствуйте,

S_>хочу создать сервис на основе .NET WebService для разгрузки базы данных. Сервис будет при инициализации кешировать все нужные таблицы, затем где нибудь раз в секунду обновлять свой кеш новыми записями. Это позволит при обращении к сервису получать информацию и делать сложные вычисления, не нагружая БД, а считая по кешу в оперативке. Очень хочется использовать .net веб-сервисы, потому что привык и чувствую себя удобно при разработке. Хочется получить масштабируемость не сменой технологий (переход на unix системы, c++, итп) а простым размножением количества компьютеров.

Моя плакать. Думаете до этого разработчики БД не додумались?
Сама СУБД отлично кеширует данные в памяти и может туда затянуть всю базу если объемов оперативки хватит. Кроме того СУБД поддерживает SQL, индексы, распараллеливание вычислений.

S_>Прокомментируйте пожалуйста такой подход, какие будут подводные камни. Я вижу только минус что WebService хостит IIS, который управляет пулом потоков неизвестным мне способом.
Вижу дофига минусов, начиная от необоснованности лишнего звена, до тормознутости и остуствия гибкости.
Кстати работа пула IIS отлично описана в MSDN.

S_>Наполнение кеша пока думаю делать так: в Application_Start создавать один поток, который будет отвечать за наполнение кеша, он будет жить очень долго и раз в секунду выполнять работу. Возникает вопрос — создавать поток самому (через System.Threading.ThreadStart) или через пул потоков ASP.NET (System.Threading.ThreadPool.QueueUserWorkItem). Прокомментируйте пожалуйста оба варианта, какие плюсы и минусы.
Варианты с потоками при любом раскладе бредовые. Время жизни app pool при отсутсвии запросов заканчивается очень быстро (20 минут), в реальном окружении еще могут стоять квоты на использование памяти, которые будут глушить app pool еще чаще.

Если вам нужна скорость, то лучше оптимизируйте свое приложение. Напишите правильные запросы, сделаейте разумные проекции. Оптимизируйте схему БД, создайте индексы, индексированные вьюхи.

Потом пожно заниматься разумной денормализацией данных, поддерживать денормальзованные данные в согласованном состоянии можно с помощью триггеров.

Если нужно совмещать OLTP (частые простые выборки и частые изменения) и OLAP (тяжкие аналитические запросы), то стоит задуматься об использовании служб бизнес-аналитики (SSAS) и использовать службы интеграции (SSIS) для перемещения данных.

Это все должно сопровождаться кешированием данных в приложении.

Если нужно периодически выполнять какой-то код, то можно задействовать шедулер ОС, SQL Server Agent или написать службу.

Реально нужен middleware когда нужно работать с распределенными БД, но изобретать его не нужно. Зачастую можно обойтись существующими библиотеками.