Так как мы хотим построить движок, ориентированный на громадное количество документов, то мы должны быть готовы к затратам на их накопление. Под затратами в данном случае будем понимать оплату оборудования сканеров CA, диспетчера и архивных серверов, оплату каналов связи, оплату операторов, обслуживающих весь этот процесс. В масштабах мировой паутины можно получить впечатляющие цифры затрат. Как попытаться их минимизировать?
Если модель накопления данных имеет распределенный характер, то почему не позволить другим компаниям-партнерам заниматься таким накоплением и обработкой результатов, сохранив за собой роль координатора в лице центрального диспетчера. Вы спросите, а какой резон партнерам участвовать в подобной программе. Ответов несколько: во-первых, сканируя собственные ресурсы собственными силами, участник программы гарантированно имеет самые свежие данные о состоянии документов его ресурсов в центральной поисковой базе. Во-вторых, участник программы, установив и настроив программное обеспечение, поставляемое ему нами, может организовать собственную поисковую систему по собственным ресурсам, при этом не затратив денег на разработку собственного программного обеспечения. При желании мы можем даже взять на себя роль обучающего центра и/или поддержку локального индекса.
В-третьих, распределение сфер ответственности может породить тематические коллекции документов и возможность поиска по ним, что является немаловажным фактором в условиях стремительного роста объемов информации. В-четвертых, подобный сервис может предоставляться как бизнес-услуга клиентам в центрах хостинга или сервис-провайдинга. При желании можно обнаружить и другие резоны, однако это является задачей маркетологов и серьезно не рассматривается в данном документе.
Из вышесказанного следует, что нашей задачей наряду с разработкой системного программного обеспечения поискового комплекса является также разработка прикладного программного обеспечения локального поиска для внешних компаний или лиц, принципы которого будут существенно отличаться от принципов поиска в основной поисковой системе, однако данные для этих различных поисков будут общими.
Отметим также, что в случае, когда накоплением данных по части коллекции документов занимаются внешние партнеры, в алгоритм работы их накопителей следует внести некоторые изменения. Эти изменения могут быть связаны с ограниченностью ресурсов партнера (например, нет возможности установить у себя многоязыковую версию или ширина канала связи партнер-базовая система "Turtle" не достаточна). При взаимодействии с внешним CA необходимо минимизировать количество соединений с подсистемами "Turtle". Специально для таких клиентов создан вспомогательный индексный сервер, с которым и контактирует CA внешней компании и который сам осуществляет все необходимые соединения с внутренними серверами системы по локальной сети для выяснения детальной информации о документе. Мы называем такие типы серверов Knowledge Server. Их количество в системе зависит от того, какое количество партнеров имеет проект и какой суммарный объем информации обрабатывает каждый партнер.
При организации коллекции по географическому принципу URL ресурса не всегда отражает географическую принадлежность. Существует множество российских сайтов, которые находятся в различных доменах первого уровня, отличных от домена "ru". Например, корпоративный сайт нашей компании имеет имя www.stack.net. Вносить руками все вновь появляющиеся в таких зонах сайты, которые удовлетворяют заданным критериям коллекции весьма трудоемко. Забегая вперед, отмечу, что для решения подобных задач в рамках прототипа нашей поисковой системы мы создали специальный Geo-Ip Server (GS), в функции которого входит определение соответствия между Интернет IP адресом и географическим положением его владельца.
Следует отметить, что система не может ориентироваться исключительно на внешние накопители данных и должна обладать достаточным набором собственных CA, чтобы избежать нежелательной зависимости от внешних, неподконтрольных нам факторов.
©ЗАО "Группа компаний Стек". 2003-2007