Pull to refresh

Comments 50

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

Смотрю, миф конкретно прилип.
UFO landed and left these words here
UFO landed and left these words here
Вот вам без мульти-запроса:
s = SphinxClient()
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
tags = s.Query('', index=index)

Будет один запрос, а группировка тут и есть add_facet, например, в pyes, просто оно тут так называется.
Группировка в документации описана. «Реализуется напрямую» — даже боюсь спросить что это значит.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Правильно ли я понимаю, что если добавить в 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
        } ]
    }
}

Ага, спасибо! Будем изучать ;)
UFO landed and left these words here
Почему запрос-то? Вы видите чтобы я сохранял результат? Вот тут 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 записан айди тега, по которому шла группировка. В общем все хорошо.
А, речь перескочила на группировку по строковым атрибутам (колонкам), что ли? Да, там должно вернуть некий непонятный внутренний группировочный ключ. Однако сам *атрибут* при этом должен быть вполне корректным.
UFO landed and left these words here
Тоже не понимаю почему очень много людей боятся solr. Русский стеминг есть, фасетный поиск из коробки. Индексировать умеет почти все, удобно и прозрачно умеет делать дельта индексы. И много приятных вещей как по типу mlt (кстати а на Sphinx есть что-то на подобии mlt?).
UFO landed and left these words here
Исходя из заголовка:
jango+sphinx = jango-sphinx
можно предположить что sphinx = 0
Парням из 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. То есть, например, одна функция поиска, которая принимает многочисленные опции сфинкса в качестве параметров. Другая функция возвращает объекты по классу модели и результату сфинкса.

А с конфигами ИМХО лучше всё же разбираться вручную, т.к. там есть много полезных вещей, о которых вы можете не подозревать. ;)
Only those users with full accounts are able to leave comments. Log in, please.