Поиск предприятия: кто-либо разработал на FAST ESP? Что Вы думали об этом?

:) Я - поисковый архитектор, который разрабатывал и интегрировал технологию поисковой системы с 1997 с моих дней как разработчик программного обеспечения Lycos.

Мы используем FAST ESP в качестве поисковой системы, это приводит в действие http://thomasnet.com. Я работал с ESP с 2003 (затем известный как FDS 3.2).

FAST ESP чрезвычайно гибок и может иметь дело с индексацией многих типов документов (HTML, PDF, слово, и т.д.). Это имеет очень устойчивый поисковый робот для веб-документов, и можно использовать их посреднический формат FastXML, чтобы загрузить пользовательские форматы документов в систему или использовать их API Содержания.

Одна из моих любимых частей механизма является своим Конвейером Обработки документов, который позволяет Вам использовать десятки плагинов обработки out-of-the-box, а также использования API Python для записи собственных этапов обработки документов. Примером пользовательского этапа, который мы записали, был тот, который смотрит на URL веб-сайта и пытается определить, какая компания, она принадлежит так дополнительным метаданным, может быть присоединена к веб-документу.

Это имеет очень робастное программирование / интеграция SDK на нескольких популярных языках (C++/C#/Java) для добавления содержания и выполнения запросов, а также выбирающего состояния системы и руководящих служб кластеров.

ESP имеет язык запросов, названный Языком запросов FAST (FQL), который очень устойчив и позволяет Вам делать основные Поиски с использованием булевых операторов (И, ИЛИ, НЕ), а также фраза и называть поиски с расстоянием. В дополнение к этому это имеет что-то позвонившее "поиск объема", который может использоваться для поиска метаданных документа (XML), который имеет формат, который может варьироваться от документа до документа.

С точки зрения производительности это масштабируется справедливо линейно. При сравнительном тестировании его, чтобы определить, как это работает на одной машине, если Вы добавляете другую машину, это обычно может удваивать производительность. Можно выполнить систему на одной машине (только рекомендуемый для разработки), или многие (для производства). Это является отказоустойчивым (это может все еще служить некоторым результатам, если один из Ваших сбалансированных с загрузки индексов идет офлайн), и это имеет полную поддержку кластерных систем (одна или несколько критических машин могли перестать работать или быть выведены из эксплуатации для обслуживания, и система продолжит функционировать правильно),

Так, его очень мощное. Документация в наше время довольно хороша. Так, Вы спрашиваете, каковы оборотные стороны?

Ну, если данные, которые необходимо сделать доступным для поиска, имеют формат, который часто изменяется, который мог бы быть болью. ESP имеет что-то позвонившее "Индексный Профиль", который является в основном файлом конфигурации, который это использует для определения, какие поля документа важны и должны использоваться для индексации. Все питалось в ESP, "документ", даже если Ваши строки таблицы базы данных загрузки в него. Каждый документ имеет несколько полей, типичное поле быть: заголовок, тело, ключевые слова, заголовки, documentvectors, processingtime, и т.д. Можно указать столько собственных полей, сколько Вы желаете.

Если Ваше содержание сохраняет главным образом тот же формат (как веб-документы) не большая проблема. Но если необходимо внести большие изменения, к которым должны быть индексированы поля и как их нужно рассматривать, вероятно, необходимо изменить Индексный Профиль. Некоторые изменения в индексном профиле являются "Горячими Обновлениями", означая, что можно внести изменение и не прервать сервис. Но, некоторые большие изменения являются "Холодными Обновлениями", который требует полного переканала данных и индексирующий, прежде чем изменение вступит в силу. В зависимости от размера Вашего набора данных и сколько машин находится в Вашем кластере, эта операция могла занять часы или дни. Холодные Обновления являются болью для планирования, если у Вас нет большого количества наличных денег для дополнительного оборудования, которое можно принести онлайн, в то время как производственные системы выполняют холодное обновление и перезагружают данные. Имея необходимость сделать это на производственных кластерах несколько раз или два раза в год требует изрядного количества планирования разобраться с минимальным или 0%-м временем простоя.

Для Вашего случая я сомневаюсь, что Ваши форматы данных будут изменяться очень часто. Если необходимо сделать незначительные тонкие настройки к нему, можно добавить дополнительные метаданные для обзора полей для обхождения потребности сделать любые полные перезагрузки данных.

Большая часть проблемы, с которой Вы, вероятно, встретитесь, является начальной кривой обучения использования продукта. После того как Вы получаете кластер разработки (или узел) выполнение, что Вы хотите и если не должны вносить существенные изменения в индексируемые полевые конфигурации часто, это - очень очень стабильная и надежная поисковая система для использования. Для Вашего приложения это походит на хорошее соответствие для меньших компаний или стартапов, там опции с открытым исходным кодом там, которые не являются столь же дороги честный, который должен быть достаточным, не ли Вам нужны столько же производительности или длительности.

Я надеюсь, что Вы находите эту оценку полезной.:)

С уважением, Michael McIntosh Senior ищет архитектора глобальный TnR

FAST ESP - это хорошо. По крайней мере, по сравнению с Google Search Appliance. Но то, какую поисковую систему предприятия выбрать, полностью соответствует требованию.

