Знаю, что баян (неделя прошла с релиза), но лучше поздно, чем никогда.

Еще бы «Расстояния Левенштейна» sphinx держал и цены бы ему не было. libstemmer_c - только частичное спасение.

СпустИ год...

>произвоидительности

Отлично.

>Проверено: anonymous_incognito
о, шаман школу открыл ;)

> поддержка ODBC и в Windows, и в linux.

и в Windows, и в linux.

linux

l

Не стыдно? А?

Не стыдно? А?

Спалился, виндузятнег

> Еще бы «Расстояния Левенштейна» sphinx держал и цены бы ему не было.

цены бы ему не было при нормальной поддержке обновления индексов.

хотя для «mostly read-only»-данных - отличное решение.

Так ведь Lucene-же!

Авторы работают над этим:

«we'll probably be busy building 1.x-alpha with incremental (real-time) updates for Christmas.»

У Lucene есть свои минусы. И свои плюсы.

Lucene в некоторых случаях быстрее, обладает возможностью нечеткого поиска. Прекрасно обновляет индексы. Хорошими темпами развивается и даже имеет си реализацию cLucene, которая, наверное, вечно будет в догоняющих.

Однако, сложнее интегрируется, кушает слегка больше ресурсов, гораздо медленнее индексируется.

Я бы сказал у них несколько разные ниши.

Я виндоузятник и горжусь этим. Правда на домашнем компьютере уже год не держу windows, но это мелочи, недостойные упоминания ^_^

> цены бы ему не было при нормальной поддержке обновления индексов.

Забыл упомянуть в новости еще одно немаловажный факт: в 0.9.9 появился параметр sql_query_killlist, предназначенный для удаления и обновления существующих индексов без перестройки и, в особенности, для борьбы с «фантомными» результатами.

http://www.sphinxsearch.com/docs/manual-0.9.9.html#conf-sql-query-killlist

Вопрос

Скажите пожалуйста, у меня есть небольшой сайт со своей CMS на PHP и мне сейчас нужен поисковик.
Sphinx подойдёт или слишком громоздок для сайта где от силы страниц 100?
Заранее спасибо.

> Sphinx подойдёт или слишком громоздок для сайта где от силы страниц 100? Использовать можно, но смысла мало. Контента явно недостаточно, чтобы бд не справилась своими силами. Где данных мало обычно используют полнотекстный поиск, встроенный в базу данных. Сейчас почти в любой бд есть своя реализация.

>цены бы ему не было при нормальной поддержке обновления индексов.

А чем дельты не нравятся? Четырёхгиговый форум индексирую так каждые 10 минут - никаких нареканий :) Раз в неделю полный реиндекс, каждые 10 минут - дельта.

>Sphinx подойдёт или слишком громоздок для сайта где от силы страниц 100?

Там справится обычный LIKE :) Без индекса...

А при каком количестве контента есть смысл ставить подобный поисковик? Просто мой сайт быстро развивается и его наполняют длинными статьями

> А чем дельты не нравятся? Четырёхгиговый форум индексирую так каждые 10 минут - никаких нареканий :) Раз в неделю полный реиндекс, каждые 10 минут - дельта.

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

>Не во всех случаях данные только добавляются

А, пардон, да, не учёл.

А при каком количестве контента есть смысл ставить подобный поисковик? Просто мой сайт быстро развивается и его наполняют длинными статьями

Не думаю, что на этот вопрос можно ответить однозначно. Единого критерия не существуют, требования тоже очень разнятся. Если нужен поиск с учетом морфологии и релевантности, то подобный поисковик имеет смысл ставить практически при любом количестве данных. Однако, в mysql 5.1 или pgsql 8.3 полнотекстный поиск держит стемминг, так что и здесь не все однозначно. Я являюсь админом форума с ~миллионом сообщений - там fulltext индекс mysql прекрасно справляется. sphinx я там ставил только ради морфологии и чтобы отказаться от myisam. Думаю, задумываться о таком поисковом движке вам следует только при экспоненциальном росте количества контекста.

> Lucene в некоторых случаях быстрее, обладает возможностью нечеткого поиска. Прекрасно обновляет индексы.

ты забыл добавить, что еще и кластеризуема (это я про люсю)

ты забыл добавить, что еще и кластеризуема (это я про люсю)

sphinx тоже, хотя у них и разные подходы к данному вопросу. Конечно, я упомянул не все отличия, полное перечисление отличий, даже без описания, потянет на полноценную статью ^_^

> Не во всех случаях данные только добавляются, есть ситуации, когда данные часто обновляются или удаляются. В этом случае дельта-индекс никак не поможет. killlist же фича новая и, по мне, довольно кривая.

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

killlist больше на тотальное цензурирование смахивает.

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

killlist больше на тотальное цензурирование смахивает.

Способ, ИМХО, ничем не лучше, чем использование killlist и способ это не применим при обновлении данных (способ обновления - удаление/вставка - не рассматриваю). Про важность этого ограничения можно спорить, но, думаю, мало кто будет оспаривать то, что отсутствие обновления индекса всё-таки является недостатком.

>А чем дедовский способ не канает? Делается атрибут «Deleted»

Да, я хотел предложить такой вариант. Но с ним всё равно нельзя модифицировать базу, только обновлять. Старую запись - «deleted», новую - добавлять. Не всюду удобно :)

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

Этот способ мне напоминает про другой способ, который применяют для того, чтобы обойтись без нечеткого поиска: на уровне скриптов, перед отправкой запроса в бд проходятся spellchecker`ом... Аналогия не полная, поскольку способ обхода обновления индекса быстрее и практически не отличается от обновления индеса, но и там и там требуется логика на стороне скриптов.

> Способ, ИМХО, ничем не лучше, чем использование killlist и способ это не применим при обновлении данных (способ обновления - удаление/вставка - не рассматриваю). Про важность этого ограничения можно спорить, но, думаю, мало кто будет оспаривать то, что отсутствие обновления индекса всё-таки является недостатком.

1. Как вы собрались через killist решать подобную задачу - мне вообще непонятно. Нарисуйте сначала себе на бумажке полностью. Потому что я не могу догадаться по вашим намекам о том, чего нет :)

2. Обновление именно так и делается. Старые данные метятся как удаленные, новые добавляются заново.

Данный метод не подходит только если индекс постоянно модифицируется. А во многих случаях (когда мы не строим собственный гугл), модификация почти отсутствует.

> Этот способ мне напоминает про другой способ

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

Сорри, про стеммер погорячился. Однако момент насчет скрытия подготовки входного запроса в API - в силе.

> «we'll probably be busy building 1.x-alpha with incremental (real-time) updates for Christmas.»

Incremental != произвольное обновление. Это добавление. Хотя могу ошибаться.

есть и с++ интерфейс к сфинксу.

Incremental != произвольное обновление. Это добавление. Хотя могу ошибаться.

Можно по-разному интерпретировать. То, что это именно произвольное обновление я сужу и по другим источникам:

http://sphinxsearch.com/forum/view.html?id=2722

* True live updates/additions/deletions
(Stated as a goal for 1.0.0)

есть и с++ интерфейс к сфинксу.

Забыл указать, главным образом потому что sphinx сам на c++ написан. Потом уже API портирован на другие языки: Search API is natively ported to PHP, Python, Perl, Ruby, Java.

> * True live updates/additions/deletions

Да, пожалуй выйдет еще руче, чем я расчитывал. Посмотрим как на скорости отразится. Лично мне пока за глаза хватит, если дельты уйдут и индекс будет в реалтайме доливаться.