Pull to refresh

Comments 54

UFO just landed and posted this here
ElasticSearch весьма велик (Java всё таки), а нынешний Sphinx кушает всего несколько мегабайт памяти (если делать поиск для небольшого сайта).
Правда на поприще «дёшево, сердито и чтоб не париться» на пятки наступает PostgreSQL — у них уже можно делать полнотекстовый поиск с некоторыми обязательными для такого поиска плюшками (типа стоп-слов) прям силами самой РСУБД.
теги читаю, sql за модой не гонится, а что бы слон на пятки не наступал — не убегайте от его, а сделайте интеграцию из коробки. И удачи в реализации планов!
UFO just landed and posted this here
кажется, что как раз своими настройками (вообще подо все) он очень удобен.
В Эластике есть русская морфология из коробки?
Стемминг есть, он в solr с незапамятных времен есть, а elastic конкурирует, в основном, с ним. Плюс можно использовать russianmorphology на базе, как я понимаю, AOT'а.
не только велИк, но и, судя по нашим тестам, проигрывает в скорости индексации и поиска Сфинксу.
elastic ок, но в нашем случае результаты сравнения его со sphinx такие (не в пользу elastic):
  • средняя скорость поиска 1:5 (относительная разница)
  • размер индексов 1:4 — это после того, как убрали хранение доков в elasticsearch
  • скорость индексации 1:8


Мерялось все без нагрузки, под нагрузкой думаю перевес sphinx был бы выше, дабы Си
С точки зрения конфигурации и простоты работы — проще там, где ориентируешься и какой инструмент тебе знаком лучше.
а если размер индексов несколько терабайт?
а какие с этим могут проблемы в sphinx?
он прекрасно будет работать, если места на диске или кластере хватает.
На HL++ Вячеслав Крюков еще в 13-ом году делал доклад на эту тему www.highload.ru/2013/abstracts/1229.html
Не знаю, потому и спрашиваю. Очень давно не работал со сфинксом. Надо посмотреть
ElasticSearch? Вы серьезно? Нет я понимаю сравнивать еще Solr со Sphinx, но эластик просто по всем основным параметрам, типа скорость, гибкость настройки и т.д. просто рядом не стоял… Про масштабируемость я вообще промолчу.
А можно поподробнее? У какой системы проблемы с масштабируемостью?
У всех, но у эластика — гигантские… Пересоздавать полутерабайтный индекс (который помер) — то еще удовольствие.
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо за статью, будем ждать релиза. Есть небольшой вопрос: при переходе на новую версию, я так понимаю, что при миграции придется заморочиться с конфитурацией (читай все переделать)?
Миграцию как раз конфигурации мы должны суметь сделать сделать довольно легкой. Там основная часть про sources/indexes по существу должна переехать в отдельный indexer.conf практически без изменений, а остального очень мало, это все легко переделать вручную, либо автоматом (условный скрипт upgrade.py) сконвертировать разово.

Меня больше беспокоит миграция больших индексов, тк. конверсия в новый формат а) будет возможна только при соблюдении ряда условий, dict=keywords + docinfo=extern + еще ряд более эзотерических штук (отсутствие hitless итп), б) даже в случаях, где возможна, может оказаться слишком медленной (ну те. может оказаться проще переналить данные заново, чем сконвертировать существующий индекс). Впрочем, так или иначе оно все решаемо.

Цена прогресса, шо поделать. Много лет держали бинарную совместимость довольно неплохо, пора наконец разок сломать!!!
Спасибо за объяснения.
dict=keywords + docinfo=extern
ну тут все понятно, а
отсутствие hitless итп
— это что? Где можно почитать?
— это что? Где можно почитать?

Это как пример эзотерической штуки, из-за которой сконвертировать индекс окажется невозможно. Беспозиционный (частично или полностью) индекс. sphinxsearch.com/docs/current.html#conf-hitless-words
А когда грядёт то?:)

Хочется http-управления, как в эластике, чтобы можно было налету создавать отдельные индексы, наполнять их данными и настраивать параметры поиска.
Грядет в этом году. Увы, точнее пока не могу оценить.

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

Менеджмент индексов на лету (не только через HTTP) тоже планируется, да. Возможно, не в первой же альфе 3.0, но планируется.
Удачи, радует, что и такие крутые вещи делаются нашими людьми )
У меня сфинкс (еще какой-то лохматой версии) работает месяцами, рестартуется только при обновлениях на сервере. И при этом на сайте быстрый и внятный поиск.
хранилка оригиналов документов
я надеюсь это отключаемо? А то если «как бы база» не нужна, чтобы то есть не хранить дважды…
Да, отключаемо (или не включаемо, пока не решил, какой лучше дефолт).
Андрей, а можно пару слов об HTTP/REST доступе в 2.3. В документации я такого нигде не встречал, о какой базовой реализации идет речь?
Оно доступно в SVN транке. Пока неотдокументировано примерно никак с одной стороны и практически нету никаких endpoints и опций к ним с другой, но таки уже:

searchd
{
    workers = threadpool
    listen = localhost:9380:http
}

http://localhost:9380/sql/?query=select%20*%20from%20rt

