Поисковые движки

В порядке убывания доли на корпоративном рынке:

• Verity Search Products
• Autonomy Enterprise Search
• Convera / Excalibur RetrievalWare

Дальше неясно и приблизительно:

• Endeca
• Hummingbird SearchServer (Fulcrum / Open DOCS)
• Fast Data Search
• AltaVista Enterprise/Desktop Search
• Google Search Appliance
• Oracle Text, Ultra Search and interMedia Search

Для меня тоже. См. выше.

Спасибо.

Это иллюзия. Такого не бывает. Грязь есть всегда и никто ее за нас не вычистит.

Нужен. Практика показала.

Еще одна иллюзия. Спам - это часть социальной природы человека. Он есть везде, скажем даже в наших Я.Товарах (примерно то, что Вы описываете).

Боюсь, что если вы будете удалять раз и навсегда, то останетесь без клиентов.

Так бы сразу и сказали. А то спорим об алгоритмах, а постановки задачи оказывается и не было.

С уважением,

Илья

Действительно, часто бывает полезно в долгом споре выяснить,

о чем спор и оговорить общие определения.

Насколько я помню, данная тема началась с вопроса о выборе

поискового движка для сайта типа государственного портала.

Может быть эта тема несколько ортогональна направлению форума

в целом, но она такая.

И эта тема имеет свою специфику.

Я лично с трудом представляю спам на правительственном портале.

Мне также кажется, что, например, полнота при поиске

по законодательству важна и т.п.

Я надеюсь, что спрашивающий (Игорь) давно уже сделал

свой выбор, а тема сдвинулась в обсуждение некоторых

профессиональных вопросов.

И одним из вопросов был о вопрос об операторе SELECT,

на который я постарался ответить, что это лишь удобный

формализм (типа middleware), а его исполнение приводит

в современных SQL базах к вызовам тех или иных

процедур низкоуровневого доступа к данным.

По памяти ответить трудновато (у меня есть папочки, по крайней

мере на три первых номера в списке, но не дома), но мне кажется,

что первые номера в списке представляют собой надстройки

(интеграторы/анализаторы) над существующими индексами и прежде всего над индексами SQL баз, и слово Oracle там встречается очень часто.

И сколько я помню из личных бесед с представителями

Метатехнологии (Весть-Метатехнологии) для Convera / Excalibur RetrievalWare стандартной платформой является опять-таки

Oracle.

Так что, аргумент в виде приведенного списка я не понял,

мне кажется он для меня более выгоден, чем Вам.

С уважением,

Борис

Как, вы, однако, раздухарились! Перешли от тезаурусов к Ораклу! Не дай Бог начнёте Windows и Linux сравнивать.

Мне всегда казалось, что проблема с Ораклом и другими универсальными базами данных в том, что полнотекстовый индекс представляет собой очень своеобразную структуру - длинные записи существенно переменной длины. И хранить их в SQL-базе ну очень невыгодно. Отсюда и прогнозируемые Борисом расходы на невозможное и ненужное внедрение Оракла в Гугл. Я, кстати тоже думаю, как и Илья, что там ошибка примерно на порядок или два в меньшую сторону.

Язык просто очень отличается от цифр, а SQL-ные базы были заточены всё-таки под хранение цифр.

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

Ну и по поводу Oracle Context Option - там, по-моему, индекс-то как раз отдельный и именно полнотекстовый, традиционный для поисковиков? Впрочем, могу ошибаться - Андрей поправит. По крайней мере, Index Server в MS SQL - точно всегда был совершенно отдельный.

Что касается рассуждений о цене перехода на Оракл - а фишка-то в чём? Зачем Гуглу Оракл, я никак не возьму в толк? Чобы опять стать убыточным, ради чистой любви к СУБД?

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

По поводу указанных Ильёй наиболее популярных (и дорогих, кстати) искалок, то Оракла как хранилища текстового индекса там нет, конечно. То есть, может, документы и графику они и позволяют хранить в Оракле, но полнотекстовые индексы, естественно, самописанные.

