Как стать автором
Обновить

Комментарии 50

А где пулл реквест от вас в оригинальный django-сфинкс?
Вернее сильно отличается от зарелизенных версий)
Вот кстати еще github.com/flaptor/indextank-py
я пока их особо не смотрел, хотелось бы послушать мнения по поводу Indextank.
В solr хорошо с русскоязычным поиском? Я так понял поддержка стемминга на русском там заявлена.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Solr на джаве, джава — тяжела. Например для VPS
НЛО прилетело и опубликовало эту надпись здесь
То есть вы предполагаете, что Solr может потреблять меньше памяти, чем Сфинкс? Именно память на VPSе самый ценный и ограниченный ресурс. А уж про внезапную прожорливость джавы до памяти ходят былины ;)
Лицензия — вас никто не заставляет встраивать код Sphinx в свои закрытые приложения, я слабо представляю себе, кому это могло бы понадобится, а использовать его в коммерческих целях как отдельный продукт GPL не запрещает.
НЛО прилетело и опубликовало эту надпись здесь
> отсутствие фасетного поиска из коробки

Смотрю, миф конкретно прилип.
НЛО прилетело и опубликовало эту надпись здесь
Да вот же:
habrahabr.ru/blogs/django/136168/#comment_4529776
В сфинксе это не «фасетки» это группировка — разница только в терминах.
НЛО прилетело и опубликовало эту надпись здесь
Вот вам без мульти-запроса:
s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)

Будет один запрос, а группировка тут и есть add_facet, например, в pyes, просто оно тут так называется.
Группировка в документации описана. «Реализуется напрямую» — даже боюсь спросить что это значит.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Правильно ли я понимаю, что если добавить в API новый метод FacetQuery с одним дополнительным параметром (список атрибутов, по которым нужна группировка) — то в Сфинксе, с вашей точки зрения, немедленно «появится» труевая поддержка «фасеточного поиска»?
Если честно, для «трушности» не хватает стринговых mva и «правильно» считать все тот же MVA (мой коммент ниже). Да, все честно, это groupby и если в группе два значения, то это все равно группа, но это как раз и отличает фасетки от группировок. Второе может быть и есть в самом поиске, но в питон апи я его не нашел.
Раз уж такая пьянка.
Вот прямо сейчас как можно «закостылить» текстовые MVA? Ничего умнее списка md5-хешей я ничего не придумал, например, для тех же тегов: django, django sphinx.
Пока никак, только сконвертировать в список номеров, действительно. Solr умеет? Где почитать (я плохо ориентируюсь в их документации)? Ну и заодно, наверное про его актуальный набор поддерживаемых сегодня типов где почитать?
>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
        } ]
    }
}

Ага, спасибо! Будем изучать ;)
НЛО прилетело и опубликовало эту надпись здесь
Почему запрос-то? Вы видите чтобы я сохранял результат? Вот тут 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, что обещают, не считается.
> К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}

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

Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?
(headbang)
Вы не представляете как я сглупил, даже стыдно признаться %)
Я каким-то чудом проморгал атрибут @groupby, вместо него я брал значение из нужного поля, типа tags и пока в нем было одно значение оно работало, как только там попадало два и больше я не знал для кого подсчитан @count :)
Спасибо что спросили, порой, да, бревно в глазу не замечу.
Понял почему порморгал. Если значение поля на русском (не mva), то атрибут приобретает вид '@groupby': 1174945792 и я его принял за какую-то служебную информацию. В MVA хранится числа, а в случае группировки в groupby записывается член группы, по которому шла группировка.
Ничего не понял. «Значение поля на русском» это как? :)
Например, 'brand_name': 'Оптика' или 'brand_name': 'Massive'
В смысле, текстовое. Я так понимаю оно потом «конвертируется» в число. В частности при группировки по этому атрибуту я получил вот это '@groupby': -8253040684853230141L.

При группировки по tags (MVA):
'@count': 5,
'@groupby': 7,
'tags': [7, 8]

В атрибуте tags два тега, но в groupby записан айди тега, по которому шла группировка. В общем все хорошо.
А, речь перескочила на группировку по строковым атрибутам (колонкам), что ли? Да, там должно вернуть некий непонятный внутренний группировочный ключ. Однако сам *атрибут* при этом должен быть вполне корректным.
НЛО прилетело и опубликовало эту надпись здесь
Тоже не понимаю почему очень много людей боятся solr. Русский стеминг есть, фасетный поиск из коробки. Индексировать умеет почти все, удобно и прозрачно умеет делать дельта индексы. И много приятных вещей как по типу mlt (кстати а на Sphinx есть что-то на подобии mlt?).
НЛО прилетело и опубликовало эту надпись здесь
Исходя из заголовка:
jango+sphinx = jango-sphinx
можно предположить что sphinx = 0
Интересно, что Haystack не поддерживает Sphinx из-за проблем с лицензией.
Пришлось использовать Sorl — работает отлично.
Парням из haystack достаточно было тупо написать мне письмо, и получить официальное разрешение использовать клиентскую библиотеку. Напишу-ка я им сам, раз они стеснительные.
Daniel молчит. Нашел другой email адрес, пробую.
Посмотрите тут: github.com/toastdriven/django-haystack/issues/485
кто-то уже написал бэкенд для Sphinx и Даниэль рассказывает о минусах Sphinx и почему он не добавляет его.
Возможно он так и не получил ваши сообщения. Но там я думаю он точно увидит его. Либо увидят заинтересованные и донесут.

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

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

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

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

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

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

Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.
Понадобилось сделать поиск на сфинксе. В реализации django-sphinx не понравилось в первую очередь привязка к моделям. А если контент раскидан по связным моделям?
Тогда реализовал вывод через питоновское апи и индексацию по xml.
Про варианты. Есть еще один: можно ходить напрямую в Sphinx через SphinxQL, все будет совершенно аналогично работе с обычным MySQL.

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

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

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

Публикации

Истории