:) Я - поисковый архитектор, который с 1997 года занимается разработкой и внедрением технологий поисковых систем, работая инженером-программистом Lycos.
Мы используем FAST ESP в качестве поисковой системы, которая поддерживает http://thomasnet.com. Я работаю с ESP с 2003 года (тогда он назывался FDS 3.2).
FAST ESP чрезвычайно гибок и может индексировать многие типы документов (html, pdf, word и т. Д.). Он имеет очень надежный сканер для веб-документов, и вы можете использовать их промежуточный формат FastXML для загрузки пользовательских форматов документов в систему или использовать их Content API.
Одна из моих любимых частей движка - это конвейер обработки документов, который позволяет вам использовать десятки готовых плагинов для обработки, а также использовать Python API для написания собственных этапов обработки документов. Примером пользовательского этапа, который мы написали, был тот, который просматривает URL веб-сайта и пытается определить, к какой компании он принадлежит, поэтому дополнительные метаданные могут быть присоединены к веб-документу.
Он имеет очень надежный SDK для программирования / интеграции на нескольких популярных языках (C ++ / C # / Java) для добавления контента и выполнения запросов, а также для получения состояния системы и управления службами кластера.
ESP имеет язык запросов, называемый FAST Query Language (FQL), который является очень надежным и позволяет выполнять базовые булевы поиски (AND, OR, NOT), а также поиск по фразе и термину близости. В дополнение к этому в нем есть что-то под названием «поиск по области», который можно использовать для поиска метаданных документа (XML), формат которых может варьироваться от документа к документу.
С точки зрения производительности, он масштабируется довольно линейно. Если вы сравните его, чтобы определить, как он работает на одной машине, если вы добавите другую машину, это обычно может удвоить производительность. Вы можете запустить систему на одном компьютере (рекомендуется только для разработки) или на нескольких (для производства). Он устойчив к сбоям (он все еще может давать некоторые результаты, если один из ваших индексов с балансировкой нагрузки переходит в автономный режим) и имеет полную поддержку отработки отказа (одна или несколько критических машин могут выйти из строя или быть переведены в автономный режим для обслуживания, и система продолжит работу для правильной работы)
Итак, это очень мощно. Документация в настоящее время довольно хорошая. Итак, вы спросите, каковы недостатки?
Что ж, если данные, которые нужно сделать доступными для поиска, имеют часто меняющийся формат, это может быть проблемой. ESP имеет нечто, называемое «Профиль индекса», который в основном является файлом конфигурации, который он использует для определения того, какие поля документа важны и должны использоваться для индексации. Все, что подается в ESP, является «документом», даже если в него загружаются строки таблицы базы данных. Каждый документ имеет несколько полей, типичные поля: заголовок, тело, ключевые слова, заголовки, векторы документов, время обработки и т. Д. Вы можете указать столько собственных полей, сколько пожелаете.
Если ваш контент поддерживает в основном один и тот же формат (например, веб-документы), это не большая проблема. Но если вам нужно внести большие изменения в то, какие поля должны быть проиндексированы и как они должны обрабатываться, вам, вероятно, нужно отредактировать профиль индексации. Некоторые изменения в профиле индекса - «Горячие обновления», то есть вы можете вносить изменения, а не прерывать службу. Но некоторые из самых больших изменений - это «холодные обновления», которые требуют полной ссылки и индексации данных, прежде чем изменения вступят в силу. В зависимости от размера набора данных и количества компьютеров в кластере эта операция может занять несколько часов или дней. Холодные обновления сложно планировать, если у вас нет достаточно денег на дополнительное оборудование, которое вы можете подключить к сети, пока производственные системы выполняют холодное обновление и перезагружают данные. Необходимость делать это в производственных кластерах чаще, чем один или два раза в год, требует значительного объема планирования для правильного решения с минимальным временем простоя или 0%.
В вашем случае я сомневаюсь, что ваши форматы данных будут меняться очень часто. Если вам необходимо внести в него небольшие изменения, вы можете добавить дополнительные метаданные в поля области действия, чтобы избежать необходимости полной перезагрузки данных.
Большая часть проблем, с которыми вы, вероятно, столкнетесь, - это начальная кривая обучения использованию продукта. Как только вы получите кластер разработки (или узел), который делает то, что вы хотите, и если вам не нужно часто вносить существенные изменения в индексированные поля конфигурации, это очень и очень стабильная и надежная поисковая система для использования. Для вашего приложения это звучит как хорошее совпадение, для небольших компаний или стартапов есть варианты с открытым исходным кодом, которые не так дороги, как предварительные, которых должно хватить, если вам не нужна такая высокая производительность или долговечность.
Надеюсь, вы найдете эту оценку полезной. :)
С уважением,
Майкл Макинтош
Старший поисковый архитектор @ TnR Global