Здравствуйте, s_viy, Вы писали:
_>В свое время достаточно много сделал подобных сервисов, но как раз на с++ и linux. Преимущество такого подхода в том, что такие сервисы очень и очень быстры (при грамотной реализации конечно) — одного хоста бывает достаточно чтобы обслуживать многие тысячи запросов в секунду — этого вполне хватит чтобы обслуживать несколько тысяч пользователей одновременно. НО, если производительности всегда хватало с лихвой, то с объемом оперативной памяти могут возникнуть сложности. Проблемы с производительностью решаются просто — путем распределения нагрузки по нескольким хостам, при условии что они имеют одинаковые кэши, но этого этого как правило не требуется. Если данных очень много (нельзя их загрузить все в кэш), то распределять нужно данные, а это гораздо сложнее — придется делать мини-поисковую систему (куча хостов с загруженными в оперативку частью данных, сервис обслуживающий пользователей, отправляющий запросы Index-сервисам и формирующий результат ну и пр.)
_>С начала необходимо оценить объем индексируемых данных — хватит ли оперативки для кэша и индексации. Если нет, то простым размножением количества компьютеров не отделаешься — лучше не ввязываться. И обязательно постоянно проводи нагрузочные тесты, с самого начала разработки. Но наверняка 90% времени и более будет занимать разбор и формирование сообщений. Рассмотри варианты REST и JSON — они гораздо легче и быстрее SOAP.
В рамках текущей задачи данные влазят, если потом разрастется буду думать. Про REST и JSON мысли есть, но пока нет сервиса нечего нагруженно тестировать. Т.к. веб-сервисы писать довольно просто, то перевести их на rest/json будет тоже просто.
_>Сделай лучше windows-сервис который читает данные из БД и отправляет данные на сервис для кэширования, а в своем сервисе сделай интерфейс для заполнения кэша. Чтобы каждый раз не загружать все данные можно использовать ChangeLog — специальная таблицы, в которую скидываются ID изменившихся записей. Если нужна максимальная оперативность, то приложение которое вносит изменения в БД одновременно отправляет их на индексацию на сервис, и только если сервис недоступен скидывает ID в ChangeLog
Правильно ли я понял, вы предлагает сделать 3 сервиса для обслуживания одного индекса — кеш, сервис наполнения кеша, собственно сервис индекса? Совсем не понял фразу — "в своем сервисе сделай интерфейс для заполнения кеша".
Вопрос с ChangeLog интересный. Т.е. вы предлагаете создать еще один сервис для ведения истории записей? При записи в БД нужно ли дожидаться успешной записи в ChangeLog? Если нет, то непонятно как мы гарантируем что в индексах рано или поздно появится актуальная информация. Если да, то возникает вопрос, в чем отличие ChangeLog от БД? Если в БД отказаться от update и delete, и реализовать их за счет версионности, то БД превратится в ChangeLog, потому что индексы смогут успешно обновлять себя из БД, и ChangeLog становится ненужным. Если я правильно помню, что-то типа ChangeLog есть у фейсбука, но им ненужна гарантия что индекс рано или поздно обновится до актуальной информации. Даже наоборот, например, когда они показывают новости то показывают лишь небольшой процент случайно выбранных новостей, про остальное забывают, потому что иначе поток новостей слишком большой.