Технология ESP FAST тверда, но Вы захотите принять во внимание, что это - действительно поисковая платформа (следовательно "ESP") не опыт поиска out-of-the-box. Качество Ваших результатов непосредственно связано с качеством Вашего индекса, что означает, что действительно необходимо настроить конвейер обработки документов и индексный профиль для содержания.

Нет никаких жестких правил для этого; действительно необходимо понять платформу и содержание. Это действительно занимает время и большой метод проб и ошибок. Кроме того, это - ресурс, голодный, таким образом, Вы не можете сэкономить на аппаратных средствах. Если у Вас будут время и ресурсы, чтобы сделать это право, то это будет работать отлично, но промежуточное задание будет не лучше (и возможно хуже), чем что-то из поля или даже Lucene.

Я нахожусь в процессе реализации FAST ESP для нескольких корпоративных интранет-сайтов (крупная компания). Я работал немного с поисковой технологией (Правда назад в конце 90-х).

К счастью я взял курсы разработчика ESP FAST, прежде чем мы действительно начали. Курсы были действительно легки и если Вы - быстрое исследование, можно, вероятно, просто сделать онлайн-курсы. Самое большое преимущество в них для меня получало предостережение на API перед запущенным проектом. После беглого взгляда и нескольких лабораторий программирования с помощью API, который я понял, было вполне немного, что я должен буду кодировать.

Я главным образом разочарован API. FAST ESP был просто куплен MS меньше чем год назад, так надо надеяться, они получат некоторую справку в чистке API.NET. Чувства API.NET как кто-то просто нажали кнопку и сделали обертку COM для взаимодействия через интерфейс с собственными сервлетами Java. Соглашения о присвоении имен API и методы достаточно легки ориентировать себя на (как долго, поскольку Вы помните, что все наборы/массивы ESP FAST на основе 1 вместо на основе 0). Однако я полагаю, что они могли сделать большую работу здесь. API Java походил в значительной степени на все другие API Java, которые я видел и работал с. Соглашения о присвоении имен и структура похожи на стандартный Java API, вероятно, потому что FAST, ESP является основанной на Java поисковой системой и их разработчиками, является разработчиками программного обеспечения Java и не разработчиками программного обеспечения.NET.

Сначала, так как я использовал ASP.NET, я разработал ряд веб-элементов управления, которые подражают функциональности веб-элементов управления SharePoint MS. В классе и всех примерах ASP.NET, все было встроенным кодированием ASP.NET без или очень небольшим количеством "кода - позади" кодирования. Сеть разработчиков Yahoo! имеет некоторые хорошие шаблоны разработки для разработки поисковых интерфейсов, результатов, пейджеров, и т.д.

В целом и до сих пор, это работает вполне прилично. Мы находимся все еще в этапе разработки и собираемся запустить тестирование бета-версии наш сайт в течение следующих нескольких недель. FQL (Быстрый Язык запросов) немногим выше сложного - наши пользователи будут, вероятно, жаловаться, что язык не достаточно "подобен Google" для них. При поиске некоторого FQL файлы PDF Вы сможете предварительно просмотреть язык. Можно также просто использовать простые поиски (все условия, любые условия, и т.д.).

Если бы существует что-либо определенное, требуется знать, просто спросить, и я попытаюсь получить информацию. Мы используем FAST ESP в среде VM - который, как они говорят, не поддерживается, но то, что это хорошо работало, и результаты сравнительного теста хорошо для нас.

@anand, Вы можете использовать FAST ESP .NET API. При установке имеются документы в формате PDF, примеры кода и справочные материалы по API.

@Michael McIntosh: Чтобы избежать холодного обновления, вы можете добавить в индекс общие поля. Например, вы добавляете 5 общих целых чисел, 5 строк и 5 дат. Когда вам нужно внезапно ввести новое целое число, вы можете использовать уже имеющийся «отступ», например igeneric1.

Через некоторое время вы можете выполнить «холодное» обновление, а затем объединить эти поля и дать им собственные имена и т. Д.

@anand: вы можете выбирать между .NET Content API или делать все через HTTP / XML и стилизовать XML по своему желанию.

Я уже несколько лет поддерживаю FAST ESP. В целом 4/5.

На сегодняшний день я знаю, что платформа FAST ESP надежна, но у различных разъемов есть некоторые особенности.

Коннектор Lotus Notes особенно плох и периодически выходит из строя, когда индексируется более 100 000 документов.

Другие причуды могут быть довольно серьезными, например, средство обхода файлов не отражает обновление документа при обновлении разрешений NTFS для файлов. Это означает, что каждый может увидеть документ, который не должен видеть - проблема с безопасностью.

Я разделяю мнение других здесь: FAST ESP - это очень хорошо, но это определенно не готовое решение. Ожидайте, что вы потратите от 3 до 12 месяцев на внедрение - но вы будете вознаграждены очень мощным двигателем.

Мы реализовали большое количество приложений FAST ESP, и во всех случаях ESP оказался очень стабильной и высокопроизводительной платформой, если вы заранее инвестируйте в относительно более высокие затраты на внедрение. Что касается вопроса о желтых страницах - мы внедрили и управляем крупнейшим сайтом онлайн-каталогов в США, используя ESP, и он обрабатывает огромные QPS (запросы в секунду). Как уже упоминалось другими, ключевые альтернативные технологии - например, Google, Solr / Lucene, также очень эффективны, и ваш выбор действительно зависит от технических / пользовательских требований и бюджета.