OFF: аналоги yandex.site?

У нас есть движок, использующийся на Finds.ru и Poisk.tochka.ru, который можно поставить и на сайт за разумные деньги. Не за 290 евро, конечно. Немецкая, французская, испанская и английская морфология не проблема, у нас есть.

Другое дело, что этот движок - пока не коробка с глянцевой документацией.

Истинно динамический индекс не обещаем, более того, считаем вредным.

А вот переиндексация хоть раз в час возможна.

Игорь, поясните, пожалуйста, про "вредность".

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

Кстати, мне показалось, в предлагаемом Вами движке используется не полноценная русская морфология, а стемминг.

Самый простой пример - запрос "подборка" и запрос "подборок".

Такая "морфология" идет в поставке siteMETA бесплатно.

lexus

Небольшое замечание - оформьте подпись, пожалуйста, нормально.

Посмотрите на свои посты сейчас.

Просто я не вижу способа грамотно спроектировать динамический индекс, а занимались мы этим довольно много. А главное, не вижу смысла. То есть при наличии денег на разработку можно, но зачем?

Динамический индекс, если приложение критичное, должен поддерживать транзакции и откаты, как в порядочной базе данных. В индустрии БД на это убили десятки лет, поэтому я не верю, что разработчики поисковой машины могли это сделать за небольшие сроки и деньги. Да и с масштабируемостью будут проблемы. Неспроста Яндекс, Рамблер, Гугл и прочие используют всё же статические индексы и эпизодическое обновление.

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

Впрочем, можно держать одну копию, а при разрушении индекса всегда можно переиндексировать заново, правда, будет потеряно время простоя.

При этом есть более простые и надёжные решения: статический или полустатический индекс можно собирать раз в день или в час, а в промежутке новые страницы сбрасывать во временный индекс простой структуры("помойку").

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

Что касается нашего движка, то там действительно используется бессловарная морфология. Так было проще - проект сделан очень быстро. В целом работает. Зато многоязыковая.

Но вообще говоря, морфология - не конкурентное преимущество никоим образом. Она у всех есть уже лет пять как. В том числе коваленковская или орфовская, или ещё какая.

У Меты есть, у Галактики есть, у Гаранта есть, у Рамблера есть, у Яндекса есть, у Апорта есть, у РБК есть, у Информатика есть, у МедиаЛингвы есть, у Рубрикона есть, у Нейрока была, у ДИАЛИНГа была, у Коваленки есть, у нас есть, у АВВУУ есть, у Вести есть, далее по индукции.

Ну и что?

Это раньше Яндекс гордо, но неуклюже писал "с учётом русской морфологии". Хотя морфология была и у Апорта, и у Рамблера. Сейчас, по-моему, перестали. В общем, общее место.

Главное там всё же удобство управления и установки, всякие пользовательские штучки, языки, прочее.

А нам вроде как удалось это сделать. Времени правда ушло немало, больше чем хотелось.:( Деньги на разработку были, а стоимость разработки такого проекта в Украине в 3-5 раз "дешевле", чем в Москве.

Смысл – создание простого в администрировании поискового средства, которое обеспечивает качество поиска на уровне "больших" поисковых систем, очень быстро, практически мгновенно, реагирует на изменения контента, постоянно поддерживает актуальный индекс и не требует дополнительного времени на переиндексацию. Новый документ уже через несколько секунд после появления становится доступным для поиска. Областей, где такое свойство крайне необходимо, становится все больше. Пример – сайты новостей, прайс-листы магазинов и т.п. Или системы покрупнее, типа корпоративного хранилища документов, куда "сваливается" переписка, документы, новостные ленты от информагентств и т.п., причем искать по всему этому хочется сразу и сейчас.

При всем при этом нет необходимости заботиться об администрировании - переиндексациях, сменах индекса, "доливках" и т.п.

Конечно же нет. Мы и не пытались соревноваться с разработчиками БД в способности к восстановлению после сбоев. А в качестве поиска, удобстве организации поиска на сайте, простоте администрирования – вполне готовы бороться. И считаем для большинства сайтов эти свойства поиска более важными. Если у заказчика есть какие-то специальные требования и запросы, то мы можем предложить решение в зависимости от этих требований, например, на основе нашего статического индекса. Три месяца, которые прошли после запуска проекта, показали, что система работает нормально не только на тестах, но и на десятках различных сайтов, под управлением различных операционок и серверов. Так что опасения по поводу надежности динамического индекса не стоит преувеличивать.

Мы вовсе не ратуем за использование динамики во всех случаях. SiteMETA – это не универсальное решение для построения поисковых систем любого масштаба. SiteMETA – это поиск для сайта, довольно удобный и недорогой. В коммерческой версии мы гарантируем устойчивую работу siteMETA на объемах текста до 1 ГБ (На тестах программа нормально работала и на 2-х, и на 3-х гигабайтных массивах). Такого объема хватает для 99% процентов сайтов. Для построения более крупных систем мы тоже используем статический индекс или комбинацию динамики и статики.

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

А из общения с заказчиками и "интересантами", менее погруженными в предмет, складывается немного другое впечатление. Люди могут не понимать, как работает поисковая система, по каким принципам осуществляется ранжирование документов, по каким критериям нужно выбирать себе поисковик, но 90% с большим удовольствием произносят слово "морфология" и считают ее наличие чуть ли не главным показателем качества поискового продукта. Типичные фразы из общения на выставках и переговорах – "А морфология у вас есть?", "Мы бы сами написали поиск, но у нас морфологии нет" и т.п. :)

Это да, тут трудно возразить.

У нас (Галактика-Зум) тоже есть динамический индекс.

Долго мы сомневались, пока взялись за него, в оценке трудностей я с Игорем вполне согласен.

Сил и времени на него тоже ушло довольно много.

Но транзакции и откаты реализованы: у некоторых пользователей они являются элементами их технологии ведения базы. Да и надежность при этом намного выше: при любых сбоях система возвращается в предыдущее состояние и нужно повторить только последнюю операцию.

Самые большие из работающих баз у наших пользователей содержат до 60Гб данных (в переводе на чистый текст).

Практический лимит в нынешней реализации - примерно 0,5Тб на каждый сегмент. Относительно просто и больше сделать, но нет смысла при нынешней массовой технической базе.

Правда, и денег за такую систему мы берем немного больше, чем SiteMeta.

http://mnogosearch.ru/

В целом с Игорем я согласен.

Но для разглядывания могу подкинуть ссылочку на описание неплохо организованного динамического индекса, сделанного из Berkeley DB (транзакции и прочее в ней имеются).

http://www10.org/cdrom/papers/275/index.html

Пункт 4. Managing inverted files in an embedded database system

Поиск там конечно медленней статического в разы, да и как сливаются "постлисты" не описано, но все же рекомендую.

С уважением,

Илья