Django + Sphinx = django-sphinx (?)

[zzeus]

А где пулл реквест от вас в оригинальный django-сфинкс?

[MechanisM]

Еще как альтернатива github.com/linkedin/indextank-engine & github.com/linkedin/indextank-service Linked in недавно открыли их исходный код.
Сам же пользуюсь django-haystack(из мастера на github — он сильно отличается от стабильных) + solr.

[MechanisM]

Вернее сильно отличается от зарелизенных версий)
Вот кстати еще github.com/flaptor/indextank-py
я пока их особо не смотрел, хотелось бы послушать мнения по поводу Indextank.

[MechanisM]

Забыл эту ссылочку еще github.com/flaptor/django-indextank-py-demo

[Prophet]

В solr хорошо с русскоязычным поиском? Я так понял поддержка стемминга на русском там заявлена.

[BasilioCat]

Solr на джаве, джава — тяжела. Например для VPS

[BasilioCat]

То есть вы предполагаете, что Solr может потреблять меньше памяти, чем Сфинкс? Именно память на VPSе самый ценный и ограниченный ресурс. А уж про внезапную прожорливость джавы до памяти ходят былины ;)
Лицензия — вас никто не заставляет встраивать код Sphinx в свои закрытые приложения, я слабо представляю себе, кому это могло бы понадобится, а использовать его в коммерческих целях как отдельный продукт GPL не запрещает.

[shodan]

> отсутствие фасетного поиска из коробки

Смотрю, миф конкретно прилип.

[magic4x]

Да вот же:
habrahabr.ru/blogs/django/136168/#comment_4529776
В сфинксе это не «фасетки» это группировка — разница только в терминах.

[magic4x]

Вот вам без мульти-запроса:

s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)

Будет один запрос, а группировка тут и есть add_facet, например, в pyes, просто оно тут так называется.
Группировка в документации описана. «Реализуется напрямую» — даже боюсь спросить что это значит.

[shodan]

Правильно ли я понимаю, что если добавить в API новый метод FacetQuery с одним дополнительным параметром (список атрибутов, по которым нужна группировка) — то в Сфинксе, с вашей точки зрения, немедленно «появится» труевая поддержка «фасеточного поиска»?

[magic4x]

Если честно, для «трушности» не хватает стринговых mva и «правильно» считать все тот же MVA (мой коммент ниже). Да, все честно, это groupby и если в группе два значения, то это все равно группа, но это как раз и отличает фасетки от группировок. Второе может быть и есть в самом поиске, но в питон апи я его не нашел.

[magic4x]

Раз уж такая пьянка.
Вот прямо сейчас как можно «закостылить» текстовые MVA? Ничего умнее списка md5-хешей я ничего не придумал, например, для тех же тегов: django, django sphinx.

[shodan]

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

[magic4x]

>Solr умеет?
К сожалению я не помню, делал я такое или нет сам. Солр у меня долго не прожил.
Вот тут речь о multiValued field, в примере:

doc {
    id : 1
    keywords: [ hello, world ]
    ...
}

Тут рассказывают как добавлять доки через CSV, там есть такая «строчка»:

# Example: for the following input
id,tags
101,"movie,spiderman,action"

#to index the 3 separate tags into a multi-valued Solr field called "tags", use
f.tags.split=true

Вот тут дока о «схеме»:
wiki.apache.org/solr/SchemaXml

Фасетки:
wiki.apache.org/solr/SolrFacetingOverview
wiki.apache.org/solr/SimpleFacetParameters

Все сразу:
wiki.apache.org/solr/

Очень наглядно для ElasticSearch (мне понравился больше чем солр, использует ту же библиотеку Lucene):

'{"title" : "One",   "tags" : ["foo"]}'
'{"title" : "Two",   "tags" : ["foo", "bar"]}'
'{"title" : "Three", "tags" : ["foo", "bar", "baz"]}'

"facets" : {
    "tags" : {
        "_type" : "terms",
        "missing" : 0,
        "total": 5,
        "other": 0,
        "terms" : [ {
            "term" : "foo",
            "count" : 2
        }, {
            "term" : "bar",
            "count" : 2
        }, {
            "term" : "baz",
            "count" : 1
        } ]
    }
}

[shodan]

Ага, спасибо! Будем изучать ;)

[magic4x]

Почему запрос-то? Вы видите чтобы я сохранял результат? Вот тут tags = s.Query('', index=index) мы получаем ответ от демона.
Апи собирает все наши запросы в список и только потом делает запрос.
Поэтому когда вы делаете Query на самом деле выполняется AddQuery и RunQuery и получаете results[0] — это такой враппер для ленивых.

>а в tags попадает количество совпадений? или это тоже надо вручную задавать? )

s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)
tags = [(x['attrs']['tags'], x['attrs']['@count']) for x in tags['matches']]
print tags 
{'django': 100, 'sphinx': 30}

Это не совсем честный пример. К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}
В случае пхп апи там есть костыль SetArrayResult, питоновцам не так повезло. Правда мне еще такое не пригождалось. Всякого рода «категории», «бренды» — да, это запросто.

