Здравствуйте, Serpenter_i, Вы писали:
S_>Здравствуйте,
S_>хочу создать сервис на основе .NET WebService для разгрузки базы данных. Сервис будет при инициализации кешировать все нужные таблицы, затем где нибудь раз в секунду обновлять свой кеш новыми записями. Это позволит при обращении к сервису получать информацию и делать сложные вычисления, не нагружая БД, а считая по кешу в оперативке. Очень хочется использовать .net веб-сервисы, потому что привык и чувствую себя удобно при разработке. Хочется получить масштабируемость не сменой технологий (переход на unix системы, c++, итп) а простым размножением количества компьютеров.
В свое время достаточно много сделал подобных сервисов, но как раз на с++ и linux. Преимущество такого подхода в том, что такие сервисы очень и очень быстры (при грамотной реализации конечно) — одного хоста бывает достаточно чтобы обслуживать многие тысячи запросов в секунду — этого вполне хватит чтобы обслуживать несколько тысяч пользователей одновременно. НО, если производительности всегда хватало с лихвой, то с объемом оперативной памяти могут возникнуть сложности. Проблемы с производительностью решаются просто — путем распределения нагрузки по нескольким хостам, при условии что они имеют одинаковые кэши, но этого этого как правило не требуется. Если данных очень много (нельзя их загрузить все в кэш), то распределять нужно данные, а это гораздо сложнее — придется делать мини-поисковую систему (куча хостов с загруженными в оперативку частью данных, сервис обслуживающий пользователей, отправляющий запросы Index-сервисам и формирующий результат ну и пр.)
S_>Прокомментируйте пожалуйста такой подход, какие будут подводные камни. Я вижу только минус что WebService хостит IIS, который управляет пулом потоков неизвестным мне способом.
С начала необходимо оценить объем индексируемых данных — хватит ли оперативки для кэша и индексации. Если нет, то простым размножением количества компьютеров не отделаешься — лучше не ввязываться. И обязательно постоянно проводи нагрузочные тесты, с самого начала разработки. Но наверняка 90% времени и более будет занимать разбор и формирование сообщений. Рассмотри варианты REST и JSON — они гораздо легче и быстрее SOAP.
S_>Наполнение кеша пока думаю делать так: в Application_Start создавать один поток, который будет отвечать за наполнение кеша, он будет жить очень долго и раз в секунду выполнять работу. Возникает вопрос — создавать поток самому (через System.Threading.ThreadStart) или через пул потоков ASP.NET (System.Threading.ThreadPool.QueueUserWorkItem). Прокомментируйте пожалуйста оба варианта, какие плюсы и минусы.
Сделай лучше windows-сервис который читает данные из БД и отправляет данные на сервис для кэширования, а в своем сервисе сделай интерфейс для заполнения кэша. Чтобы каждый раз не загружать все данные можно использовать ChangeLog — специальная таблицы, в которую скидываются ID изменившихся записей. Если нужна максимальная оперативность, то приложение которое вносит изменения в БД одновременно отправляет их на индексацию на сервис, и только если сервис недоступен скидывает ID в ChangeLog