{
    "attrs": ["id","gid","gid2","date_added","title","content"],
    "matches": [
        [1,1,[5],1428361133,"test one 24 mois","this is my test document number one"],
    ...
}
Есть у кого-нибудь видео встречи?
Не понятны некоторые вещи. Долго ждал пока обновится документация но так и не произошло.
1. Был замечательный инструмент «search ». Что теперь является заменой?
2. В документации есть куча информации про SQL, но вот инструмента в котором можно этот sql ввести я не нашёл. Как щупать это чудо?
3. После апдейта сломались все стемеры и другие плюхи в morphology. Чтото пока не получилось вникнуть как починить. То есть конфиг кушается но поиск уже не тот. А так ка кет search тула то совсем засада с дебагом.
Чтото одни печали пока.
1. Инструмент сразу был дрянненький вообще-то, и предназначлся скорее для внутренней отладки. Заменой, как всегда, является штатный запуск searchd и запросы либо через mysql либо любой другой удобный клиент.

2. Неожиданно, mysql -h0 -P9306, да.

3. Надо смотреть SHOW META и далее SHOW PLAN, подробности в документации есть.
> В документации есть куча информации про SQL, но вот инструмента в котором можно этот sql ввести я не нашёл. Как щупать это чудо?

mysql -P9306 --protocol=tcp --prompt='sphinxQL> '

Ну еще можно добавить хост соответственно.
Октябрь заканчивается, на оффсайте ни намёка на 3ю версию.
Увы, разработка двигается вот так — небыстро.
А есть примерные сроки? Зима? Весна? Лето?
Упс, пропустил комментарий в горке почты.

Нету сроков. Конец в целом видно, конкретную дату не видно :(
Почти год прошел. А на гитхабе даже ветки нет.
master это разве не sphinx 3?
Мастер это 2.3 версия.

Ветку 3.0 откроем, как только переделку формата доведем хотя бы до альфы.
я так понимаю — дело с мертвой точки так и не сдвинулось?

На SphinxMeetup shodan говорил, что в начале осени откроет ветку, даже если там не всё будет готово.

Не, эти «люди» форкнулись по решительно другим причинам, настоящая история (в отличие от официальной) совершенно феерическая.

А ряд других людей уже успешно гоняет 3.0 в проде и тестах ;)
Жаждя кровавых подробностей, нагуглил только вот это:

FYI, we’ve been receiving a spam from “developers” of a fork of SphinxSearch claiming your development have stalled. That’s not nice of them.
@SphinxSearch user, yep, thanks for the report. I’m investigating this. At the moment, looks like some of the ex-employees decided that it’s quite appropriate not just to keep Sphinx internal information (like those emails subscribed to the mailing list) after leaving Sphinx for a competitor (silently, by the way, and while retaining access to Sphinx servers during the “pause mode” that we had), but also to use it this way. Well. Their actions kinda speak for themselves. :)

Я бы, кстати, тоже на досуге погонял 3.0, но увы:
Where are the commits? Not public. Mostly in private branches, both on Github, and locally.

В общем расскажите, чего вообще творится, а то у нас тут некий информационный вакуум, слышал даже мнение, что Сфинкс 3 это типа как Перл 6 +)
Да у меня пока ещё нет желания тратить время на онлайн-драму и постить все пикантные и феерические подробности. Глобально-то история довольно банальная: начались разные проблемы, люди довольно некрасиво форкнулись, люди довольно некрасиво ушли, люди продолжают делать странные и некрасивые вещи, чем местами тупо мешают и проекту Сфинкс и лично мне.

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

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

Мысли понятны и такое и здесь и там, но… то все лирика.
А вот как вот это ниже "сочетается" по вашему с опенсорсным проектом?


При этом… нужно написать мне в почту и я выдам билд.

Вас правда здесь ничего не смущает? Совсем, совсем?

Да меня в целом в текущей ситуации многое «смущает», в том числе и этот момент. Это не самая большая головная боль.

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

Замечу ещё, что доступ к исходникам там, где можно и нужно, я тоже обеспечиваю и тоже уже сейчас.

А исходники-то не открыты до сих пор. То есть по сути простым смертным ничего не остаётся, кроме как переходить на Manticore

Кто такие эти так называемые «простые смертные» и как их жизнь радикально поменяет наличие исходников, я не знаю.

А переходить, если хочется переходить, очевидно, что уже давно пора на Эластик. Собственно, см. первый же комментарий 4-летней давности :-) Нафига эти полумеры со странными форками сразу некоторым образом леворезьбовых (на данную минуту) проектов, бери текущий индустриальный стандарт.
Уважаемый автор, расскажите, пожалуйста, про текущую ситуацию со sphinx или дайте ссылочку какую. Elastic медленный очень, притом что Lucene в целом достаточно быстрый.
Текущая ситуация вкратце — сижу вот в офисе Авито; пилим всякое в этот Сфинкс тут в составе группы лиц; не менее успешно его эксплуатируем; закапывать проект мы ни разу не собираемся; а вовсе даже и наоборот, есть некоторое громадьё технологических планов.

Вышло именно так ровно потому — что сколько-то серьёзный интерес к продолжению проекта проявила в нужный момент исключительно компания Авито, все остальные разговоры происходили практически буквально в стиле «срочно почини нам редкий спорадический баг неизвестной сложности в какой-то древней версии за гигантский бюджет в $200 на круг» или там например «сколько-сколько, целых $800 в мес за поддержку?! Не, это очень дорого для нашей маленькой компании на 1000+ человек» — и это, возможно, даже не самые угарные истории :)))

Поскольку пилим мы не только лишь один Сфинкс, а ещё и всю остальную инфраструктуру местного поиска, а толковых рук удаётся нанять не так много, как хотелось бы — то и получается не так быстро, как в Идеальном Мире хотелось бы. Плюс моё личное время на документацию, публичные релизы итп находится строго по остаточному принципу, увы; а каких-то ещё добровольцев помогать мне этим заниматься на данный момент нашлось отчего-то ровно 0 (ноль). Однако движемся явно вперед, ага. У нас тут вокруг всё интересно, и думаю, будет ещё интереснее :) что рано или поздно найдёт своё отражение и в релизах тоже, конечно.
Sign up to leave a comment.

Articles