Есть еще один момент %): сфинкс не умеет стринговые mva, а вот солр кажись умеет.
Однако я всеми руками за сфинкс, потому-как в нем есть то одно великое чего нет и в ближайшее время не будет в люцене: RT индексы — это просто железобитонный аргумент в пользу сабжа. Near-realtime, что обещают, не считается.

[shodan]

> К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}

Группировка по MVA есть и работает. Если документ принадлежит N группам, он во все N и попадет, все агрегатные функции посчитаются правильно.

Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?

[magic4x]

(headbang)
Вы не представляете как я сглупил, даже стыдно признаться %)
Я каким-то чудом проморгал атрибут @groupby, вместо него я брал значение из нужного поля, типа tags и пока в нем было одно значение оно работало, как только там попадало два и больше я не знал для кого подсчитан @count :)
Спасибо что спросили, порой, да, бревно в глазу не замечу.

[magic4x]

Понял почему порморгал. Если значение поля на русском (не mva), то атрибут приобретает вид '@groupby': 1174945792 и я его принял за какую-то служебную информацию. В MVA хранится числа, а в случае группировки в groupby записывается член группы, по которому шла группировка.

[shodan]

Ничего не понял. «Значение поля на русском» это как? :)

[magic4x]

Например, 'brand_name': 'Оптика' или 'brand_name': 'Massive'
В смысле, текстовое. Я так понимаю оно потом «конвертируется» в число. В частности при группировки по этому атрибуту я получил вот это '@groupby': -8253040684853230141L.

При группировки по tags (MVA):

'@count': 5,
'@groupby': 7,
'tags': [7, 8]

В атрибуте tags два тега, но в groupby записан айди тега, по которому шла группировка. В общем все хорошо.

[shodan]

А, речь перескочила на группировку по строковым атрибутам (колонкам), что ли? Да, там должно вернуть некий непонятный внутренний группировочный ключ. Однако сам *атрибут* при этом должен быть вполне корректным.

[shodan]

habrahabr.ru/blogs/sphinx/64318/

[pav]

Тоже не понимаю почему очень много людей боятся solr. Русский стеминг есть, фасетный поиск из коробки. Индексировать умеет почти все, удобно и прозрачно умеет делать дельта индексы. И много приятных вещей как по типу mlt (кстати а на Sphinx есть что-то на подобии mlt?).

[k0ldbl00d]

Исходя из заголовка:
jango+sphinx = jango-sphinx
можно предположить что sphinx = 0

[rtm]

Интересно, что Haystack не поддерживает Sphinx из-за проблем с лицензией.
Пришлось использовать Sorl — работает отлично.

[shodan]

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

[shodan]

Daniel молчит. Нашел другой email адрес, пробую.

[MechanisM]

Посмотрите тут: github.com/toastdriven/django-haystack/issues/485
кто-то уже написал бэкенд для Sphinx и Даниэль рассказывает о минусах Sphinx и почему он не добавляет его.
Возможно он так и не получил ваши сообщения. Но там я думаю он точно увидит его. Либо увидят заинтересованные и донесут.

Кстати для тех кому интересно, вот Sphinx-бэкенд для django-haystack: github.com/btimby/sphinx-haystack

[shodan]

Спасибо за ссылку!

Большая часть т.н. «минусов» вызывает у меня сильное офигение.

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

Сейчас напишу ему туда.

[MechanisM]

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

[shodan]

Дык, оно все равно полезное: что людям вот кажется важным, в какие мифы верят. Что стоит приделывать, с чем нужно бороться. ;)

Плюс тот факт, что я с Д. в итоге ведь связался почтой и *раньше*, чем появился комментарий, усиляет мою веру в человечество!!!

[MechanisM]

Молодец, хорошо расписал там все! Надеюсь скоро займутся этим и в django-haystack бэкенд Shphinx будет «из коробки». Я на твиттере(и в некоторых комнатах IRC) с нужными хэш-тэгами выложил ссылку на твой комментарий. Те кому интересно проголосуют чтобы добавили или доработают тот что я выше по ссылке выложил. Спасибо!

[shodan]

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

Те. считаю, задачу «давайте легко прикрутим поиск к фреймворку X» в идеальном мире должен хорошо решать вообще тот или иной наш нативный интерфейс; следующее допустимое приближение это родной плагин (видимо, это django-sphinx или любой его живенький форк); и только затем обобщенные абстракции типа haystack.

Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.

[EvilX]

Понадобилось сделать поиск на сфинксе. В реализации django-sphinx не понравилось в первую очередь привязка к моделям. А если контент раскидан по связным моделям?
Тогда реализовал вывод через питоновское апи и индексацию по xml.

[shodan]

Про варианты. Есть еще один: можно ходить напрямую в Sphinx через SphinxQL, все будет совершенно аналогично работе с обычным MySQL.

Про режимы поиска. Они, может, некоторые мелочи слегка упрощают, но это таки легаси. Я бы советовал таки везде приводиться к MATCH_EXTENDED.

Про релизы. Мы обратно совместимы, практически всегда. Ну те. любая новая версия обязана работать с любыми старыми клиентами и умеренно старыми форматами индексов.

[Kirax]

А я для себя просто сделал «обертку» python api. То есть, например, одна функция поиска, которая принимает многочисленные опции сфинкса в качестве параметров. Другая функция возвращает объекты по классу модели и результату сфинкса.

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