Я не очень понимаю в общей постановке что такое "полнотекстовый

индекс".

В качестве справки (года до 1996 мы пользовали Oracle TextRetrieval

- предыдущее название Oracle interMedia Server) Oracle хранил

поисковый индекс в битных строках, хитро их записывая, и хитро

(весьма быстро) их доставая и обрабатывая. Затем мы перешли на

свои структуры данных. Фишка в том, что данные достаются как в том

так и вдругом случае SELECTом, а как на самом деле - даже не знаю - но для наших целей вполне эффективно.

С уважением,

Борис

Угу. Не к ночи будь помянутый M$ FullText search поддерживает начиная, по крайней мере, с 7-ой версии SQL Server'a (индексы кстати не в БД хранятся). Опять же можно делать запросы (SELECT'ы) к индексам Index Server'a. Видел даже некоторые add-on'ы для поддержки русской морфологии (на уровне Ispell'а как я разумею).

Однако довески в виде монструозных SQL серверов однозначно перечёркивают все остальные [теоретические] преимущества подобных систем.

Из всего перечисленного в начальном посте попробовал только Yandex.Site. Качество поиска понравилось. Очень. Не понравилось всё остальное. Отсюда вопрос к Илье: недружественность по отношению к владельцам виртуальных серверов (абсолютно непонятная политика лицензирования, да и цена в 80$ за Мб заставляет надолго задуматься...) - это "политика партии" или можно попытаться вести конструктивный диалог с Алексеем (он вроде крайним выбран)?

> Фишка в том, что данные достаются как в том так и вдругом случае SELECTом

Так ведь чтение данных с диска это не более одного процента работы, выполняемой поисковым механизмом. Затем эти данные нужно распаковать, найти объединение или пересечение, подсчитать релевантность, отсортировать полученный список. И если все эти операции делать на SQL, то база загнется (как показывает опыт mnogosearch). А если для этих целей пишется отдельный код, то зачем тогда данные хранить в дорогой полнофункциональной базе? Как сказал Илья, для простой таблицы "ключ -> инвертированный список" вполне достаточно самой примитивной схемы хранения, вроде Беркли_DB (если не говорить об особо крупных и загруженных системах, где и чтение данных приходится сильно оптимизировать). Использовать базу для хранения индекса оправданно только в том случае, если она и так используется для хранения, например, самих документов. Тогда конечно, почему бы и индекс не хранить там же.

Возникает такой почти теоретический вопрос. Интересно услышать мысли мэтров.

Очень вероятно, что использование реляционных подходов при решении примитивной (в смысле “первичной” а не смыле “простой в реализации”) задачи поиска не целесообразно. Но .... возможно ли разширение функций поисковых машин (как систем, что владеют огромной БД ) в сторону более аналитических задач (например тот же data mining или web mining)? Такой путь уже прошли разработчики OLTP систем для предприятий.

Если такое случится ( а языки типа всяких WebQL-ей уже разработаны достаточно хорошо), то возможно и механизмы реализации поисковых систем будут изменятся в сторону большей схожести с реляционными или постреляционными СУБД?

Есть несколько обстоятельств:

1) Я ввязался в эту дискуссию совсем не как сторонник навязывания

Oracle всем и вся. В течение некотого времени наблюдается

несколько поверхностный взгляд на возможности больших SQL баз данных

в задачах поиска, среди которых много разных и интересных помимо

поиска во всем глобальном Интернет.

Я попробовал объяснить, что большие SQL базы имеют массу возможностей

для эффективной обработки данных. Производителей SQL баз очень много, большие игроки отличаются тем, что там многое оптимизировано

(исполнение вложенных запросов, исполнение длинных запросов,

выбор специальных, но стандартных объектов, работа в оперативной памяти и т.п.).

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

2) Ну зачем кому-то писать новый поисковик для глобального Интернет?

Здесь больше не технологических проблем, а финансовых,

