LINUX.ORG.RU

Вышел релиз sphinx 0.9.9

 , ,


0

0

Спустя год после последнего релиза 0.9.8.1 вышла новая версия полнотекстового поискового движка sphinx. Движок обладает API для PHP, Python, Java, Perl и Ruby и позволяет организовывать очень быстрый поиск.

Среди основных новшеств следует отметить:

  • реализована поддержка бинарного протокола MySQL. Теперь можно подключиться к sphinx через обычный MySQL-клиент и выполнять обычные запросы SELECT;
  • поддержка ODBC и в Windows, и в Linux;
  • разработчики добавили счетчики производительности;
  • теперь возможна перезагрузка конфигурации по SIGHUP;
  • добавлены постоянные соединения и UNIX-сокеты;
  • добавлена опция в конфиге inplace_enable, при включении которой, при индексировании нагрузка на файловую систему уменьшается в 1.5-2 раза ценой незначительного падения производительности (на 5-10%).

И индексы, и API сохранили обратную совместимость.

>>> Подробности

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

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

troop ()

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

amorpher ★★★★★ ()
Ответ на: комментарий от troop

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

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

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

pv4 ★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

troop ()
Ответ на: комментарий от ostin

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

troop ()
Ответ на: комментарий от pv4

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

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

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

troop ()

Вопрос

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

Ramzes001 ★★ ()
Ответ на: Вопрос от Ramzes001

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

troop ()
Ответ на: комментарий от pv4

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

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

KRoN73 ★★★★★ ()
Ответ на: Вопрос от Ramzes001

Re: Вопрос

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от troop

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

Ramzes001 ★★ ()
Ответ на: комментарий от KRoN73

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

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

troop ()
Ответ на: комментарий от troop

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Ramzes001

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


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

troop ()
Ответ на: комментарий от troop

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

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

real_maverick ★★★ ()
Ответ на: комментарий от real_maverick

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


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

troop ()
Ответ на: комментарий от troop

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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


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


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

troop ()
Ответ на: комментарий от Vit

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Vit

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


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

troop ()
Ответ на: комментарий от troop

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

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от troop

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

Vit ★★★★★ ()
Ответ на: комментарий от troop

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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


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

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

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

troop ()
Ответ на: комментарий от anonymous

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


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

troop ()
Ответ на: комментарий от troop

> * True live updates/additions/deletions

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

Vit ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.