в смысле ну сделает, а где профит? Делать из академического интереса?

Яндекс, Рамблер и пр. НЕ ПОЛУЧАЮТ деньги за поиск, а получают

совсем за другое - за рекламу, за спец сервисы.

За лицензирование своих технологий (типа Яндекс.Сайт) - то есть

работы на корпоративном рынке.

А вот по последнему пункту уже возможна конкуренция, в том числе

и с решениями на основе реляционных баз данных.

При этом потребителя часто (но не всегда, конечно) собственно поиск интересует незначительно, простой поиск еще меньше.

Потребителю надо совместить поиск с поиском, например, по собственным базам или подавай "анализ" (именно здесь работают Autonomy и Verity -

и они востребованы).

А для своих БД он уже либо купил что-то из большой SQL базы

(Oracle, MS SQL, Sybase, DB2, Informix, ...) либо готов купить.

3) То есть, выбор, например, Oracle в качестве платформы информационной системы обусловлен:

3а) уверенностью, что все что захотите сделать, будет

можно реализовать

3б) относительно слабой зависимостью от текучки персонала

3в) ориентацией на самоокупаемость собственно технологических

решений

Увы, Борис, тут есть теоретический предел: при приближении объёмов простого текста к 10-12 Гбайт, поисковики с хранением индекса в реляционных базах перестают работать.

А сейчас типовой объём данных в копрорации включая периодику,

интернет-контент и пр. уже близок к этим цифрам.

Как раз тут уверенности в реализуемости всех нужных идей - нет.

Выше было указано, что и Оракл, и MS SQL не хранят полнотекстовый индекс в своей БД, а используют специальные структуры данных, как впрочем, и все интернет-поисковики. В этом смысле можно пользоваться было бы и Ораклом, если бы он открывал доступ к своим полнотекстовым возможностям. Так ли это - не знаю.

Ну, а то, что Оракл эмулирует стандартный запрос типа Select и потом внутри подменяет его на полнотекстовый аналог - это хорошо, программировать проще. Если вы эту возможность имели в виду, то и спорить не о чем.

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

При этом качество поиска - второстепенно, в первую очередь влияет актуальность, скорость, полнота, отсутствие спама при хорошей релевантности. Очевидно, что в лабораторных условиях или условиях неспешного внедрения у крупного заказчика легко получить релевантность выше, чем у Яндекса или Гугла, а вот построить бизнес-процесс в масштабах Рунета или Интернета в целом - очень трудно.

Заметим, что и MSN только что начала делать свой собственный поисковик, и Увертюра купила пару поисковиков - вместо того, чтобы покупать универсальную базу данных.

Зарабатывают они на поиске, конечно. Как иначе назвать контекстную поисковую рекламу?

Или Вы считаете, что зарабатывать на поиске - это брать центы за запросы? Или продавать поисковики компаниям - ну и тогда, Гугл и Верити как раз на поиске и зарабатывают. Гугл лицензирует поисковик

очень широко, в том числе крупнейшим интернет-игрокам, Верити - лидер рынка корпоративных поисковиков.

Фактически, мы спорим о разных вещах - о различных бизнес-моделях. Вы для себя выработали работающую схему своего бизнеса, когда Вы думаете о семантике, о качестве услуги, а о хранении и эффективности думать считаете не обязательным при прочих равных условиях (и в вашем бизнесе это может быть оправданно - пусть Оракл об этом заботится, на среднем, но стандартном уровне), а Илья думает в первую очередь об эффективности и хранении, а во вторую - о семантике (но думает!), и если он не будет так делать, его проект рост Интернета сожрёт за полгода.

При том, что вы ведёте клиентов годами, годами внедряете систему, обучаете пользованию, подстраиваете тезаурусы, действительно лучше использовать стандартные решения там, где это не касается вашей ключевой компетенции - качества очень углублённого поиска по чистым и выверенным массивам данных. Ну и хорошо.

Но нельзя советовать пламенным борцам со змеем экспоненты поступать так же.